分析源码最好的方式就是画时序图，搞清它的流程，时序图还有一个好处，就是看到某个地方，如果忘了前面的，可以直接看看图就好了。也方便以后复习。

根据android7.0的源码，绘制了时序图，跟着图点点源码，对属性动画的会有更清晰的理解，有利于日常开发。

别犹豫了，跳进源码点一点吧

图片较大，加载可能较慢，请耐心等待。最好查看原图，会比较清晰

建议使用电脑查看

属性动画源码分析.jpg

时序图中讲到，系统每隔16ms会发送VSYNC信号，然后ValueAnimation的doAnimationFrame就会调用，接下来分析一下他是如何被调用的

为什么ValueAnimator中的doAnimationFrame会每隔16ms回调一次(API25)

在ValueAnimator的start方法中，调用AnimationHandler animationHandler = AnimationHandler.getInstance();，然后animationHandler.addAnimationFrameCallback(this, (long) (mStartDelay * sDurationScale));。

1. 首先看第一条代码。在api25中，AnimationHandler是一个单例的，并且被ThreadLocal来持有，说明一个线程中只能有一个。（猜想：动画应该是在主线程执行的吧？所以线程单例应该等价于全局单例吧？？？）
2. 然后看addAnimationFrameCallback
   • 他首先判断mAnimationCallbacks是否为空，它是个什么玩意呢？它是一个callback的集合，看下面可知，该方法的第一个参数就是被添加到了这个集合中，而第一个参数又是ValueAnimator（其实是AnimationFrameCallback，ValueAnimator实现了这个接口），说明
     mAnimationCallbacks这个集合中存储了N个ValueAnimator，也就是我们在调用层创建了5个属性动画，并且使用了它们，这个集合中就会有5个回调。
   • 再看该方法最前面，getProvider().postFrameCallback(mFrameCallback);，这个过程其实就是调用了mChoreographer.postFrameCallback(mFrameCallback);，并且由于AnimatorHandler是单例的，所以这个mProvider、mChoreographer也是单例的。
   • 那么什么是Choreographer呢，他是android.view下的一个类，它可以接收到系统的VSYNC信号，并且在前面设置了回调的情况下，回调这个接口mFrameCallback的doFrame方法，然后调用AnimatorHandler的doAnimationFrame方法，然后在for循环，调用前面说的那个callback集合中的回调接口，最后，由于ValueAnimator就是实现的那个接口，回调的就是ValueAnimator，所以ValueAnimator中的doAnimationFrame就被回调了。所以，每隔16ms，ValueAnimator中的doAnimationFrame就会被回调一次。

那么，mChoreographer中的FrameCallback是如何接受到VSYNC信号的呢？

1. 稀里糊涂的找到了一个叫做FrameDisplayEventReceiver的类，他继承自DisplayEventReceiver，然后点进去看注释，看方法，大概是系统会在通过底层去回调它的onVsync方法，所以从这里入手开始看吧。
   2 .假设/猜测，onVsync方法会在底层每次发送消息的时候回调，再往下就到jni层了，不考虑了。那么在onVsync最后几行代码中，把this发送给了handler，而他自己实现了runnable接口，所以到了handler之后，他自己的run方法就会被调用。所以调用他的run方法，然后调用了doFrame方法。
2. doFrame中调用了doCallbacks，然后内部调用了CallbackRecord.run方法，然后里面就是 ((FrameCallback)action).doFrame(frameTimeNanos);
   ，这样，mChoreographer里面的这个接口就被回调了

后面这块代码看的糊里糊涂，连蒙带猜也不知道对错，功力不够，再接再厉。。。