屏幕刷新机制与Choreographer的工作原理

前言

2021的进度已过50%，不知大家的小目标是否已经也到达了50%了，如果没有的话，还有2021的下一个50%。本文将给大家带来Android的屏幕刷新机制的介绍，同时通过Choreographer的源码了解它的工作原理。

正文

刷新率：代表一秒内屏幕刷新的次数，大部分手机的刷新率为60Hz，即一秒刷新60次，所以大概就是16.6ms刷新一次，这个是由硬件的参数决定的。

帧率：相信开发客户端的同学都听说过FPS，也就是帧率。帧率代表一秒内绘制的帧数，当某个页面或者某个操作的帧率比较低时，也就是出现丢帧的情况（没法在16.6ms内完成工作），有可能就会出现卡顿。

Android通过VSync来确保帧率的稳定，VSync是Vertical Synchronization(垂直同步)的缩写，它主要用来出发界面的更新绘制、处理用户的输入等操作，系统会定时发送Vsync信号，也就是16ms发送一次，在Android4.1开始引入Vsync机制。

我们通过下面两张图来看看VSync机制。

正常的Vsync机制：

发生卡顿：

（图片来源于网络，如有侵权请联系删除）

以上两张图如何理解：

正常帧：1、2、3、4每一帧内都能够计算完成，并且得到展示，给用户。

掉帧：第一帧的时候，B没能计算完成，所以第二帧继续展示A，直到第三帧才能展示出B，但A却不能在第三帧计算完成，所以第四帧继续展示的是B，就出现了掉帧的情况，可能给用户带来卡顿的感觉。

看完上图，可能会带来对问题是Vsync怎么去触发到具体页面的绘制等响应的呢？有个重要的类Choreographer，Vsync通过去唤醒Choreographer，然后它进行一系列的处理，比如输入事件、控件的更新等等，同时Choreographer也会进行请求Vsync信号。接下来就来看看Choreographer这个类是怎么样的。

除了VSync信号，Choreographer起到了很大的作用，假设没有Vsync跟Choreographer，那么每当渲染完一帧，那么下一帧就接着开始渲染，这导致了不稳定的情况。它们的存在便能够保证帧率的稳定，让用户的体验更好。

Choreographer通过接收Vsync的信号，进而对app的一些绘制、用户输入事件、动画等做处理，这些都是在onVsync回调方法里边进行统一的处理；同时它也负责对Vsync信号的请求。接下来，我们通过源码来了解它的工作原理。

1.注册：

我们都知道，每当要接收某个回调事件，都需要提前进行注册。Choreographer是怎么去进行注册的呢？

在了解之前，我们先看看Choreographer是怎么被创建出来的：

public static Choreographer getInstance() {
   
    return sThreadInstance.get();
}
private static final ThreadLocal<Choreographer> sThreadInstance =
            new ThreadLocal<Choreographer>() {
   
        @Override
        protected Choreographer initialValue() {
   
            Looper looper = Looper.myLooper();
            if (looper == null) {
   
                throw new IllegalStateException("The current thread must have a looper!");
            }
            Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
            if (looper == Looper.getMainLooper()) {
   
                mMainInstance = choreographer;
            }
            return choreographer;
        }
    };

可以看出它是一个线程单例，并且需要有looper与之绑定。

它的构造方法：

private Choreographer(Looper looper, int vsyncSource) {
   
    mLooper = looper;
    mHandler = new FrameHandler(looper);