前言：

vsync信號(hào)其實(shí)主要有兩種，APP和SF兩種。

(資料圖)

兩種類(lèi)似的信號(hào)分別具有以下的作用：

1.APP類(lèi)型，我們常說(shuō)的Vsync信號(hào)其實(shí)指的就是這種類(lèi)型。

2.SF類(lèi)型，我感覺(jué)有可能是SurfaceFlinger的縮寫(xiě)，這個(gè)同步信號(hào)主要是通知進(jìn)行數(shù)據(jù)buffer的合成。

本文主要探討的主APP類(lèi)型的Vsync信號(hào)，SF類(lèi)型的會(huì)在另外一篇文章，View繪制流程中講解。

一.整體流程簡(jiǎn)介

我把a(bǔ)pp-VSync的整個(gè)流程分為四大塊：

第一塊，APP側(cè)發(fā)出請(qǐng)求信號(hào)，通知到SurfaceFlinger；

第二塊，SurfaceFlinger收到通知后，作為消費(fèi)者側(cè)去緩存池中查詢(xún)是否存在VSYNC，如果有，則通知APP側(cè)。

第三塊，SurfaceFlinger中的生產(chǎn)者邏輯，生產(chǎn)下一次的Vsync信號(hào)。

第四塊，APP側(cè)收到Vsync信號(hào)后進(jìn)行處理，最終完成繪制流程。

整體的流程圖如下圖所示，后續(xù)文章也會(huì)按照這四大塊流程去細(xì)講。

二.客戶(hù)端發(fā)出信號(hào)

2.1 java端流轉(zhuǎn)

我們把代碼的開(kāi)始點(diǎn)設(shè)置為ViewRootImpl中的scheduleTraversals方法，如果想了解這個(gè)方法之前的流程，可以參看我的另外一篇文章：

View繪制流程2-安卓是如何執(zhí)行measure/layout/draw三個(gè)繪制流程_失落夏天的博客-CSDN博客

scheduleTraversals是負(fù)責(zé)渲染流程的，界面上任何布局上的改動(dòng)，最終都會(huì)執(zhí)行這個(gè)方法進(jìn)行刷新操作。scheduleTraversals會(huì)通過(guò)Choreographer的postCallback方法去請(qǐng)求Vsync信號(hào)并且設(shè)置回調(diào)方法。

mChoreographer.postCallback(                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);

Choreographer中的最終實(shí)現(xiàn)是postCallbackDelayedInternal方法：

private void postCallbackDelayedInternal(int callbackType,            Object action, Object token, long delayMillis) {        ...        synchronized (mLock) {            final long now = SystemClock.uptimeMillis();            final long dueTime = now + delayMillis;            mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);            if (dueTime <= now) {                scheduleFrameLocked(now);            }            ...        }    }

這個(gè)方法會(huì)把回調(diào)加入到mCallbackQueues中，然后通過(guò)scheduleFrameLocked方法開(kāi)始請(qǐng)求Vsync信號(hào)。

scheduleFrameLocked中又會(huì)進(jìn)行層層傳遞，最終調(diào)用到native方法。傳遞關(guān)系如下：

scheduleFrameLocked(Choreographer.java)->scheduleVsyncLocked(Choreographer.java)->scheduleVsync(DisplayEventReceiver.java)->nativeScheduleVsync(DisplayEventReceiver.java)

2.2 native方法中的邏輯流轉(zhuǎn)

nativeScheduleVsync在native層的注冊(cè)是DisplayEventReceiver.cpp中的nativeScheduleVsync方法，方法中通過(guò)NativeDisplayEventReceiver的scheduleVsync來(lái)完成請(qǐng)求：

static void nativeScheduleVsync(JNIEnv* env, jclass clazz, jlong receiverPtr) {    spreceiver =            reinterpret_cast(receiverPtr);    status_t status = receiver->scheduleVsync();   ...}

NativeDisplayEventReceiver是DisplayEventDispatcher的子類(lèi)，scheduleVsync方法會(huì)執(zhí)行到DisplayEventDispatcher中的scheduleVsync方法，調(diào)用DisplayEventReceiver的requestNextVsync繼續(xù)請(qǐng)求流程。

status_t DisplayEventDispatcher::scheduleVsync() {    if (!mWaitingForVsync) {        ...        status_t status = mReceiver.requestNextVsync();        ...        mWaitingForVsync = true;        ...    }    return OK;}

這里有一個(gè)本地變量mWaitingForVsync，如果請(qǐng)求了一次sync，就會(huì)改為true，接下來(lái)的Vsync請(qǐng)求，都不會(huì)傳輸?shù)絊urfaceFlinger一層了，避免重復(fù)無(wú)意義請(qǐng)求。只有等到收到Vsync信號(hào)的時(shí)候，才會(huì)改為false。

DisplayEventReceiver中，會(huì)交給mEventConnection處理：

status_t DisplayEventReceiver::requestNextVsync() {    if (mEventConnection != nullptr) {        mEventConnection->requestNextVsync();        return NO_ERROR;    }    return NO_INIT;}

mEventConnection其實(shí)是一個(gè)binder客戶(hù)端，是在創(chuàng)建DisplayEventReceiver的時(shí)候通過(guò)binder方法創(chuàng)建的，其binder服務(wù)端實(shí)現(xiàn)在SurfaceFlinger進(jìn)程側(cè)的EventThread.cpp。

DisplayEventReceiver::DisplayEventReceiver(        ISurfaceComposer::VsyncSource vsyncSource,        ISurfaceComposer::EventRegistrationFlags eventRegistration) {    spsf(ComposerService::getComposerService());    if (sf != nullptr) {        mEventConnection = sf->createDisplayEventConnection(vsyncSource, eventRegistration);        ...    }}

三.SurfaceFlinger端Vsync信號(hào)消費(fèi)者

首先，SurfaceFlinger的總體結(jié)構(gòu)圖如下，SurfaceFlinger中存在一個(gè)Scheduler，Scheduler中存在多個(gè)VsyncDispatch。其中VSYNC-app負(fù)責(zé)所有APP的VSYNC信號(hào)的處理，本文主要講的也是這個(gè)流程中的。

其次，下圖是主流程圖中的一部分，也是本章要講的內(nèi)容。

3.1 EventThread收到通知后，轉(zhuǎn)發(fā)EventThread的工作線(xiàn)程

是接收方法如下，轉(zhuǎn)發(fā)到mEventThread的requestNextVsync方法中。

binder::Status EventThreadConnection::requestNextVsync() {    ATRACE_CALL();    mEventThread->requestNextVsync(this);    return binder::Status::ok();}

我們接著看一下EventThread中的requestNextVsync方法：

void EventThread::requestNextVsync(const sp& connection) {    ...    if (connection->vsyncRequest == VSyncRequest::None) {        connection->vsyncRequest = VSyncRequest::Single;        mCondition.notify_all();    } else if (connection->vsyncRequest == VSyncRequest::SingleSuppressCallback) {        connection->vsyncRequest = VSyncRequest::Single;    }}

這里的邏輯很簡(jiǎn)單，如果當(dāng)前的VSYNC狀態(tài)是None的話(huà)，釋放鎖mCondition。

這里既然notify_all，那么一定有地方wait等待鎖，而等待的地方就是threadMain方法。

3.2 threadMain方法

這個(gè)方法算是整個(gè)Vsync流程的核心，它是一個(gè)無(wú)限循環(huán)的模式，其作用是不斷的從mPendingEvents中獲取Vsync信號(hào)，然后轉(zhuǎn)交給APP端。并且在一次Vsync流程結(jié)束后，又通過(guò)VsyncSource請(qǐng)求下一次的Vsync信號(hào)。

threadMain方法是EventThread類(lèi)初始化的時(shí)候創(chuàng)建的線(xiàn)程去執(zhí)行的方法：

mThread = std::thread([this]() NO_THREAD_SAFETY_ANALYSIS {        std::unique_locklock(mMutex);        threadMain(lock);    });

我們看一下精簡(jiǎn)后的threadMain方法：

void EventThread::threadMain(std::unique_lock& lock) {    DisplayEventConsumers consumers;    //只要沒(méi)有退出，就一直循環(huán)    while (mState != State::Quit) {        執(zhí)行以下1-7的操作           }}

總體來(lái)說(shuō)，分為以下四大步驟：

1.作為消費(fèi)者嘗試從mPendingEvents中獲取Vsync信號(hào)，如果獲取成功，則賦值給event。

std::optionalevent;        //查看mPendingEvents中是否存在Vsync信號(hào)        if (!mPendingEvents.empty()) {            event = mPendingEvents.front();            mPendingEvents.pop_front();            ...        }

2.計(jì)算vsyncRequested的狀態(tài)，只要客戶(hù)端消費(fèi)者的Connection保持連接，則vsyncRequested=true，并且上面步驟一獲取到event的話(huà)，則把消費(fèi)者的connection加入到consumers集合中。

bool vsyncRequested = false;       //獲取當(dāng)前的狀態(tài)，并且判斷是否有客戶(hù)端的消費(fèi)者在請(qǐng)求，如果有則加入到consumers集合中        auto it = mDisplayEventConnections.begin();        while (it != mDisplayEventConnections.end()) {            if (const auto connection = it->promote()) {                //客戶(hù)端還是處于請(qǐng)求的狀態(tài)                vsyncRequested |= connection->vsyncRequest != VSyncRequest::None;                if (event && shouldConsumeEvent(*event, connection)) {                    consumers.push_back(connection);                }                ++it;            } else {                it = mDisplayEventConnections.erase(it);            }        }

3.如果consumers集合不為空，則進(jìn)行消費(fèi)。把Vsync信號(hào)分發(fā)給消費(fèi)者。（具體步驟我們下一小節(jié)中講）

//如果消費(fèi)者不為空，則通過(guò)dispatchEvent方法最終通知到APP一側(cè)        if (!consumers.empty()) {            dispatchEvent(*event, consumers);            consumers.clear();        }

4.獲取下一個(gè)狀態(tài)

//mVSyncState不會(huì)為空，則主要是根據(jù)vsyncRequested來(lái)判斷的。vsyncRequested上面計(jì)算的        State nextState;        if (mVSyncState && vsyncRequested) {            nextState = mVSyncState->synthetic ? State::SyntheticVSync : State::VSync;        } else {            ALOGW_IF(!mVSyncState, "Ignoring VSYNC request while display is disconnected");            nextState = State::Idle;        }

5.進(jìn)行判斷，確定是否需要請(qǐng)求VSYNC信號(hào)。這一塊挺有意思的，簡(jiǎn)單理解如下：

如果當(dāng)前是VSYNC狀態(tài)，下一個(gè)狀態(tài)也是VSYNC狀態(tài)，那么說(shuō)明信號(hào)還沒(méi)來(lái)，所以沒(méi)必要重復(fù)發(fā)送。

如果當(dāng)前是Idle狀態(tài)，下一個(gè)狀態(tài)是VSYNC狀態(tài)，那么則要進(jìn)行VSYNC信號(hào)請(qǐng)求。

如果當(dāng)前是VSYNC狀態(tài)，下一個(gè)狀態(tài)也是Idle狀態(tài)，那么說(shuō)明信號(hào)已經(jīng)來(lái)了，下一次的客戶(hù)端請(qǐng)求還沒(méi)來(lái)，所以不要進(jìn)行VSYNC信號(hào)請(qǐng)求，則會(huì)進(jìn)行取消操作。

if (mState != nextState) {            if (mState == State::VSync) {                mVSyncSource->setVSyncEnabled(false);            } else if (nextState == State::VSync) {                //如果下一個(gè)狀態(tài)還是VSync，則繼續(xù)去請(qǐng)求VSYNC信號(hào)                mVSyncSource->setVSyncEnabled(true);            }            mState = nextState;        }

如何開(kāi)始和結(jié)束去進(jìn)行VSYNC信號(hào)獲取的獲取操作，我們第四章中講，這個(gè)主要就是消費(fèi)者邏輯了。

6.如果event為空，說(shuō)明mPendingEvents中已經(jīng)取光了，則進(jìn)入休眠操作。

反之event不為空，說(shuō)明mPendingEvents中也許還存在未消費(fèi)的VSYNC信號(hào)，則contine繼續(xù)消費(fèi)。

//如果處理了event，那么說(shuō)明此次已經(jīng)拿到了Vsync信號(hào)，說(shuō)明后面有可能還有，則繼續(xù)拿        if (event) {            continue;        }

7.進(jìn)入休眠或者超時(shí)之后主動(dòng)模擬信號(hào)加入到mPendingEvents中。

//說(shuō)明Vsync信號(hào)已經(jīng)消費(fèi)完了，則進(jìn)入休眠模式，等到APP側(cè)的下一次通知進(jìn)行喚醒        // Wait for event or client registration/request.        if (mState == State::Idle) {            mCondition.wait(lock);        } else {            // Generate a fake VSYNC after a long timeout in case the driver stalls. When the            // display is off, keep feeding clients at 60 Hz.            const std::chrono::nanoseconds timeout =                    mState == State::SyntheticVSync ? 16ms : 1000ms;            if (mCondition.wait_for(lock, timeout) == std::cv_status::timeout) {                if (mState == State::VSync) {                    ALOGW("Faking VSYNC due to driver stall for thread %s", mThreadName);                    std::string debugInfo = "VsyncSource debug info:\n";                    mVSyncSource->dump(debugInfo);                    // Log the debug info line-by-line to avoid logcat overflow                    auto pos = debugInfo.find("\n");                    while (pos != std::string::npos) {                        ALOGW("%s", debugInfo.substr(0, pos).c_str());                        debugInfo = debugInfo.substr(pos + 1);                        pos = debugInfo.find("\n");                    }                }                LOG_FATAL_IF(!mVSyncState);                const auto now = systemTime(SYSTEM_TIME_MONOTONIC);                const auto deadlineTimestamp = now + timeout.count();                const auto expectedVSyncTime = deadlineTimestamp + timeout.count();                mPendingEvents.push_back(makeVSync(mVSyncState->displayId, now,                                                   ++mVSyncState->count, expectedVSyncTime,                                                   deadlineTimestamp));            }        }

3.3  dispatchEvent方法把Vsync信號(hào)分發(fā)給消費(fèi)者

首先遍歷消費(fèi)者，調(diào)用postEvent進(jìn)行通知

void EventThread::dispatchEvent(const DisplayEventReceiver::Event& event,                                const DisplayEventConsumers& consumers) {     for (const auto& consumer : consumers) {            ...            switch (consumer->postEvent(copy)) {            }     }}

然后postEvent方法中，調(diào)用sendEvent進(jìn)行信號(hào)的發(fā)送

status_t EventThreadConnection::postEvent(const DisplayEventReceiver::Event& event) {   ...        auto size = DisplayEventReceiver::sendEvents(&mChannel, mPendingEvents.data(),                                                     mPendingEvents.size());    ...}

最終通過(guò)Socket的方法進(jìn)行信號(hào)的發(fā)送，接受者就是APP側(cè)了。

ssize_t DisplayEventReceiver::sendEvents(gui::BitTube* dataChannel,        Event const* events, size_t count){    return gui::BitTube::sendObjects(dataChannel, events, count);}

四.SurfaceFlinger端生產(chǎn)者

上面講到通過(guò)setVSyncEnabled方法去開(kāi)始或者結(jié)束獲取Vsync信號(hào)的操作。

4.1 獲取VSYNC信號(hào)

setVSyncEnabled方法如下：

void DispSyncSource::setVSyncEnabled(bool enable) {    std::lock_guard lock(mVsyncMutex);    if (enable) {        mCallbackRepeater->start(mWorkDuration, mReadyDuration);    } else {        mCallbackRepeater->stop();    }    mEnabled = enable;}

對(duì)應(yīng)的其實(shí)就是mCallbackRepeater的start和stop方法，其實(shí)現(xiàn)類(lèi)是DispSyncSource.cpp中的CallbackRepeater。

我們這里看到一個(gè)成員變量mWorkDuration，這個(gè)值其實(shí)就是控制Vscyn觸發(fā)時(shí)間的。這個(gè)我們后續(xù)小節(jié)再講，這里只是知道有這個(gè)值就好了。

4.2 把時(shí)間設(shè)置給Timer定時(shí)觸發(fā)

start方法中，記錄一下傳入的workDuration時(shí)間，然后傳遞給mRegistration處理。

void start(std::chrono::nanoseconds workDuration, std::chrono::nanoseconds readyDuration) {        std::lock_guard lock(mMutex);        mStarted = true;        mWorkDuration = workDuration;        mReadyDuration = readyDuration;        auto const scheduleResult =                mRegistration.schedule({.workDuration = mWorkDuration.count(),                                        .readyDuration = mReadyDuration.count(),                                        .earliestVsync = mLastCallTime.count()});           }

mRegistration的實(shí)現(xiàn)類(lèi)是VSyncCallbackRegistration，其中schedule方法也是交給VSyncDispatchTimerQueue來(lái)處理：

ScheduleResult VSyncCallbackRegistration::schedule(VSyncDispatch::ScheduleTiming scheduleTiming) {    if (!mValidToken) {        return std::nullopt;    }    return mDispatch.get().schedule(mToken, scheduleTiming);}

schedule方法中，進(jìn)行一系列的合法判斷，最終會(huì)交給 rearmTimerSkippingUpdateFor方法處理。

然后我們就可以看到rearmTimerSkippingUpdateFor中去調(diào)用setTimer方法去設(shè)置定時(shí)觸發(fā)。

rearmTimerSkippingUpdateFor方法略，

setTimer方法如下：

void VSyncDispatchTimerQueue::setTimer(nsecs_t targetTime, nsecs_t /*now*/) {    mIntendedWakeupTime = targetTime;    mTimeKeeper->alarmAt(std::bind(&VSyncDispatchTimerQueue::timerCallback, this),                         mIntendedWakeupTime);    mLastTimerSchedule = mTimeKeeper->now();}

則到了targetTime之后，就會(huì)執(zhí)行timerCallBack方法。

4.3 生成Vsync信號(hào)加入mPendingEvents

timerCallback方法如下：

void VSyncDispatchTimerQueue::timerCallback() {    struct Invocation {        std::shared_ptrcallback;        nsecs_t vsyncTimestamp;        nsecs_t wakeupTimestamp;        nsecs_t deadlineTimestamp;    };    std::vectorinvocations;    {        std::lock_guard lock(mMutex);        auto const now = mTimeKeeper->now();        mLastTimerCallback = now;        for (auto it = mCallbacks.begin(); it != mCallbacks.end(); it++) {            auto& callback = it->second;            auto const wakeupTime = callback->wakeupTime();            if (!wakeupTime) {                continue;            }            auto const readyTime = callback->readyTime();            auto const lagAllowance = std::max(now - mIntendedWakeupTime, static_cast(0));            if (*wakeupTime < mIntendedWakeupTime + mTimerSlack + lagAllowance) {                callback->executing();                invocations.emplace_back(Invocation{callback, *callback->lastExecutedVsyncTarget(),                                                    *wakeupTime, *readyTime});            }        }        mIntendedWakeupTime = kInvalidTime;        rearmTimer(mTimeKeeper->now());    }    for (auto const& invocation : invocations) {        invocation.callback->callback(invocation.vsyncTimestamp, invocation.wakeupTimestamp,                                      invocation.deadlineTimestamp);    }

這里的核心邏輯其實(shí)就是遍歷mCallbacks，然后分別回調(diào)。

那么mCallbacks是怎么添加的呢？ CallbackRepeater創(chuàng)建的時(shí)候，回去注冊(cè) mRegistration，同時(shí)會(huì)傳入CallbackRepeater::callback方法作為回調(diào)，所以mCallbacks其實(shí)就是CallbackRepeater::callback。

void callback(nsecs_t vsyncTime, nsecs_t wakeupTime, nsecs_t readyTime) {       ...        mCallback(vsyncTime, wakeupTime, readyTime);        ...    }

很明顯直接交給mCallback處理，所以我們又得看一下這個(gè)mCallback從何而來(lái)。

這個(gè)mCallback是CallbackRepeater創(chuàng)建時(shí)傳入的DispSyncSource::onVsyncCallback方法：

mCallbackRepeater =            std::make_unique(vSyncDispatch,                                               std::bind(&DispSyncSource::onVsyncCallback, this,                                                         std::placeholders::_1,                                                         std::placeholders::_2,                                                         std::placeholders::_3),                                               name, workDuration, readyDuration,                                               std::chrono::steady_clock::now().time_since_epoch());

所以，最終會(huì)調(diào)用到DispSyncSource::onVsyncCallback方法：

void DispSyncSource::onVsyncCallback(nsecs_t vsyncTime, nsecs_t targetWakeupTime,                                     nsecs_t readyTime) {    VSyncSource::Callback* callback;    {        std::lock_guard lock(mCallbackMutex);        callback = mCallback;    }    ...    if (callback != nullptr) {        callback->onVSyncEvent(targetWakeupTime, {vsyncTime, readyTime});    }}

又是回調(diào)，這里很繞。這里的callback其實(shí)就是EventThread，仍然是在創(chuàng)建EventThread的時(shí)候設(shè)置的：

EventThread::EventThread(std::unique_ptrvsyncSource,                         android::frametimeline::TokenManager* tokenManager,                         InterceptVSyncsCallback interceptVSyncsCallback,                         ThrottleVsyncCallback throttleVsyncCallback,                         GetVsyncPeriodFunction getVsyncPeriodFunction)      : mVSyncSource(std::move(vsyncSource)),        mTokenManager(tokenManager),        mInterceptVSyncsCallback(std::move(interceptVSyncsCallback)),        mThrottleVsyncCallback(std::move(throttleVsyncCallback)),        mGetVsyncPeriodFunction(std::move(getVsyncPeriodFunction)),        mThreadName(mVSyncSource->getName()) {    LOG_ALWAYS_FATAL_IF(getVsyncPeriodFunction == nullptr,            "getVsyncPeriodFunction must not be null");    mVSyncSource->setCallback(this);    ...}

所以，終于可以看到盡頭了。最終其實(shí)就是調(diào)用到EventThread的onVSyncEvent方法：

void EventThread::onVSyncEvent(nsecs_t timestamp, VSyncSource::VSyncData vsyncData) {    std::lock_guardlock(mMutex);    LOG_FATAL_IF(!mVSyncState);    mPendingEvents.push_back(makeVSync(mVSyncState->displayId, timestamp, ++mVSyncState->count,                                       vsyncData.expectedPresentationTime,                                       vsyncData.deadlineTimestamp));    mCondition.notify_all();}

這里我們看到，會(huì)生成一個(gè)VSync信號(hào)，加入到mPendingEvents集合中，并且發(fā)出通知，讓threadMain去獲取，從而完成了VSync信號(hào)的生產(chǎn)者流程。

畫(huà)了如下的surfaceFlinger結(jié)構(gòu)圖，方便理解（非完整版）：

五.APP層收到信號(hào)進(jìn)行刷新

本章講的主要流程如下圖紅圈所示：

5.1 APP端接受流程

3.3小節(jié)中講到，SurfaceFlinger會(huì)通過(guò)BitTube的方式傳遞給APP側(cè)Vsync信號(hào)。發(fā)送vscyn信號(hào)的方法在DisplayEventReceiver.cpp中，而接收方法也在這個(gè)類(lèi)當(dāng)中。而具體調(diào)用方則是DisplayEventDispatcher.cpp中的dispatchVsync方法。流程如下圖所示：

5.2 dispathVsync分發(fā)流程

上面在handleEvent中，processPendingEvents獲取到了Vsync信號(hào)VsyncEventData后，交給dispatchVsync方法負(fù)責(zé)處理。

dispatchVsync(vsyncTimestamp, vsyncDisplayId, vsyncCount, vsyncEventData);

dispatchVsync方法的實(shí)現(xiàn)者是android_view_DisplayEventReceiver.cpp，如下：

void NativeDisplayEventReceiver::dispatchVsync(nsecs_t timestamp, PhysicalDisplayId displayId,                                               uint32_t count, VsyncEventData vsyncEventData) {    JNIEnv* env = AndroidRuntime::getJNIEnv();    ...    jobject javaVsyncEventData = createJavaVsyncEventData(env, vsyncEventData);    env->CallVoidMethod(receiverObj.get(), gDisplayEventReceiverClassInfo.dispatchVsync,                            timestamp, displayId.value, count, javaVsyncEventData);    ...}

我們可以看到，先是把VsyncEventData轉(zhuǎn)換為java可以接受的jobject對(duì)象，然后通過(guò)CallVoidMethod方法通知到j(luò)ava層中DisplayEventReceiver.java中的dispatchVsync方法。

5.3 java中流程流轉(zhuǎn)

首先DisplayEventReceiver中dispatchVsync方法被調(diào)用：

// Called from native code.    @SuppressWarnings("unused")    private void dispatchVsync(long timestampNanos, long physicalDisplayId, int frame,            VsyncEventData vsyncEventData) {        onVsync(timestampNanos, physicalDisplayId, frame, vsyncEventData);    }

該方法中直接調(diào)用onVsync方法，調(diào)用到Choreographer.java中FrameDisplayEventReceiver下的onVsync方法：

@Override        public void onVsync(long timestampNanos, long physicalDisplayId, int frame,                VsyncEventData vsyncEventData) {            try {                ...                if (timestampNanos > now) {                    timestampNanos = now;                }                if (mHavePendingVsync) {                } else {                    mHavePendingVsync = true;                }                mTimestampNanos = timestampNanos;                mFrame = frame;                mLastVsyncEventData = vsyncEventData;                Message msg = Message.obtain(mHandler, this);                msg.setAsynchronous(true);                mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);            } finally {                Trace.traceEnd(Trace.TRACE_TAG_VIEW);            }        }

onVsync方法中，主要判斷時(shí)間。如果timestampNanos>now，則是用當(dāng)前時(shí)間。所以還是以方法的調(diào)用時(shí)間為準(zhǔn)。然后通過(guò)handle轉(zhuǎn)發(fā)到主線(xiàn)程中執(zhí)行。

Message.obj=this，本身FrameDisplayEventReceiver又實(shí)現(xiàn)了Runnable接口，所以自然會(huì)執(zhí)行FrameDisplayEventReceiver下的run方法：

@Override        public void run() {            mHavePendingVsync = false;            doFrame(mTimestampNanos, mFrame, mLastVsyncEventData);        }

這時(shí)候我們就看到，執(zhí)行到了doFrame方法，而這個(gè)方法也是就是渲染流程的執(zhí)行者。

5.4 如何觸發(fā)handleEvent流程？

講到這里，你或許有個(gè)疑問(wèn)，上面流程中，如何執(zhí)行到5.1中的handleEvent方法的呢？

主要是下圖所示的流程：

如果你斷點(diǎn)調(diào)試的時(shí)候，會(huì)發(fā)現(xiàn)下面所示的這個(gè)方法，竟然是主線(xiàn)程調(diào)用的：

DisplayEventReceiver.java // Called from native code.    @SuppressWarnings("unused")    private void dispatchVsync(long timestampNanos, long physicalDisplayId, int frame,            long frameTimelineVsyncId, long frameDeadline, long frameInterval) {        onVsync(timestampNanos, physicalDisplayId, frame,                new VsyncEventData(frameTimelineVsyncId, frameDeadline, frameInterval));    }

為什么用竟然呢？因?yàn)橐话銇?lái)看，應(yīng)該是子線(xiàn)程等待接受SurfaceFlinger的信號(hào)，收到了信號(hào)后交給主線(xiàn)程處理，如果是主線(xiàn)程去等待，豈不是主線(xiàn)程阻塞了？

這里使用looper.addFd()方法，在該方法中，用到了一個(gè)epoll_ctl的機(jī)制，即對(duì)FD文件進(jìn)行監(jiān)聽(tīng)，當(dāng)FD改變時(shí)觸發(fā)主線(xiàn)程的回調(diào)。如果處理完回調(diào)任務(wù)，則會(huì)進(jìn)入epoll_wait的阻塞，繼續(xù)監(jiān)聽(tīng)。

六.擴(kuò)展問(wèn)題

問(wèn)：高頻次請(qǐng)求vsync信號(hào)，會(huì)突破60FPS的限制嗎？

答：不會(huì)。

首先ViewRootImpl中做了一層處理，哪怕16ms改變了很多View的布局，最終執(zhí)行到了scheduleTraversals方法時(shí)，因?yàn)橛腥缦碌呐袛啵远贾粫?huì)執(zhí)行一次vsync信號(hào)的請(qǐng)求和注冊(cè)一次回調(diào)，直至收到VSYNC信號(hào)。

void scheduleTraversals() {        if (!mTraversalScheduled) {            mTraversalScheduled = true;            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();            mChoreographer.postCallback(                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);        }    }

取消限制：

void doTraversal() {        if (mTraversalScheduled) {            mTraversalScheduled = false;}

其次，2.2小節(jié)中講到，native請(qǐng)求VSYNC信號(hào)時(shí)也有一次限制，等到VSYNC信號(hào)時(shí)是不會(huì)再次發(fā)送請(qǐng)求的。

status_t DisplayEventDispatcher::scheduleVsync() {    if (!mWaitingForVsync) {        ...        status_t status = mReceiver.requestNextVsync();        ...        mWaitingForVsync = true;        ...    }    return OK;}

七.參考資料

https://www.jianshu.com/p/6083c590521b

https://www.jianshu.com/p/386bbb5fa29a //努比亞技術(shù)團(tuán)隊(duì)文章

八.聲明

1.本文是原創(chuàng)，根據(jù)網(wǎng)上資料和閱讀ASOP的源碼之后得出的結(jié)論，如有問(wèn)題，歡迎指出。

2.圖中涉及到的流程圖如果想要高清大圖或者pos格式的原圖，可以私信我。