从Android4.1开始，Google引入了Project Butter，即“黄油计划”。目的是改善用户抱怨最多的系统缺陷：UI响应速度，Google希望这一新计划可以让Android系统摆脱UI交互上给人带来的滞后感，而能像黄油一样顺滑。 Project Butter对Android Display系统进行了重构，引入了三个核心元素：VSync、Triple Buffer和Choreographer。今天我们主要看下VSync信号的来龙去脉。

VSync信号的产生

VSync信号是由HWC硬件模块根据屏幕刷新率产生。DispSync是VSync事件核心类，根据HWC产生的硬件VSync信号，训练了一个模拟的VSync事件源，并且通过内部的DispSyncThread线程向外分发DispSync::Callback回调，DispSyncSource就是实现了该回调接口。为了处理VSync信号，SurfaceFlinger启动了两个EventThread线程：

mEventThread：服务于客户端APP UI渲染。
mSFEventThread：服务于SurfaceFlinger合成和上屏。

两个VSync线程在SurfaceFlinger::init中完成初始化，如下所示：

 // start the EventThread vsyncSrc 表示渲染用的Vsync
sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync, vsyncPhaseOffsetNs, true, "app");
// 客户端UI渲染使用的VSync线程
mEventThread = new EventThread(vsyncSrc, *this);
// sfVsyncSrc表示SF合成用的VSync
sp<VSyncSource> sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync, sfVsyncPhaseOffsetNs, true, "sf"); 
// SF使用的VSync线程
mSFEventThread = new EventThread(sfVsyncSrc, *this);
//MessageQueue向SF的EventThread注册监听器
mEventQueue.setEventThread(mSFEventThread);

DispSyncSource实现了DispSync::Callback回调接口，可以从DispSync接收VSync事件。上述代码创建了两个DispSyncSource对象，vsyncSrc是给CPU服务，驱动客户端APP UI线程渲染；sfVsyncSrc是给GPU服务，驱动SF主线程合成上屏。两个DispSyncSource分别指定了不同的时间戳偏移量（相对于标准的VSync时间戳），可以精细控制VSync的回调时机，通过adb shell dumpsys SurfaceFlinger可以查看这两个偏移量（后面详细介绍）：

// app phase就是vsyncSrc偏移量，sf phase是sfVsyncSrc偏移量，refresh是主屏的刷新周期
DispSync configuration: app phase 1000000 ns, sf phase 1000000 ns, early sf phase 1000000 ns, present offset 0 ns (refresh 16666666 ns)

每个DispSyncSource对象与一个EventThread相关联，DispSync的VSync事件会通过DispSyncSource传递到EventThread::onVSyncEvent，再通过EventThread::Connection向外分发。

基于DispSync的VSync架构如下所示：

DispSync借助硬件VSync（HW_VSYNC）训练了一个模拟的VSync模型（SW-VSYNC）。
模拟的VSync模型为驱动APP绘制的VSync信号添加了时间戳偏移（phase-app），生成了Vsync-app事件。
模拟的VSync模型为驱动SF合成的VSync信号添加了时间戳偏移（phase-sf），生成了Vsync-sf事件。
Vsync-app和Vsync-sf是外界真正接触到的VSync事件。
addPresentFence用来检查模拟的VSync模型与硬件VSync之间是否超过了一定误差，若是，则需要重启硬件Vsync，训练新的VSync模型。

下面详细看下DispSync是如何训练出模拟的VSync事件？在Android图形系统系统篇之HWC一文中，我们提到HWC2::Device构造函数会通过Device::registerCallbacks向显示设备注册三个Display回调：热插拔，刷新和VSync信号，这里的显示设备就是hwc2_device_t。所以，VSync信号的起源是hwc2_device_t，然后经过一系列回调到达SurfaceFlinger.onVSyncReceived方法。onVSyncReceived通过addResyncSample方法把硬件VSync时间戳交给DispSync，训练一个模拟的VSync事件模型。addResyncSample主要逻辑：

几个关键变量：mReferenceTime记录第一个硬件VSync时间戳；mResyncSamples存储所有硬件Vsync时间戳（数组长度为NUM_PRESENT_SAMPLES，目前为32）；mNumResyncSamples表示参与计算的时间戳个数。在时间戳个数达到MIN_RESYNC_SAMPLES_FOR_UPDATE（常量，目前为6）时，会触发真正的模型计算updateModelLocked。
计算过程：首先，计算出相邻时间戳时间差的均值（排除了最大和最小值），作为模拟的Vsync的时间周期mPeriod（这个值理论上等于16.66666...ms）；然后根据每个硬件时间戳相比于mPeriod的偏差，计算出平均偏差mPhase，范围是(-mPeriod/2 , mPeriod/2]；最后把mPeriod、mPhase和mReferenceTime设置给DispSyncThread线程。
DispSyncThread线程根据上面计算出的mPeriod、mPhase、mReferenceTime以及每个DispSync::Callback要求的Phase，定时回调每个Callback，其中Callback的时间戳参数，不是系统时间，而是基于第一个硬件Vsync时间戳mReferenceTime计算出来的。
如果训练的模拟VSync时间戳与硬件VSync时间戳在一定的误差范围内，则addResyncSample返回false，表示模拟的硬件VSync模型已经OK，不再需要硬件VSync时间戳了，否则返回true，表示需要更多的硬件VSync时间戳来训练模型。
如果DispSync检测到硬件VSync与模拟的VSync模型之间存在较大误差，则会重新训练新的VSync模型。

核心代码如下所示：

// 收到HWComposer的Vsync信号
void SurfaceFlinger::onVSyncReceived(int32_t type, nsecs_t timestamp) {
    bool needsHwVsync = false;
    { // Scope for the lock
        Mutex::Autolock _l(mHWVsyncLock);
        // type为0，表示主显示屏
        if (type == 0 && mPrimaryHWVsyncEnabled) { 
            // 训练模型，返回false，则表示模型训练成功
            needsHwVsync = mPrimaryDispSync.addResyncSample(timestamp); 
        }
    }

    if (needsHwVsync) {
        enableHardwareVsync();
    } else { // 关闭硬件VSync
        disableHardwareVsync(false);
    }
}
// DispSyncThread线程注册的监听器
 struct EventListener {
    const char* mName; 
    nsecs_t mPhase; // 时间戳偏移量
    nsecs_t mLastEventTime; // 上次VSync事件的时间戳
    sp<DispSync::Callback> mCallback; // 对应的回调，即DispSyncSource
    };

为了控制硬件VSync的打开与关闭，专门提供了一个线程EventControlThread，当内部的mVsyncEnabled状态改变时，会调用到下面的SurfaceFlinger::setVsyncEnabled方法：

void SurfaceFlinger::setVsyncEnabled(int disp, int enabled) {
    // 打开 or 关闭HWC VSync，最终调用到下面的 Display::setVsyncEnabled
    getHwComposer().setVsyncEnabled(disp,
            enabled ? HWC2::Vsync::Enable : HWC2::Vsync::Disable);
}
// 硬件模块
Error Display::setVsyncEnabled(Vsync enabled)
{
    auto intEnabled = static_cast<int32_t>(enabled);
    // 打开 or 关闭HWC VSync
    int32_t intError = mDevice.mSetVsyncEnabled(mDevice.mHwcDevice, mId, intEnabled);
    return static_cast<Error>(intError);
}

此外，必须在屏幕亮着时，硬件VSync才能工作，否则只能依赖训练好的模拟硬件VSync，甚至需要在EventThread中通过软件方式进行VSync兜底（后面会介绍），下面是屏幕打开和关闭的逻辑：

void SurfaceFlinger::setPowerModeInternal(const sp<DisplayDevice>& hw, int mode){
    int32_t type = hw->getDisplayType();
    // current hwc power mode
    int currentMode = hw->getPowerMode();
    if (mode == currentMode) {
        return;
    }
    
    if (currentMode == HWC_POWER_MODE_OFF) { 
        getHwComposer().setPowerMode(type, mode);
        if (type == DisplayDevice::DISPLAY_PRIMARY) {
            // 通知为客户端服务的EventThread：显示器打开了
            mEventThread->onScreenAcquired(); 
            // 显示器打开后，需要重新基于硬件VSync信号，训练软件VSync
            resyncToHardwareVsync(true);
        }
        mHasPoweredOff = true;
        repaintEverything();
    } else if (mode == HWC_POWER_MODE_OFF) {
        if (type == DisplayDevice::DISPLAY_PRIMARY) {
            // 显示器关闭了，则关闭硬件VSync，停止软件VSync训练
            disableHardwareVsync(true); // also cancels any in-progress resync
           // 通知为客户端服务的EventThread：显示器关闭了
            mEventThread->onScreenReleased(); 
        }

        getHwComposer().setPowerMode(type, mode);
        // from this point on, SF will stop drawing on this display
    } else {
        getHwComposer().setPowerMode(type, mode);
    }
}

为什么屏幕的打开与关闭只通知了mEventThread，而没通知mSFEventThread，因为前者是为客户端进程服务，即使主屏幕关闭了，客户端依然要依赖VSync事件做一些工作，所以在mEventThread中必须通过软件的方式为VSync事件兜底（就是等待模拟的硬件VSync 16ms，若超时了，就使用系统时间戳）。而后者是为SurfaceFlinger的合成上屏服务，当对应的屏幕关闭后，就不再需要上屏了，所以mSFEventThread就可以不工作了。

adb shell dumpsys SurfaceFlinger可以查看mEventThread的dump信息，如下所示：

// 是否在使用VSync，可能是硬件VSync，也可能是EventThread的软件VSync
VSYNC state: enabled
    // 当屏幕亮着的，就是disabled，如果关闭屏幕，这里为enabled
  soft-vsync: disabled
    // 表示感兴趣的Connection的个数
  numListeners=90,
   // 表示接收到的VSync的累加值（包括硬件VSync和EventThread的软件VSync）
  events-delivered: 181752
    // 下面是具体Connection的count，-1表示该Connection不会接收VSync信号，Connection->count的具体含义下面👇会详细介绍。
    0x76fa631480: count=-1
    0x76fa633d00: count=-1
    ......

如果模拟的硬件VSync事件（DispSyncThread产生）是正常的，那么EventThread::onVSyncEvent负责接收VSync事件，并更新vsync.count计数和header.timestamp时间戳。

// 接收到DispSyncSource传过来的VSync信号
void EventThread::onVSyncEvent(nsecs_t timestamp) {
    Mutex::Autolock _l(mLock);
    // 表示VSync事件，也可能是热插拔事件
    mVSyncEvent[0].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
    mVSyncEvent[0].header.id = 0;
    // 更新VSync时间戳
    mVSyncEvent[0].header.timestamp = timestamp; 
    // VSync的累加计数，即dump信息中的events-delivered值
    mVSyncEvent[0].vsync.count++;
    mCondition.broadcast();
}

如果屏幕关闭了，那么在EventThread::waitForEvent中通过Condition.waitRelative为VSync信号兜底，核心代码如下所示：

// SurfaceFlinger通知屏幕关闭了，模拟的硬件VSync信号可能不准，需要使用软件模拟，即16ms
void EventThread::onScreenReleased() {
    Mutex::Autolock _l(mLock);
    if (!mUseSoftwareVSync) {
        // disable reliance on h/w vsync
        mUseSoftwareVSync = true;
        mCondition.broadcast();
    }
}
// SurfaceFlinger通知屏幕打开了，不再需要使用软件模拟VSync
void EventThread::onScreenAcquired() {
    Mutex::Autolock _l(mLock);
    if (mUseSoftwareVSync) {
        // resume use of h/w vsync
        mUseSoftwareVSync = false;
        mCondition.broadcast();
    }
}

// 下面是EventThread::waitForEvent中产生软件VSync的地方
bool softwareSync = mUseSoftwareVSync;
// 如果屏幕没关闭，那么继续等待模拟的硬件VSync信号（超时时间为1S），否则等待时间为16ms。在waitRelative期间，如果模拟的硬件VSync信号到了，那么就继续使用模拟的硬件VSync，否则就自己更新vsync.count和`header.timestamp`时间戳。
nsecs_t timeout = softwareSync ? ms2ns(16) : ms2ns(1000);
if (mCondition.waitRelative(mLock, timeout) == TIMED_OUT) {
// 这里的代码块是处理等待超时的情况，即模拟的硬件VSync信号在16ms内没到达，就需要软件模拟了
    if (!softwareSync) {
        // 硬件Vsync失效了，下面是模拟的Vsync信号
        ALOGW("Timed out waiting for hw vsync; faking it"); 
    }
    mVSyncEvent[0].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
    mVSyncEvent[0].header.id = DisplayDevice::DISPLAY_PRIMARY;
    // 软件方式，更新为系统时间戳
    mVSyncEvent[0].header.timestamp = systemTime(SYSTEM_TIME_MONOTONIC);
     mVSyncEvent[0].vsync.count++;
}

屏幕关闭后，DispSyncThread线程还在继续发送模拟的硬件VSync事件，所以正常情况下，还是通过EventThread::onVSyncEvent更新vsync.count计数和header.timestamp时间戳。只有在超过16ms，没有接收到模拟的硬件VSync时，系统才会主动更新vsync.count计数和header.timestamp时间戳。

针对服务于CPU的mEventThread，vsync.count计数和header.timestamp时间戳一般情况下都是通过EventThread::onVSyncEvent方法来更新，若屏幕关闭了，并且在16ms内EventThread::onVSyncEvent方法未更新VSync信息，那么就在EventThread::waitForEvent中主动更新VSync信息。而针对服务于GPU的mSFEventThread，只会通过EventThread::onVSyncEvent方法更新vsync.count计数和header.timestamp时间戳。

总结下：不管是服务于CPU的mEventThread，还是服务于GPU的mSFEventThread，都是通过DispSyncSource接收模拟的硬件VSync事件。差异点在于，当有EventThread::Connection请求了VSync事件，但是此时又没有VSync时，waitRelative等待超时的时间是不同的：在屏幕亮着的情况是1000ms，而屏幕关闭后则是16ms。而SurfaceFlinger只会通知mEventThread屏幕的打开与关闭。所以mSFEventThread等待超时的时间只能是1000ms。

上文中有提到vsync.count计数和EventThread::Connection.count值，它们主要是控制通知EventThread::Connection的频率，当VSync信号到来时，vsync.count会不断累加，比较简单。而EventThread::Connection.count的取值主要分为三类：

count >= 1 ：当vsync.count % count为0时，通知对应的EventThread::Connection
count == 0 ：可以通知对应的EventThread::Connection，但是立即赋值为-1，表示下次不再继续通知
count ==-1 : 不会通知对应的Connection

核心代码在waitForEvent中，如下所示：

// 根据count决定对应的connection是否应该被通知，signalConnections是收集需要通知的connection列表。
if (connection->count == 0) {
    // 此次通知，下次就不通知VSync事件了
    connection->count = -1;
    signalConnections.add(connection);
    added = true;
} else if (connection->count == 1 || (vsyncCount % connection->count) == 0) {
    // continuous event, and time to report it 持续的VSync事件
    signalConnections.add(connection);
    added = true;
}

EventThread::Connection提供了setVsyncRate和requestNextVsync方法修改这个count，最终会调用到EventThread对应的方法，如下所示：

// 设置指定Connection接收VSync事件的固定频率
void EventThread::setVsyncRate(uint32_t count, const sp<EventThread::Connection>& connection) {
    if (int32_t(count) >= 0) { 
        Mutex::Autolock _l(mLock);
        const int32_t new_count = (count == 0) ? -1 : count;
        if (connection->count != new_count) {
            // 更新connection->count
            connection->count = new_count;
            mCondition.broadcast();
        }
    }
}
// 请求接收下一次的VSync事件，请求一次，接收下一次VSync
void EventThread::requestNextVsync(
        const sp<EventThread::Connection>& connection) {
    Mutex::Autolock _l(mLock);
    mFlinger.resyncWithRateLimit();
    // 更新connection->count
    if (connection->count < 0) {
        connection->count = 0;
        mCondition.broadcast();
    }
}

setVsyncRate只需要指定一次，后续根据vsync.count % connection->count == 0来接收VSync事件

requestNextVsync则是请求下一次VSync事件，请求一次，接收一次，View.invalidate和SF合成，都是使用这种方式。

上文有提到，当模拟的VSync模型与硬件VSync在一定误差内时，会关闭硬件VSync。那么随着时间推移，如果误差越来越大，如何调整模拟的硬件VSync模型那？原来，SurfaceFlinger在处理Layer合成的最后一步（handleMessageRefresh -> postComposition）会通过addPresentFence把Present Fence交给DispSync, DispSync会检查Present Fence与模拟的VSync周期之间的误差，若误差偏大就会打开HWCVSync，重新走addResyncSample训练逻辑。核心代码如下所示：

// handleMessageRefresh -> postComposition
void SurfaceFlinger::postComposition(){
    const HWComposer& hwc = getHwComposer();
    sp presentFence = hwc.getDisplayFence(HWC_DISPLAY_PRIMARY);
    if (presentFence->isValid()) {
        if (mPrimaryDispSync.addPresentFence(presentFence)) {
            // 打开HWC VSync，重新训练DispSync的VSync模型
            enableHardwareVsync();
        } else {
            // 关闭HWC VSync
            disableHardwareVsync(false);
        }
    }
}

// 添加Present Fence，检查VSync模型误差
bool DispSync::addPresentFence(const sp<Fence>& fence) {
    // 保存Present Fence，最大长度为NUM_PRESENT_SAMPLES，目前是8
    mPresentFences[mPresentSampleOffset] = fence;
    mPresentTimes[mPresentSampleOffset] = 0;
    mPresentSampleOffset = (mPresentSampleOffset + 1) % NUM_PRESENT_SAMPLES;
    mNumResyncSamplesSincePresent = 0;
    for (size_t i = 0; i < NUM_PRESENT_SAMPLES; i++) {
        const sp<Fence>& f(mPresentFences[i]);
        if (f != NULL) {
            nsecs_t t = f->getSignalTime();
            if (t < INT64_MAX) {
                mPresentFences[i].clear();
                // 记录Present Fence的时间戳
                mPresentTimes[i] = t + kPresentTimeOffset;
            }
        }
    }
    // 检查误差
    updateErrorLocked();
    // 若误差超过一定阈值，则返回true，表示需要重启硬件VSync
    return !mModelUpdated || mError > kErrorThreshold;
}
// 检查已经保存的Present Fence与现有VSync周期的均方误差
void DispSync::updateErrorLocked() {
    // Need to compare present fences against the un-adjusted refresh period, since they might arrive between two events.
    nsecs_t period = mPeriod / (1 + mRefreshSkipCount);
    int numErrSamples = 0;
    nsecs_t sqErrSum = 0;
    for (size_t i = 0; i < NUM_PRESENT_SAMPLES; i++) {
        // mReferenceTime表示之前记录的第一个硬件VSync时间戳
        nsecs_t sample = mPresentTimes[i] - mReferenceTime;
        if (sample > mPhase) {
            // 相对于现有VSync周期的误差
            nsecs_t sampleErr = (sample - mPhase) % period;
            if (sampleErr > period / 2) {
                sampleErr -= period;
            }
            // 求取误差平方和
            sqErrSum += sampleErr * sampleErr;
            numErrSamples++;
        }
    }
    // 计算出均方误差
    if (numErrSamples > 0) {
        mError = sqErrSum / numErrSamples;
    } else {
        mError = 0;
    }
}

当DispSync收到addPresentFence添加的Present Fence时(目前最多8个)，会计算出Present Fence与现有VSync周期的均方误差，若均方误差超过常量：kErrorThreshold = 160000000000，就会打开硬件VSync，重新训练DispSync模拟的硬件VSync模型。

最后，总结下VSync模型的运转流程：当HWC发出VSync信号时，SurfaceFlinger将会收到回调并且发送给DispSync。DispSync将会记录这些硬件VSync时间戳，当累计了足够的硬件VSync以后（目前是大于等于6个），就开始计算VSync周期和偏移：mPeriod和mPhase。DispSyncThread将会利用mPeriod和mPhase模拟硬件VSync，并且通知对VSync感兴趣的Listener，这些Listener包括SurfaceFlinger和客户端APP。这些Listener以Connection形式注册到EventThread。DispSyncThread与EventThread通过DispSyncSource作为中间人进行连接。EventThread收到模拟的硬件VSync后，将会通知所有感兴趣的Connection，然后SurfaceFlinger开始合成，APP开始渲染。当收到足够多的硬件VSync并且在误差允许范围内，将会通过EventControlThread关闭HWC的硬件VSync。通过流程图表示如下：

OK，上述分析了VSync事件的起源和分发逻辑，下面我们详细看下VSync事件的两种使用场景：一个是驱动SurfaceFlinger合成上屏；一个是驱动客户端APP UI渲染。

驱动`SurfaceFlinger`合成上屏

上文SurfaceFlinger::init代码中完成了MessageQueue与mSFEventThread的绑定，即MessageQueue向mSFEventThread注册了EventThread::Connection，并通过BitTube监听Connection写入的事件（通过EventThread::Connection::postEvent写事件到BitTube），例如：VSync和热插拔事件。核心代码如下所示：

// 主线程`MessageQueue`绑定`mSFEventThread`，
void MessageQueue::setEventThread(const sp<EventThread>& eventThread)
{
    mEventThread = eventThread;
    // 创建EventThread::Connection
    mEvents = eventThread->createEventConnection();
    mEventTube = mEvents->getDataChannel();
    // 监听BitTube的方式（用Looper），一旦有数据到来则调用cb_eventReceiver()，this表示透传的参数
    mLooper->addFd(mEventTube->getFd(), 0, Looper::EVENT_INPUT,
            MessageQueue::cb_eventReceiver, this);
}
// 接收EventThread的VSync事件，分发到MessageQueue线程
int MessageQueue::cb_eventReceiver(int fd, int events, void* data) {
    MessageQueue* queue = reinterpret_cast<MessageQueue *>(data);
    return queue->eventReceiver(fd, events);
}
// 创建的Connection在第一次被引用时，才会注册到EventThread
void EventThread::Connection::onFirstRef() {
    // 当第一次引用Connection时，就会把它添加到所属EventThread维护的Connection队列
    mEventThread->registerDisplayEventConnection(this);
}

OK，MessageQueue向mSFEventThread注册EventThread::Connection后，就可以接收VSync事件了，那么SurfaceFlinger是一直接收VSync事件，还是按需请求的那？还记得上面介绍的connection->count吗？实际上是通过Connection::requestNextVsync按需请求的，这个“按需”就是指有Layer更新了。这里我们通过两个时序图详细看下：

驱动SurfaceFlinger合成上屏的VSync是什么时候请求的：

SurfaceFlinger是怎么接收VSync信号的：

当View.invalidate调用后，最终会触发ViewRootImpl向SurfaceFlinger的mEventThread请求接收下一次的VSync事件（后面详细介绍）。
客户端收到VSync事件后，最终通过performTraversals触发View体系的绘制。
这里以软件绘制为例，通过Surface拿到Canvas，Canvas底层实际对应的是从SurfaceFlinger申请的GraphicBuffer。当Canavs绘制完成后，通过Surface.unlockCanvasAndPost触发GraphicBuffer的入队流程，即通过BufferQueueProducer把GraphicBuffer入队到`BufferQueue。
入队后，通过BufferQueueCore中的mConsumerListener回调一步步通知到SurfaceFlinger。
SurfaceFlinger通过MessageQueue向mSFEventThread请求下一次的VSync信号。
Vsync到来后，通过MessageQueue分发到SurfaceFlinger主线程，并且最终通过handleMessageRefresh进行Layer的合成与上屏。

驱动客户端APP UI渲染

同样的，驱动客户端APP UI渲染的VSync逻辑，也可以分为客户端请求VSync信号和客户端接收VSync信号，一样可以通过两个时序图来看下：

客户端请求VSync：

客户端接收VSync:

客户端APP怎么请求VSync事件那？实际是View请求重绘时，通过Choreographer向SurfaceFlinger的mEventThread线程请求接收下一次的VSync事件。

当View.invalidate调用后，最终会触发ViewRootImpl向Choreographer注册一个TraversalRunnable。
Choreographer本地保存这个TraversalRunnable后，会通过DisplayEventReceiver.java调用到Native层，最终一步步调用到mEventThread线程，修改connection->count = 0(请求接收下一次VSync)。
Vsync到来后，会从SurfaceFlinger进程一步步回调到客户端进程，最终触发ViewRootImpl之前注册TraversalRunnable，启动View树的渲染。

那么这里的EventThread::Connection是怎么注册到mEventThread线程的那？其实在创建DisplayEventReceiver就已经完成了注册，如下所示：

// DisplayEventReceiver的构造函数
DisplayEventReceiver::DisplayEventReceiver() {
    // 跨进程获取SurfaceFlinger句柄
    sp<ISurfaceComposer> sf(ComposerService::getComposerService());
    if (sf != NULL) {
        // 向SurfaceFlinger的mEventThread线程注册Connection
        mEventConnection = sf->createDisplayEventConnection();
        if (mEventConnection != NULL) {
            // 需要监听的句柄
            mDataChannel = mEventConnection->getDataChannel();
        }
    }
}
// 添加感兴趣的Connection到mEventThread线程，用于通知客户端APP VSync事件
sp<IDisplayEventConnection> SurfaceFlinger::createDisplayEventConnection() {
    return mEventThread->createEventConnection();
}

VSync偏移

在基于VSync的渲染模型中，涉及到三个组件：APP、SurfaceFlinger和Display，它们都是在VSync到来时开始工作。假如我们请求了View重绘，那么整个渲染流程如下所所示：

View.invalidate请求重绘，通过Choreographer请求接收下一个VSync信号。
第一个VSync信号到来时，View开始绘制，绘制完成后通过BufferQueue通知到SurfaceFlinger，SurfaceFlinger通过MessageQueue请求接收下一个VSync信号。
第二个VSync信号到来时，SurfaceFlinger开始合成Layer，并把结果交给HWC。
第三个VSync信号到来时，Display开始展示合成好的图像数据。

同时需要注意到：屏幕开始显示帧N时，SurfaceFlinger开始为帧N+1合成Layer，客户端开始处理View渲染并生成帧N+2，即：从View绘制到显示在屏幕上，延迟至少为两帧，大概33ms。

但是对大部分场景来说，APP渲染+SurfaceFlinger合成可能在16ms内就可以完成。为了缩短帧延迟，可以在设备的BoardConfig.mk文件中为驱动APP渲染和SurfaceFlinger合成的VSync信号分别配置时间戳偏移：VSYNC_EVENT_PHASE_OFFSET_NS 和SF_VSYNC_EVENT_PHASE_OFFSET_NS（即SurfaceFlinger::init中创建DispSyncSource时传入的vsyncPhaseOffsetNs与sfVsyncPhaseOffsetNs偏移）。若不设置，则默认都是0，即相对于模拟的硬件VSync信号，都没有时间戳偏移。

VSync-App（驱动APP的VSync） = HW_VSync_0 + phase-app
VSync-sf（驱动SurfaceFlinger的VSync） = HW_VSync_0 + phase-sf

理想情况下，App可以在phase-sf - phase-app时间内完成绘制，SurfaceFlinger可以在VSync周期 - phase-sf时间内完成合成，那么在下一个VSync信号时就可以上屏，即帧延迟为16ms。但是若APP绘制耗时超过了phase-sf - phase-app，那就只能等到下一个VSync-sf信号才能开始合成，即等待SurfaceFlinger开始合成的时间由VSync周期变成了VSync周期 + phase-sf - phase-app，若同时SurfaceFlinger的合成耗时超过了VSync周期 - phase-sf，那么就要再等下一个VSync才能上屏，整体延迟了3帧，即将近50ms。所以一般情况下，系统都会将phase-sf - phase-app设置为VSync周期。

总结

本文主要介绍了VSync信号的来龙去脉，以及驱动客户端APP渲染和SurfaceFlinger合成上屏的逻辑。

参考文章