揭秘：Android屏幕中你不知道的刷新机制

前言

之前在整理知识的时候，看到android屏幕刷新机制这一块，以前一直只是知道，Android每16.6ms会去刷新一次屏幕，也就是我们常说的60fpx，那么问题也来了：

16.6ms刷新一次是什么一次，是以这个固定的频率去重新绘制吗？但是请求绘制的代码时机调用是不同的，如果操作是在16.6ms快结束的时候去绘制的，那么岂不是就是时间少于16.6ms，也会产生丢帧的问题？再者熟悉绘制的朋友都知道请求绘制是一个Message对象，那这个Message是会放进主线程Looper的队列中吗，那怎么能保证在16.6ms之内会执行到这个Message呢？

文章较长，请耐心观看，水平不足，如果错误，还望指出

View ## invalidate()

既然是绘制，那么就从这个方法看起吧

public void invalidate() {
        invalidate(true);
    }
    public void invalidate(boolean invalidateCache) {
        invalidateInternal(0, 0, mRight - mLeft, mBottom - mTop, invalidateCache, true);
    }
    void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache,
            boolean fullInvalidate) {
            ......
            final AttachInfo ai = mAttachInfo;
            final ViewParent p = mParent;
            if (p != null && ai != null && l < r && t < b) {
                final Rect damage = ai.mTmpInvalRect;
                damage.set(l, t, r, b);
                p.invalidateChild(this, damage);
            }
           .....
        }
    }

主要关注这个p，最终调用的是它的invalidateChild()方法，那么这个p到底是个啥，ViewParent是一个接口，那很明显p是一个实现类，答案是ViewRootImpl，我们知道View树的根节点是DecorView，那DecorView的Parent是不是ViewRootImpl呢

熟悉Activity启动流程的朋友都知道，Activity 的启动是在 ActivityThread 里完成的，handleLaunchActivity() 会依次间接的执行到 Activity 的 onCreate(), onStart(), onResume()。在执行完这些后 ActivityThread 会调用 WindowManager#addView()，而这个 addView()最终其实是调用了 WindowManagerGlobal 的 addView() 方法，我们就从这里开始看，因为是隐藏类，所以这里借助Source Insight查看WindowManagerGlobal

public void addView(View view, ViewGroup.LayoutParams params,
            Display display, Window parentWindow) {
        synchronized (mLock) {
            .....
            root = new ViewRootImpl(view.getContext(), display);
            view.setLayoutParams(wparams);
            mViews.add(view);
            mRoots.add(root);
            mParams.add(wparams);
        }
        try {
            root.setView(view, wparams, panelParentView);
        } catch (RuntimeException e) {
            // BadTokenException or InvalidDisplayException, clean up.
            synchronized (mLock) {
                final int index = findViewLocked(view, false);
                if (index >= 0) {
                    removeViewLocked(index, true);
                }
            }
            throw e;
        }
    }
 public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
        synchronized (this) {
                ....
                view.assignParent(this);
                ...
            }
        }
void assignParent(ViewParent parent) {
        if (mParent == null) {
            mParent = parent;
        } else if (parent == null) {
            mParent = null;
        } 
      }

参数是ViewParent，所以在这里就直接将DecorView和ViewRootImpl给绑定起来了，所以也验证了上述的结论，子 View 里执行 invalidate() 之类的操作，最后都会走到 ViewRootImpl 里来

ViewRootImpl##scheduleTraversals

根据上面的链路最终是会执行到scheduleTraversals方法

void scheduleTraversals() {
        if (!mTra