Animator源码

做百分比的定时更新，发现用Handler.postDelay会卡，同样的逻辑放到Animator里就不会。拜读一下Animator是怎么做的。
主要是四个类：Animator（基类）、ValueAnimator（主要分析）、ObjectAnimator和AnimatorSet。

Animator：

• Animator是不做线程同步的，所有方法都是口头要求同线程操作。Handler的postDelay是有同步的，每次都会在MessageQueue.enqueueMessage时做同步
• 所有listener都是顺序执行的，均在UI线程被调用
• 清空listener时会 mListeners.clear(); mListeners = null;
• 因为AnimatorListener的回调不是很全，又加入了AnimatorPauseListener，做到了向前兼容

ValueAnimator：

• 主要逻辑是：AnimatorHandler（内部类，Runnable）持有当前线程（ThreadLocal实现）start的所有Animator。如果需要执行，AnimatorHandler将自己post到Choreographer中，在Choreographer收到页面刷新信息后回调自己，在其所在的Looper执行所有更新操作
• a%b的语义是while(a>b) a -= b;float、double都是这个语义
• 维持一些不变式，比如说startTime + fractionTime = now;会让程序简洁
• 时间使用SystemClock.uptimeMillis()
• Animator.setFrameDelay是直接给Choreographer设FrameDelay，不一定生效
• 对于同一线程可能修改的容器，可以使用退化的CopyOnWrite策略
• 不论在什么线程上启动，Animator的所有操作都在UI线程上执行，但是不同线程上启动的Animator之间的运行时间是不会互相影响的，相同线程的Animator会在同一队列顺序执行
• 实际上Animator多出很多变量来减少中间计算，开发者没有这样做，很可能是为了减少维持不变式的成本，减少出错的概率

分析

之所以用Handler会卡，用Animator不卡，最重要的原因是Animator的间隔和时序都是通过Choreographer控制的，与页面刷新的节奏是同步的，而Handler可能会因为各种原因导致掉帧，看起来卡。为了保持Choreographer尽量的流程，增加的ThreadLocal区分不同的Animator。
使用不当（未及时remove listener，没有cancel Animator）可能有内存泄露。

架构

Animator的架构设计非常有趣，划分的非常细致，以至于我一直把Interpolator理解错了。
抽象来看，ValueAnimator就是一个时间到值的函数映射及时间自运行的功能，即一个自更新的f(t)（在一个二维坐标系中，自动变换x获取y）。而真实的ValueAnimator对f进行了拆分。
- ValueAnimator：对t进行了归一化，即a = t/total，把x轴的进度都变为0-1。这样后面的所有运算都是统一的算法。可以看到BounceInterpolator中，所有的值都是写死的，非常容易做出通用的算法
- Interpolator：a到x的映射，会出现不同的映射进度，x = f1(a)。所有不同的映射、弹跳等变换都是在这一层。这里面，所有的变化都发生在x轴上，充分隔离了传入的y范围（ValueAnimator.ofInt）的影响，也保证了这是一个单纯的分段函数，不会出现两级分段的情况
- PropertyHolder：x到y的映射f2(x)，这是最终函数值获取，大部分来讲就是一个线性变换/分段函数。这里面的输入就是进行了一大波变换后的x了，这里面又非常简单的做了一系列的变化，非常清爽
这样一个架构比我主观上yy的直接Interpolator是f(t)要有不小的优势。主要有几方面：
- f(t)真正的入参还是有y取值范围的，也就是说f(t, y[])。增加了Interpolator和归一化，可以真正的让映射f2只有一个入参就是x，而y[]是作为算法的一部分存在的
- 同样，各种速率变换本身也是有多入参的，包括了y[]，duration和t。归一化剔除了duration，只做x轴上的映射剔除了y[]，真的是简化了思考和算法

大概这就是牛逼的设计吧，虽然不是那么好理解，要细细品味才能参透。但是不管从哪方面来讲，都比直来直去的更合理。