说明的版本：2.0.9
前言
自2.0.4版本加入动画预处理回调并与链式语法结合，集成速度得到了较大提高，重复性工作也大大降低。
但是，之前版本仍然存在一个痛点，就是动画元素的下标。
对于纯代码布局，下标的顺序就是addSubView的顺序，
对于xib布局，下标顺序是关联的顺序。
使用坑点
- 对于xib布局特别坑，如果习惯不是特别好，那么关联的组件顺序开发者自己根本就不知道，只能一个一个试，这个就别提多坑了。
- 对于纯代码布局，如果视图数量稍微多一点，就要打开对应的文件去看，然后按照规则得出顺序，很憋屈。
解决方案
起初，我也意识到了这个问题，但思路一直是如何调整动画元素的顺序，让开发者很容易就能准确判断出顺序，然后对应修改。
期间，也有想过根据动画元素的frame，按照从左往右，从上至下动态调整顺序，但是还是觉得有点蠢，所以并没有推出。
后来，自己在集成中，始终觉得这是一个很难受的点。前几天灵感一发，既然程序本身知道下标，为什么不体现出来呢？我何必一直想着如何能更好的调整顺序呢？
如下图所示：
将版本新增的openAnimationTag属性设置为YES，
会将所有元素自动添加红色的角标，角标就是动画元素对应的下标。
如此以来，开发者不需要在纠结哪个元素对应是哪个下标了。
比如:
调整红色1号的宽度为20，高度为10，圆角为3
view.animation(1).width(20).height(10).radius(3);
以前把时间都浪费在红色1号的下标是哪个了，现在无需纠结，一眼看过去，哪个对哪个很清晰。
想要调整红色1号，那就是view.animation(1)，屡试不爽。
PS：为了防止开发者粗心，在生产环境下没有及时将属性openAnimationTag改回去，同时减少生产环境不必要的判断
，生成红色角标的代码仅在debug模式下生效。
新的启动函数
在实践中发现，
使用原有的启动动画方法tab_startAnimation时发现了一个问题。
在网络非常好的情况下，动画基本没机会展示出来，甚至会有一闪而过的视觉差，并不友好。
起初用tab_startAnimation方法配合MJRefresh，则会减缓这样的问题，原因是MJRefresh本身有一个延迟效果（为了说明，这么称呼的），大概是0.4秒。
所以，增加了一个带有延迟时间的启动方法，默认为0.4s
这样的话，在网络卡的情况下，0.4秒并不会造成太大的影响，在网络不卡的情况下，可以有一个短暂的视觉停留效果。
个人比较喜欢的两个控制函数方案
开启动画
[self.tableView tab_startAnimationWithCompletion:^{
// 请求数据
// ...
// 获得数据
// ...
[self afterGetData];
}];
结束动画
[self.tableView tab_endAnimationEaseOut];
下面的方法可以自定义延迟时间
- (void)tab_startAnimationWithDelayTime:(CGFloat)delayTime
completion:(void (^)(void))completion
PS: 当然，这个方案仅仅是我个人偏好，你可以自行处理。
