Android SurfaceFlinger SW Vsync模型

Android SurfaceFlinger Vsync这块比较复杂,最初在看这块的时候,迟迟不知道从何入手,网上看了各种SurfaceFlinger Vsync相关的博客,个人感觉紧紧是把代码流程给讲了一遍,当涉及到更具体一些知识,比如updateModelLocked里的时间计算时都没有一篇文章涉及到。

自己硬着头皮看了好几星期,稍微有些心得。所以在这里写下博客将我所理解的SurfaceFlinger记录下来

  • 一来是方便以后再回过头来看时,
  • 一来也给其它读者提供一个参考,利己利人。

本文代码是基于 Android 7.0

转载请标明来处: http://www.jianshu.com/p/d3e4b1805c92

本文也是在参考了网上大牛的文章,自己加log debug后加上自己的理解写的。下面推荐几篇比较不错的文章。

  • Android - SurfaceFlinger 之 VSync 概括
    这篇文章对 vsync 科普得还行, 没有涉及到一行代码。
  • Android 5.1 SurfaceFlinger VSYNC详解
    这篇文章对 vsync 的传递流程讲得还是挺不错了,对于理解Surface Vsync流程还是不错的。但是感觉仅仅是在分析代码调用流程而已。
  • Android中的GraphicBuffer同步机制-Fence
    话说第一次见到Fence,也没有仔细阅读
  • DispSync
    这篇文章真的是五星推荐,它将SurfaceFlinger的Vsync机制最重要的DispSync部分拿出来讲, 而且讲得非常好。BTW, 这篇文章是我在网上搜到,觉得好像是我们现公司一个大牛写的,于是跟他确认,结果真是他写的。真是大牛。

一、SurfaceFlinger Vsync的线程图

图1 vsync信号产生

由图1可以看出与vsync相关的SurfaceFlinger线程主要有以下几个:

  1. EventControlThread: 控制硬件vsync的开关
  2. DispSyncThread: 软件产生vsync的线程
  3. SF EventThread: 该线程用于SurfaceFlinger接收vsync信号用于渲染
  4. App EventThread: 该线程用于接收vsync信号并且上报给App进程,App开始画图

从这4个线程,其实我们可以将vsync分为4种不同的类型

  • HW vsync, 真实由硬件产生的vsync信号
  • SW vsync, 由DispSync产生的vsync信号
  • SF vsync, SF接收到的vsync信号
  • App vsync, App接收到的vsync信号

DispSync这篇文章里用了一个非常非常准确的 PLL 图来表示上面4个vsync信号之间的关系。

图2 DispSync的PLL模型

因此可以看出 SW vsync/App vsync 并不是直接由HW vsync产生的,而是由SW vsync产生的,HW vsync作为SW vsync的参考,动态的更新SW vsync里的模型参数,这样让SW vsync能与HW vsync更加的精确吧。

那么为什么SurfaceFlinger要用SW vsync而不是直接用HW vsync呢?
猜想可能是因为HW vsync每隔固定时间由显示屏产生中断,然后传给driver, driver再回调给SurfaceFlinger, 这样经过层层回调,会对performance有影响吧。而SW vsync直接由SurfaceFlinger产生,省略了很多步骤。

所以我个人觉得SurfaceFlinger最重要的是要搞明白 SW vsync是怎么运作的。

二、EventThread

为什么要先说EventThread? 很奇怪是吧,图2 PLL图 明明是SW vsync将vsync信号传给 VSYNC-sf/VSYNC-app的,怎么还先讲结果了呢?而不先讲DispThread呢?

因为前面所说的4个线程互相影响,且是并行进行的,所以要想用一篇文章(单线程)来很顺利的写清楚(多线程的过程),而还要交待清楚前因后果,非常考验这个作者的水平。所以第二节先说 EventThread 是为了写好 DispSync 作铺垫的。

由于SF EventThread和APP EventThread是同一套代码, 而SF EventThread先运作起来,所以下面以SF EventThread为例作介绍.

2.1 EventThread的初始化

sp vsyncSrc = new DispSyncSource(&mPrimaryDispSync,vsyncPhaseOffsetNs, true, "app");
mEventThread = new EventThread(vsyncSrc,*this); 
sp sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync, sfVsyncPhaseOffsetNs, true, "sf");
mSFEventThread = new EventThread(sfVsyncSrc, *this);
mEventQueue.setEventThread(mSFEventThread);

如上面所示,生成两个EventThread,一个是APP EventThread, 一个是SF EventThread.
它们的区别在于相移phase offset不同,

EventThread 相移
App VSYNC_EVENT_PHASE_OFFSET_NS
SF SF_VSYNC_EVENT_PHASE_OFFSET_NS

这两个值都可配,这两个一般用来调节performance. 具体可在 BoardConfig.mk里配置

2.2 EventThread运行

void EventThread::onFirstRef() {
    run("EventThread", PRIORITY_URGENT_DISPLAY + PRIORITY_MORE_FAVORABLE);
}

bool EventThread::threadLoop() {
    signalConnections = waitForEvent(&event);  //阻塞式的等待事件发生
    const size_t count = signalConnections.size();
    for (size_t i=0 ; i& conn(signalConnections[i]);
        status_t err = conn->postEvent(event);
    }
}

sp指针是生成对象结束后会调用onFirstRef.
接着又调用Thread的run函数,线程就一直开始反复调用threadLoop.
从threadLoop大致可以猜测出来,先等着事件发生(这里也就是vsync事件),然后将vsync事件分发出去,不同的EventThread(SF/APP EventThread)作的事情就开始不同了。

2.2.1接着看 waitForEvent()

Vector< sp > EventThread::waitForEvent(
        DisplayEventReceiver::Event* event)
{
    Mutex::Autolock _l(mLock);
    Vector< sp > signalConnections;

    do {
        bool eventPending = false;
        bool waitForVSync = false;

        size_t vsyncCount = 0;
        nsecs_t timestamp = 0;

        for (int32_t i=0 ; i connection(mDisplayEventConnections[i].promote());
            if (connection != NULL) {
                bool added = false;
              //这里的connection->count的值的大小有如下含义
             // count >= 1 : continuous event. count is the vsync rate  如果在大于等于1,表示会持续接收vsync event
            // count == 0 : one-shot event that has not fired    表示只接收一次
            // count ==-1 : one-shot event that fired this round / disabled   等于-1,表示不能再接收vsync事件了

                if (connection->count >= 0) {  //只能对还能接收的connection进行处理
                    // we need vsync events because at least
                    // one connection is waiting for it
                    waitForVSync = true;  //这个变量后面会用到
                    if (timestamp) {
                        // we consume the event only if it's time
                        // (ie: we received a vsync event)
                        if (connection->count == 0) {  //如定义一样,如果是一次性的,那么在获得本次vsync后,将它的count置为-1了, 下次只能通过 requestNextVsync 来重置为0
                            // fired this time around
                            connection->count = -1;
                            signalConnections.add(connection);  //最外层的while判断条件会用到
                            added = true;
                        } else if (connection->count == 1 ||
                                (vsyncCount % connection->count) == 0) {
                            // continuous event, and time to report it
                            signalConnections.add(connection);
                            added = true;
                        }
                    }
                }
                
                if (eventPending && !timestamp && !added) {
                    // we don't have a vsync event to process
                  // 英文注释已经写的很明白了,如果此时没有vsync事件,但是有pending的事件,那不管connection是否能接收了
                    // (timestamp==0), but we have some pending
                    // messages.
                    signalConnections.add(connection);
                }
            } else {
                // we couldn't promote this reference, the connection has
                // died, so clean-up!
                mDisplayEventConnections.removeAt(i);
                --i; --count;
            }
        }

        // Here we figure out if we need to enable or disable vsyncs
        if (timestamp && !waitForVSync) {
            // we received a VSYNC but we have no clients
            // don't report it, and disable VSYNC events
          // 英文注释已经写的很明白了,vsync事件已经发生了,但是我都还没有client去监听,那么这时你再继续发vsync根本就是多余的
         // 所以直接disable Vsync, 注意这里并不是真正的disable硬件的VSYNC信号,见下面的分析
            disableVSyncLocked();
        } else if (!timestamp && waitForVSync) {
            // we have at least one client, so we want vsync enabled
            // (TODO: this function is called right after we finish
            // notifying clients of a vsync, so this call will be made
            // at the vsync rate, e.g. 60fps.  If we can accurately
            // track the current state we could avoid making this call
            // so often.)
        // 如果有client在监听了,但是还没有vsync事件,那么是否是之前vsync被disable了呢?
       //如果是的就要打开vsync监听,
            enableVSyncLocked();
        }

        // note: !timestamp implies signalConnections.isEmpty(), because we
        // don't populate signalConnections if there's no vsync pending
        if (!timestamp && !eventPending) {//既没有vsync事件,也没有其它pending的事件(hotplug事件)
            // wait for something to happen
            if (waitForVSync) {  //但是有client在监听了,这时就等着上报vsync事件即可
                // This is where we spend most of our time, waiting
                // for vsync events and new client registrations.
                //
                // If the screen is off, we can't use h/w vsync, so we
                // use a 16ms timeout instead.  It doesn't need to be
                // precise, we just need to keep feeding our clients.
                //
                // We don't want to stall if there's a driver bug, so we
                // use a (long) timeout when waiting for h/w vsync, and
                // generate fake events when necessary.
                bool softwareSync = mUseSoftwareVSync; //这里只考虑硬件vsync的情况,软件模拟的暂时不考虑
                nsecs_t timeout = softwareSync ? ms2ns(16) : ms2ns(1000);
              //如注释所说的,如果是driver的bug,如果硬件一直不上报vsync事件怎么办??难道就一直等下去??那client不就饿死了么?
             //所以这里如果driver不报vsync,那么就软件模拟一个vsync事件,这里的timeout是1000ms,发一个
   
                if (mCondition.waitRelative(mLock, timeout) == TIMED_OUT) {
                    if (!softwareSync) {
                        ALOGW("Timed out waiting for hw vsync; faking it");
                    }
                    // FIXME: how do we decide which display id the fake
                    // vsync came from ?
                    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++;
                }
            } else {
                // Nobody is interested in vsync, so we just want to sleep.
                // h/w vsync should be disabled, so this will wait until we
                // get a new connection, or an existing connection becomes
                // interested in receiving vsync again.
              //既没有client, 又没有硬件vsync事件,那么就死等下去了。
                mCondition.wait(mLock);
            }          
            
        }
    } while (signalConnections.isEmpty());

    // here we're guaranteed to have a timestamp and some connections to signal
    // (The connections might have dropped out of mDisplayEventConnections
    // while we were asleep, but we'll still have strong references to them.)
    return signalConnections;
}

对于这个函数的解释已经基本上在注释里已经写得比较清楚了,下面来考虑最初的代码运作过程,

  1. 函数第一次进入
    timestamp为0,即没有vsync事件, 也没有pending事件, 而且重要的是也没有client,那么就直接进入 mCondition.wait(mLock) 死等

  2. 创建Connection
    当初始化完SF EventThread后,就开始创建SF Connection了。
    入口

mEventQueue.setEventThread(mSFEventThread);

创建Connection,加入回调函数

void MessageQueue::setEventThread(const sp& eventThread)
{
    mEventThread = eventThread;
    mEvents = eventThread->createEventConnection();                                                                                                                   
    mEventTube = mEvents->getDataChannel();
    mLooper->addFd(mEventTube->getFd(), 0, Looper::EVENT_INPUT,
            MessageQueue::cb_eventReceiver, this);
} 
sp EventThread::createEventConnection() const {
    return new Connection(const_cast(this)); 
//这里注意了,初始化的Connection的count都为-1,即刚开始的时候,connection都不会接收vsync事件
}  

注册Connection

void EventThread::Connection::onFirstRef() {
    // NOTE: mEventThread doesn't hold a strong reference on us
    mEventThread->registerDisplayEventConnection(this);
}
status_t EventThread::registerDisplayEventConnection(                                                                                                                 
        const sp& connection) {
    Mutex::Autolock _l(mLock);
    mDisplayEventConnections.add(connection);  
        //加入要SF EventThread里的mDisplayEventConnections里
    mCondition.broadcast();  //并释放mCondition
    return NO_ERROR;
}
  1. 第2步中mCondition.broadcast()会唤醒第一步中的mCondition.wait(),但是在waitForEvent的while循环为false,再做while一次循环
  2. 这时候 timestamp还是为0,还是没有pending的event, 但是这时有SF的connection了,只不过此时connection的count仍然为默认的-1,
  3. 最后还是进入 mCondition.wait死等.

注意: 实际在调试的时候 registerDisplayEventConnection会比SF EventThread的threadLoop先运行起来,不过最后的结果是一样的。

由第4步可知Connection的初始化count为-1,即表示该Connection不会接收vsync事件,那么这个值是在什么地方被修改的呢?

答案是在SurfaceFlinger初始化的最后initializeDisplays里

2.2.2 requestNextVsync

initializeDisplays();
    flinger->onInitializeDisplays();
        setTransactionState(state, displays, 0);
            setTransactionFlags(transactionFlags);
                signalTransaction();
                    EventQueue.invalidate();
                        mEvents->requestNextVsync()  //mEvents是Connection实例
                            EventThread->requestNextVsync(this);

requestNextVsync表示主动去请求获得vsync事件, 上面的意思是将Display初始化后,即显示屏可以工作后,那么SF EventThread就开始要监听vsync事件了。

void EventThread::requestNextVsync(
        const sp& connection) {
    Mutex::Autolock _l(mLock);

    mFlinger.resyncWithRateLimit();

    if (connection->count < 0) {
        connection->count = 0;  //这里将SurfaceFlinger的Count改为0,变成一次性接收的了
        mCondition.broadcast();  //释放EventThread里的mCondition
    }
}                       
  • a) requestNextVsync释放EventThread里的mCondition后,接着会唤醒 EventThread里的上面第5步的mCondition.wait, 这时会再走一遍while循环
  • b). 这时候timestamp还是为0,还是没有pending的event, 但是这时有SF的connection了, 且此时的connection的count已经被置为了0,表明此时有connection在监听了,即waitForVSync为true
  • c) 接下来 enableVSyncLocked
  • d) 进入mCondition.waitRelative(), 其中超时时间为1000ms

那么 enableVSyncLocked 这个函数又是干什么的呢?

2.2.3 enableVSyncLocked

void EventThread::enableVSyncLocked() {
    if (!mUseSoftwareVSync) {
        // never enable h/w VSYNC when screen is off
        if (!mVsyncEnabled) { //这里只考虑硬件vsync的情况,而不考虑软件模拟的情况
            mVsyncEnabled = true; 
            mVSyncSource->setCallback(static_cast(this));
            mVSyncSource->setVSyncEnabled(true);
        }
    }
    mDebugVsyncEnabled = true;
    sendVsyncHintOnLocked();
}

这里只考虑硬件vsync的情况,即mUseSoftwareVSync为false的情况,最后调用到 setVsyncEnabled, 且其值为true

virtual void setVSyncEnabled(bool enable) {
    Mutex::Autolock lock(mVsyncMutex);
    if (enable) {
      // 将EventListener最终加入到DispSyncThread的mEventListeners里
        status_t err = mDispSync->addEventListener(mName, mPhaseOffset,
                static_cast(this));
        if (err != NO_ERROR) {
            ALOGE("error registering vsync callback: %s (%d)", strerror(-err), err);
        }    
        //ATRACE_INT(mVsyncOnLabel.string(), 1);
    } else {
      //相反如果 enable 为false时,那么就从EventListeners里删除掉
        status_t err = mDispSync->removeEventListener(static_cast(this));
        if (err != NO_ERROR) {
            ALOGE("error unregistering vsync callback: %s (%d)",strerror(-err), err);
        }    
        //ATRACE_INT(mVsyncOnLabel.string(), 0);
    }    
    mEnabled = enable;
} 
status_t addEventListener(const char* name, nsecs_t phase,
        const sp& callback) {
    if (kTraceDetailedInfo) ATRACE_CALL();
    Mutex::Autolock lock(mMutex);

    for (size_t i = 0; i < mEventListeners.size(); i++) {
        if (mEventListeners[i].mCallback == callback) {
            return BAD_VALUE;
        }
    }

    EventListener listener;
    listener.mName = name;
    listener.mPhase = phase;
    listener.mCallback = callback;

    // listener里的mLastEventTime这个在这里初始化的意义是防止之前的VSYNC事件被发送出去了
    // We want to allow the firstmost future event to fire without
    // allowing any past events to fire
    listener.mLastEventTime = systemTime() - mPeriod / 2 + mPhase - mWakeupLatency;

    mEventListeners.push(listener);
   //DispSyncThread的 mCond释放
    mCond.signal();

    return NO_ERROR;
}

第二节主要是为DispSyncThread添加EventListener, 那下面这节就是为DispSyncThread设置Peroid. 这样DispSync模型就可以动作起来了。

三、开关硬件HWC

在SurfaceFlinger初始化Display后,会调用resyncToHardwareVsync跟硬件vsync进行同步

initializeDisplays();
    flinger->onInitializeDisplays();
        setPowerModeInternal()
            resyncToHardwareVsync(true);
                repaintEverything();

3.1 resyncToHardwareVsync函数

void SurfaceFlinger::resyncToHardwareVsync(bool makeAvailable) {
    Mutex::Autolock _l(mHWVsyncLock);

    if (makeAvailable) {
        // mHWVsyncAvailable表示HW vsync被enable了
        mHWVsyncAvailable = true;
    } else if (!mHWVsyncAvailable) {
        // Hardware vsync is not currently available, so abort the resync
        // attempt for now
        return;
    }

   //获得显示设备的刷新率,比如60HZ, 那么period就是16.6667ms,即每隔16.6667就会产生一个硬件vsync信号
    const nsecs_t period =
            getHwComposer().getRefreshPeriod(HWC_DISPLAY_PRIMARY);
    //当前这个值跟具体的显示设备有关,并不一定是60HZ
    mPrimaryDispSync.reset();
    //设置DispSync模型里period为显示设备的频率
    mPrimaryDispSync.setPeriod(period);

   //mPrimaryHWVsyncEnabled表示当前的硬件vsync是否enable,
    if (!mPrimaryHWVsyncEnabled) {
        mPrimaryDispSync.beginResync();
        //如果硬件vsync没有enable,那么就通知EventControlThread去通知硬件enable VSYNC,这个和DispSync的setVsyncEnabled是不一样的
        mEventControlThread->setVsyncEnabled(true);
        mPrimaryHWVsyncEnabled = true;
    }
}

3.2 setPeriod 更新mPeriod

mPrimaryDispSync.setPeriod(period);
void DispSync::setPeriod(nsecs_t period) {
    Mutex::Autolock lock(mMutex);
    mPeriod = period;
    mPhase = 0;
    mReferenceTime = 0;
    mThread->updateModel(mPeriod,mPhase,mReferenceTime);                                                                                                        
}

mPeriod表示具体的硬件产生vsync的时间间隔
mThread是DispSyncThread, DispSync在初始化的时候直接生成一个线程DispSyncThread并运行起来

void updateModel(nsecs_t period, nsecs_t phase, nsecs_t referenceTime) {                                                                                          
    if (kTraceDetailedInfo) ATRACE_CALL();
    Mutex::Autolock lock(mMutex);
    mPeriod = period;
    mPhase = phase;
    mReferenceTime = referenceTime;
    mCond.signal(); 
}

updateModel里会再次唤醒 DispSyncThread的里的 mCond, 注意此时 mPeroid已经不为0了。

四、硬件Vsync的控制

4.1 默认开闭硬件vsync

SurfaceFlinger在初始化HWComposer时会默认关闭硬件Vsync信号,这里直接调用eventControl.
具体代码如下

HWComposer::HWComposer() {
    eventControl(HWC_DISPLAY_PRIMARY, HWC_EVENT_VSYNC, 0);
}

void HWComposer::eventControl(int disp, int event, int enabled) {
    err = mHwc->eventControl(mHwc, disp, event, enabled);
}

mHwc是hwc_composer_device_1类型,它表示是对一个硬件设备的抽象吧,通过它就可以控制和使用硬件相关功能吧。

那么硬件的Vsync是在什么时候被打开的呢?

4.2 打开硬件vsync

具体是在3.1 resyncToHardwareVsync 函数最后的代码打开的。
resyncToHardwareVsync函数从字面上看来就是和硬件的Vsync进行同步的意思。

    if (!mPrimaryHWVsyncEnabled) {
        mPrimaryDispSync.beginResync();
        //如果硬件vsync没有enable,那么就通知EventControlThread去通知硬件enable VSYNC,
        //这个和DispSync的setVsyncEnabled是不一样的
        mEventControlThread->setVsyncEnabled(true);
        mPrimaryHWVsyncEnabled = true;
    }

resyncToHardwareVsync函数通过EventControlThread去控制硬件Vsync信号的开关

void EventControlThread::setVsyncEnabled(bool enabled) {                                                                                                              
    Mutex::Autolock lock(mMutex);
    mVsyncEnabled = enabled; // mVsyncEnabled一个控制开关
    mCond.signal();  //释放EventControlThread里的mCond信号
}

setVsyncEnabled会释放mCond信号,这样在EventControlThread的threadLoop里的mCond会被唤醒去操作硬件Vsync开关了

好了,经过三节的铺垫终于可以说下DispSync.

五、DispSync模型

DispSync 是定义在SurfaceFlinger类里的成员变量,因此在初始化 SurfaceFlinger时,就会初始化DispSync, 它在SurfaceFlinger里的具体定义是

DispSync mPrimaryDispSync

而DispSync在初始化的时候会生成 DispSyncThread 线程,紧接着将 DispSyncThread run起来,根据C++ Thread模型, DispSyncThread 会循环调用threadLoop() 函数。

下面来看下 DispSyncThread 里的 threadLoop()函数, 之所以把它的所有代码粘贴上来,是方便以后回顾之用。

5.1 DispSync模型运作

5.1.1 等待可用的EventListener

virtual bool threadLoop() {
    status_t err;
    nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC); 
    //获得当前的系统时间,这个是比较老的时间了

    while (true) {
        Vector callbackInvocations;

        nsecs_t targetTime = 0;

        { // Scope for lock
            Mutex::Autolock lock(mMutex);

            if (kTraceDetailedInfo) {
                ATRACE_INT64("DispSync:Frame", mFrameNumber);
            }
            ALOGV("[%s] Frame %" PRId64, mName, mFrameNumber);
            ++mFrameNumber; 
           //mFrameNumber仅仅是一个计数而已,没有实际用处,它和vsync个数是不等同的

            if (mStop) {
                return false;
            }
           
            //当threadLoop第一次进来后,由于mPeriod初始化为0,所以一直死等在这里
            if (mPeriod == 0) {
                err = mCond.wait(mMutex);  // **blockingA**
                if (err != NO_ERROR) {
                    ALOGE("error waiting for new events: %s (%d)",  strerror(-err), err);
                    return false;
                }
                continue;
            }
          ...
    }
}

当threadLoop第一次运行,mPeriod初始化为0,所以一直死等在"blockingA"处。

5.1.2 往DispSyncThread里加入EventListener

具体是在 setVSyncEnabled里,参考 2.2.3 enableVSyncLocked
setVSyncEnabled 将 EventListener添加到 DispSync 里的mEventListeners里,然后释放mCond.signal(), 继而mCond会唤醒 5.1.1 中的 blockingA.

注意此时 mPeriod 依然为0,所以线程也一直死等在"blockingA" 处, 但是DispSyncThread的 mEventListeners 已经加入了listener了。

5.1.3 DispSyncThread收到mPeriod更新

由5.1.2可知,由于mPeriod为0,所以线程一直死等在blockingA处,
而由3.2 setPeriod可知,此时mPeriod已经被更新成显示设备的刷新率了,且 mCond已经被释放了,因此 blockingA mCond.wait()被唤醒了。

这时进入threadLoop的第二阶段,计算下一个Vsync信号的时间戳,并且上报给EventListener. 就这样,DispSyncThread模型就运作起来了。

5.2 更新DispSync模型

由 4.2 小节可知,硬件Vsync已经在resyncToHardwareVsync被打开了,既然打开了,那么只要有硬件Vsync信号产生,就可回调 hook_vsync函数(hook_vsync函数在HWComposer的初始化的时候被注册的)

5.2.1 hook_vsync的回调函数

void HWComposer::hook_vsync(const struct hwc_procs* procs, int disp,
        int64_t timestamp) {
    cb_context* ctx = reinterpret_cast(
            const_cast(procs));
    ctx->hwc->vsync(disp, timestamp);
}

具体调用到HWComposer的vsync

void HWComposer::vsync(int disp, int64_t timestamp) {
    if (uint32_t(disp) < HWC_NUM_PHYSICAL_DISPLAY_TYPES) {
        {
            Mutex::Autolock _l(mLock);

            // 防止重复上报相同的vsync
            // There have been reports of HWCs that signal several vsync events
            // with the same timestamp when turning the display off and on. This
            // is a bug in the HWC implementation, but filter the extra events
            // out here so they don't cause havoc downstream.
            if (timestamp == mLastHwVSync[disp]) {
                ALOGW("Ignoring duplicate VSYNC event from HWC (t=%" PRId64 ")", timestamp);
                return;
            }

            mLastHwVSync[disp] = timestamp;
        }

        char tag[16];
        snprintf(tag, sizeof(tag), "HW_VSYNC_%1u", disp);
        ATRACE_INT(tag, ++mVSyncCounts[disp] & 1);
        //回调 onVsyncReceived函数
        mEventHandler.onVSyncReceived(disp, timestamp);
    }
}

5.2.2 onVsyncReceived

void SurfaceFlinger::onVSyncReceived(int type, nsecs_t timestamp) {
    bool needsHwVsync = false;

    { // Scope for the lock
        Mutex::Autolock _l(mHWVsyncLock);
        // 这里的type为0,表示的是primary display, 
        // 而 mPrimaryHWVsyncEnabled 在最初的resyncToHardwareVsync里已经被设置为true了,
        // 所以这里会进入addResyncSample
        if (type == 0 && mPrimaryHWVsyncEnabled) {
            needsHwVsync = mPrimaryDispSync.addResyncSample(timestamp);
        }    
    }    
    //addResyncSample会根据现有的硬件Vsync样本计算SW Vsync模型,如果误差已经在可接受范围内
   // 即认为不再需要硬件Vsync样本了,就得关闭硬件Vsync
   // 反之,如果误差还比较大,这里还需要继续加入硬件Vsync样本继续计算SW Vsync模型 
   // enableHardwareVsync/disableHardwareVsync都是通过EventControlThread去控制硬件Vsync开关
    if (needsHwVsync) {
        enableHardwareVsync();               
    } else {
        disableHardwareVsync(false);
    }    
}

5.2.3 addResyncSample

addResyncSample函数从字面上来讲就是加入硬件vsync的样本,目的是为了计算更新SW Vsync里面的参数。 具体的解释全部以注释的方式写在代码里了。

bool DispSync::addResyncSample(nsecs_t timestamp) {                                                                                                                   
    Mutex::Autolock lock(mMutex);

     //这里MAX_RESYNC_SAMPLES为32,即最大只保存32次硬件vsync时间戳,用来计算SW vsync模型.
      // mNumResyncSamples 表示已经有多少个硬件vsync 样本了 
     // 如果 mNumResyncSamples 等于32个了,那么下一次vsync来了,就用 mFirstResyncSample来记录是第几个
    // 如果保存的vsync个数达到最大32个的时候, 这样 mNumResyncSamples 和
    // mFirstResyncSample 两个变量就组成一个窗口(长度为32)向前滑动, 
    // 在滑动过程中丢掉最老的硬件vsync样本
    size_t idx = (mFirstResyncSample + mNumResyncSamples) % MAX_RESYNC_SAMPLES;
    // mResyncSamples 记录每个硬件vsync样本的时间戳,在计算sw vsync的模型时有用
    mResyncSamples[idx] = timestamp;
    
    //如果是第一个硬件vsync样本,就直接更新模型 (注意,这里的第一个硬件vsync并不是指开机后的第一个vsync, 
    //而是指 mNumResyncSamples被清0后的第一个vsync信号),具体在是beginResync里清0的
    //这里提前说一下,当SW Vsync与硬件Vsync误差比较大后,要重新校准,这里就要 beginResync,
    //它主要是重置一些值 ,比如 mNumResyncSamples, 既然有误差了,那么之前保存的硬件vsync样本就不能用了,就重新保存新的硬件vsync样本来调节精度了
    //所这里也很好理解,首先让SW Vsync模型以第一个硬件vsync为基准(注意第一个硬件vsync的含义),然后再慢慢调节它的精度
        
    if (mNumResyncSamples == 0) {   
        mPhase = 0;
        mReferenceTime = timestamp;  //参考时间设置为第一个硬件vsync的时间戳
        mThread->updateModel(mPeriod, mPhase, mReferenceTime);
    }   

    //更新 mNumResyncSamples 或 mFirstResyncSample的值
    if (mNumResyncSamples < MAX_RESYNC_SAMPLES) {
        mNumResyncSamples++;
    } else {
        mFirstResyncSample = (mFirstResyncSample + 1) % MAX_RESYNC_SAMPLES;
    }   

    // 开始计算更新SW vsync 模型
    updateModelLocked();

    //如果 mNumResyncSamplesSincePresent 大于4,重置 Error信息
    // mNumResyncSamplesSincePresent 表示的是当目前的硬件 vsync samples个数大于4个时,就重置error信息。
    // 注意,在硬件vsync被enable的条件下fence是无效的,所以在这里需要将error信息清空,
    // 但是为什么要大于MAX_RESYNC_SAMPLES_WITHOUT_PRESENT(4)时才去reset error信息呢?
    //注意: 当mNumResyncSamplesSincePresent大于4时,意味着已经保存有6个硬件Vsync样本了,自己好好算算,
    //由于在硬件Vsync在enable时fence无效,那么应该是每来一个硬件Vsync就应该要reset error呀?为啥还要等到6个过后才reset呢?
    //确实是这样的,但是在updateModelLocked中,要更新SW vsync模型,至少得有6个及以上的样本才行,所以至少要有6个硬件vsync样本,
    //所以fense在前6个硬件vsync样本都是无效的,因此不必每次都reset,只要它大于6个过后再reset,真的是细思极恐啊。
    if (mNumResyncSamplesSincePresent++ > MAX_RESYNC_SAMPLES_WITHOUT_PRESENT) {
        resetErrorLocked();
    }   

    if (kIgnorePresentFences) {
        // If we don't have the sync framework we will never have
        // addPresentFence called.  This means we have no way to know whether
        // or not we're synchronized with the HW vsyncs, so we just request
        // that the HW vsync events be turned on whenever we need to generate
        // SW vsync events.
        return mThread->hasAnyEventListeners();
    }   
    // Check against kErrorThreshold / 2 to add some hysteresis before having to
    // resync again
    // 如果模型更新了,并且产生的错误小于 kErrorThreshold/2 这个值 (这个值是错误容忍度),那么 modelLocked就被置为true, 即模型被锁定,模型被锁定的含义是
    // 现在SW vsync工作的很好,暂时不需要硬件Vsync来进行校正了,最后会将硬件Vsync给disable掉
    bool modelLocked = mModelUpdated && mError < (kErrorThreshold / 2);
    ALOGV("[%s] addResyncSample returning %s", mName,
            modelLocked ? "locked" : "unlocked");
    return !modelLocked;
}

接下来继续看下是怎样更新模型里的参数的

5.2.4 updateModelLocked更新模型参数

updateModelLocked函数是根据已经保存的硬件Vsync样本来计算模型的参数。

void DispSync::updateModelLocked() {
    // 如果已经保存了6个以上的 硬件 vsync 样本后,就要开始计算 sw vsync模型了
    if (mNumResyncSamples >= MIN_RESYNC_SAMPLES_FOR_UPDATE) {
        nsecs_t durationSum = 0;
        nsecs_t minDuration = INT64_MAX;
        nsecs_t maxDuration = 0;
        //还记得上面 如果 mNumResyncSamples=0,即第一个硬件vsync时,直接更新SW vsync模型了,所以这里把第一个给去除掉
        for (size_t i = 1; i < mNumResyncSamples; i++) {
            size_t idx = (mFirstResyncSample + i) % MAX_RESYNC_SAMPLES;
            size_t prev = (idx + MAX_RESYNC_SAMPLES - 1) % MAX_RESYNC_SAMPLES;
            
            // mResyncSamples[idx] - mResyncSamples[prev] 这个差值就是计算出两个硬件vsync样本之间的时间间隔
            nsecs_t duration = mResyncSamples[idx] - mResyncSamples[prev];
            // durationSum 表示保存的所有样本(除去第一个vsync)时间间隔之后,用于后面计算 平均 mPeriod
            durationSum += duration;  
            minDuration = min(minDuration, duration);
            maxDuration = max(maxDuration, duration);
        }

        // 去掉一个最小,一个最大值再来计算平均值,这个平均值就是硬件vsync产生的时间间隔
        // Exclude the min and max from the average
        durationSum -= minDuration + maxDuration;
        // 这里减去3是 一个最大,一个最小,还有第一个硬件vsync
        mPeriod = durationSum / (mNumResyncSamples - 3);

       //下面计算出模型需要的偏移, 因为现在 mPeriod 算出来的是平均值,所以并不是真的硬件vsync时间间隔就是 mPeriod, 存在着偏移与噪音(这个和样本个数有很大的关系)
       // 即有些样本信号的时间间隔大于平均值,而有些样本时间间隔小于平均值,而这些与 mPriod的差值就是偏移
       // 下面就是要算出这些平均的偏移值
        double sampleAvgX = 0;
        double sampleAvgY = 0;
        //将硬件vsync的时间间隔换算成对应的度数,即刻度,这里的刻度表示每ns代表多少度 
        double scale = 2.0 * M_PI / double(mPeriod);
        // Intentionally skip the first sample
        //同样去掉第一个样本
        for (size_t i = 1; i < mNumResyncSamples; i++) {
            size_t idx = (mFirstResyncSample + i) % MAX_RESYNC_SAMPLES;
            nsecs_t sample = mResyncSamples[idx] - mReferenceTime;
           // 这里对mPeriod取余就是相对于mPeriod倍数的偏移值,然后将其转换成对应的度数
            double samplePhase = double(sample % mPeriod) * scale;
            sampleAvgX += cos(samplePhase); //依次累加成 sampleAvgX
            sampleAvgY += sin(samplePhase); //依次累加成 sampleAvgY
        }

        //获得在x轴与y轴的偏移的平均值
        sampleAvgX /= double(mNumResyncSamples - 1);
        sampleAvgY /= double(mNumResyncSamples - 1);

       //最后再通过atan2获得最终的相移值
        mPhase = nsecs_t(atan2(sampleAvgY, sampleAvgX) / scale);

        //如果相移偏过了mPeriod的一半,那么重新调整一下
        if (mPhase < -(mPeriod / 2)) {
            mPhase += mPeriod;
            ALOGV("[%s] Adjusting mPhase -> %" PRId64, mName, ns2us(mPhase));
        }

        if (kTraceDetailedInfo) {
            ATRACE_INT64("DispSync:Period", mPeriod);
            ATRACE_INT64("DispSync:Phase", mPhase + mPeriod / 2);
        }

        // 这个 mRefreshSkipCount 一般为0,它的意思是多少个vsync才进行刷新,即人为的降低显示设备的刷新率了
       // mRefreshSkipCount 通过 setRefreshSkipCount来设置
        // Artificially inflate the period if requested.
        mPeriod += mPeriod * mRefreshSkipCount;

      // 将最新的 偏移 mPhase和 vsync时间间隔mPeriod和mReferenceTime更新到SW vsync模型当中
        mThread->updateModel(mPeriod, mPhase, mReferenceTime);
        
      // 模型更新了
        mModelUpdated = true;
    }
}

下面来看下几个比较重要的变量

  1. 硬件vsync样本个数 MIN_RESYNC_SAMPLES_FOR_UPDATE
    要6个硬件vsync样本以上才计算,当然样本越多,模型越精确
  2. mPeriod
    即是显示屏的刷新率,这里mPeriod是根据样本个数去掉一个最大一个最小,算平均
  3. mPhase
    这个是偏移移时间,这个相称和具体的SF/APP Thread里固定的相称是不一样的,这个相移是针对 mPeroid的一个偏移。
  4. mModelUpdated
    这个bool变量表示是否模型已经更新了
  5. mReferenceTime
    这个是第一个硬件Vsync的时间,每次SW vsync计算下一个vsync时间时,都是以该时间作为基准,这样可以减少误差。
    为什么不以上一个SW vsync时间为基准呢?
    想像一下,如果SW vsync的每一个Vsync都以上一个vsync时间作为基准,那相当于误差就会不停的累加,而如果以第一个硬件vsync时间作基准,那每次vsync的误差是不会累加的。

图3 相移图

        //将硬件vsync的时间间隔换算成对应的度数,即刻度,这里的刻度表示每ns代表多少度 
        double scale = 2.0 * M_PI / double(mPeriod);
        // Intentionally skip the first sample
        //同样去掉第一个样本
        for (size_t i = 1; i < mNumResyncSamples; i++) {
            size_t idx = (mFirstResyncSample + i) % MAX_RESYNC_SAMPLES;
            nsecs_t sample = mResyncSamples[idx] - mReferenceTime;
           // 这里对mPeriod取余就是相对于mPeriod倍数的偏移值,然后将其转换成对应的度数
            double samplePhase = double(sample % mPeriod) * scale;
            sampleAvgX += cos(samplePhase); //依次累加成 sampleAvgX
            sampleAvgY += sin(samplePhase); //依次累加成 sampleAvgY
        }

        //获得在x轴与y轴的偏移的平均值
        sampleAvgX /= double(mNumResyncSamples - 1);
        sampleAvgY /= double(mNumResyncSamples - 1);

       //最后再通过atan2获得最终的相移值
        mPhase = nsecs_t(atan2(sampleAvgY, sampleAvgX) / scale);

图4 相移计算公式

 

mPhase对应的角度Angle是通过atan2(sampleAvgY, sampleAvgX)计算出来的,
最后将角度/scale即可得到相移,单位也是纳秒.

5.2.3 计算SW vsync下一个vsync时间点

上面已经介绍了DispSync模型了,且模型已经更新好了,那就可以由SW vsync发出vsync信号了呀。
那接着5.1.1 DispSyncThread的threadLoop的下半部分代码分析

virtual bool threadLoop
{
        ...
    //计算下一次vsync事件的时间
    targetTime = computeNextEventTimeLocked(now);

    bool isWakeup = false;

    //如果计算出来的下一次vsync事件还没有到来,那就等着呗,等着时间到了,就发送SW VSYNC信号
    //可以看出 DispSyncThread的发送的vsync信号和真正硬件发生的vsync信号没有直接的关系,
       //发送给app/sf的vsync信号都是由 DispSyncThread发送出去的.
    if (now < targetTime) {
        if (kTraceDetailedInfo) ATRACE_NAME("DispSync waiting");

        if (targetTime == INT64_MAX) {
            err = mCond.wait(mMutex);
        } else {
                        //等着SW VSYNC时间到了,就唤醒,开始发送vsync信号
            err = mCond.waitRelative(mMutex, targetTime - now);
        }

        if (err == TIMED_OUT) {
                        //mCond 是自己醒的,即在targetTime-now时间后醒来的,那就要计算wake up的时间
            isWakeup = true;
        } else if (err != NO_ERROR) {
            ALOGE("error waiting for next event: %s (%d)",
                    strerror(-err), err);
            return false;
        }
    }
    
    now = systemTime(SYSTEM_TIME_MONOTONIC);

     //计算wake up时间, 但是不能超过1.5 ms
    // Don't correct by more than 1.5 ms
    static const nsecs_t kMaxWakeupLatency = us2ns(1500);

    if (isWakeup) {
        // mWakeupLatency 醒来时间是累加的,这个在后面计算SW vsync的时间有用, 不过所有的wake up时间最大不能超过1.5 ms, 这点延迟就是代码上的延迟了,看来Google计算的很严谨呀
        mWakeupLatency = ((mWakeupLatency * 63) + (now - targetTime)) / 64; 
        mWakeupLatency = min(mWakeupLatency, kMaxWakeupLatency);
        if (kTraceDetailedInfo) {
            ATRACE_INT64("DispSync:WakeupLat", now - targetTime);
            ATRACE_INT64("DispSync:AvgWakeupLat", mWakeupLatency);
        }   
    }   

    //收集回调的EventListener, 注意,前面已经加入了eventlistener,参见5.1.2 所以callbackInvocations.size()肯定大于0
    callbackInvocations = gatherCallbackInvocationsLocked(now);
    
    if (callbackInvocations.size() > 0) {
        //向SF/APP EventThread发送Vsync信号                                                                                                           
        fireCallbackInvocations(callbackInvocations);
    }
}

接着来看下SW vsync模型是怎样计算vsync时间的呢

nsecs_t computeNextEventTimeLocked(nsecs_t now) {
    if (kTraceDetailedInfo) ATRACE_CALL();
    nsecs_t nextEventTime = INT64_MAX;
    //对所有的EventListener进行分别计算,里面的mLastEventTime值不同
    for (size_t i = 0; i < mEventListeners.size(); i++) {
        nsecs_t t = computeListenerNextEventTimeLocked(mEventListeners[i],now);
        if (t < nextEventTime) {
            nextEventTime = t;
        }
    }
    return nextEventTime;
}

这里其实就最多只有两种EventListener, 一个是SF EventThread,一个是App EventThread,它们都需要接收Vsync信号来分别做不同的事情。
但是实际上两个线程都有一个偏移,见2.1,它们工作既保持一定的节拍,又可以相互错开,一前一后保持着咚次哒次, 还可以让CPU能错开工作高峰。
见 Android 5.1 SurfaceFlinger VSYNC详解

图5 Vsync phase

nsecs_t computeListenerNextEventTimeLocked(const EventListener& listener,
        nsecs_t baseTime) {
    if (kTraceDetailedInfo) ATRACE_CALL();
    
    // lastEventTime 是求的是上一次vsync事件的时间,它等于上一次vsync事件加上wake up时间
    // 一般来说baseTime应该不会小于 lastEventTime
   // 也有小于的情况,比如第一次,threadLoop的now生成的时间比较早,而 addEventListener 发生的比较晚。
   // 而listener的lastEventTime设为了当前的系统时间,这时baseTime 就会小于 lastEventTime
    nsecs_t lastEventTime = listener.mLastEventTime + mWakeupLatency;
    if (baseTime < lastEventTime) {
        //重新修正 baseTime
        baseTime = lastEventTime;
    }
    // baseTime 减去参考的时间,这个 mReferenceTime就是第一个硬件Vsync样本的时间
    baseTime -= mReferenceTime;
    // phase偏移, mPhase是通过硬件vsync的样本计算出来的,而listener.mPhase是固定的具体是在编译时设置的
    // sf 使用的是 SF_VSYNC_EVENT_PHASE_OFFSET_NS;
    //而APP使用的VSYNC_EVENT_PHASE_OFFSET_NS
    nsecs_t phase = mPhase + listener.mPhase;
    
   // 减去偏移
    baseTime -= phase;

    // If our previous time is before the reference (because the reference
    // has since been updated), the division by mPeriod will truncate
    // towards zero instead of computing the floor. Since in all cases
    // before the reference we want the next time to be effectively now, we
    // set baseTime to -mPeriod so that numPeriods will be -1.
    // When we add 1 and the phase, we will be at the correct event time for
    // this period.
    if (baseTime < 0) {
        baseTime = -mPeriod;
    }

   //下面是求出下一时刻发送 sw vsync的时间,这个时间是以第一个硬件vsync作为参考来这样计算
   //为什么不是以上一个sw vsync时间作为参考呢?为什么要以第一个硬件vsync时间作为参考呢?
   //如果以一个sw vsync时间作为参考,因为sw vsync的时间本身就是一种根据模型模拟出来的,所以本身存在误差,所以如果每个sw vsync以上一个作为base的话,
   //那么它的误差会慢慢积累。
   //而每次以第一个硬件vsync时间作为基准,那么每个sw vsync的误差,并不会累加,这样就相对来说更加精确些
    nsecs_t numPeriods = baseTime / mPeriod;
   //算出距离第一个硬件Vsync时间的偏移,即得到下一个sw vsync的时间,numPeriods + 1,注意是下一个vsync的时间
    nsecs_t t = (numPeriods + 1) * mPeriod + phase;
   // 这个时间t是相对于每一个硬件 vsync的时间
    t += mReferenceTime;

    // 如果这个vsync距离上一个vsync时间小于3/5个mPeriod的话,为了避免连续的两个sw vsync, 那么这次sw vsync就放弃了,直接放到下一个周期里
    // Check that it's been slightly more than half a period since the last
    // event so that we don't accidentally fall into double-rate vsyncs
    if (t - listener.mLastEventTime < (3 * mPeriod / 5)) {
        t += mPeriod;
    }

  // 当然算出来的时间要减去wake up的时间了,这样才能精确的模拟硬件vsync的时间, 注意 mWakeupLatency 是所有wake up的时间累加,但是最大只能到1.5ms
    t -= mWakeupLatency;

    return t;
}

继续看下 gatherCallbackInvocationsLocked

Vector gatherCallbackInvocationsLocked(nsecs_t now) {
    if (kTraceDetailedInfo) ATRACE_CALL();
    ALOGV("[%s] gatherCallbackInvocationsLocked @ now %" PRId64, mName,
            ns2us(now));

    Vector callbackInvocations;
    //因为computeListenerNextEventTimeLocked计算的是下一个vsync时间,那么这一次的vsync就以上now - mPeriod作为基准时间
    nsecs_t onePeriodAgo = now - mPeriod;

    for (size_t i = 0; i < mEventListeners.size(); i++) {                                                                                                         
        nsecs_t t = computeListenerNextEventTimeLocked(mEventListeners[i],
                onePeriodAgo);

        if (t < now) {
            CallbackInvocation ci; 
            ci.mCallback = mEventListeners[i].mCallback;
            ci.mEventTime = t;
            callbackInvocations.push(ci);
            //记录SW vsync的时间
            mEventListeners.editItemAt(i).mLastEventTime = t;
        }   
    }   

    return callbackInvocations;
} 

到这里基本上说完了DispSync更新模型,以及计算SW Vsync时间。那到这里完了么?还没有呐,现在SW vsync已经按需要由DispSync发出了,但这就完全和硬件Vsync信号保持一致了么?还不一定,所以还需要看下SW vsync与硬件Vsync之间的误差是否还在可接收范围内。

5.2.4 更新SW Vsync的误差值

SurfaceFlinger在收到SW Vsync信号后就要去渲染,做图像的合成,在渲染完后会调用postComposition函数,

5.2.4.1 postComposition

void SurfaceFlinger::postComposition(nsecs_t /*refreshStartTime*/)
{
    mAnimFrameTracker.setPostCompositionTime(mPostCompositionTimestamp);
    const LayerVector& layers(mDrawingState.layersSortedByZ);
    const size_t count = layers.size();
    for (size_t i=0 ; ionPostComposition(mPostCompositionTimestamp);
    }    

    // 通过 HWComposer 获得 Fence
    const HWComposer& hwc = getHwComposer();
    sp presentFence = hwc.getDisplayFence(HWC_DISPLAY_PRIMARY);

    //注意,如果硬件vsync已经被打开了,那么fence是无效了,只有它在关闭的情况下,它才有效
    if (presentFence->isValid()) {
        if (mPrimaryDispSync.addPresentFence(presentFence)) {
            ALOGD("in setPostCompositionTime will enableHardwareVsync");
            enableHardwareVsync();
        } else {
            disableHardwareVsync(false);
        }    
    }    
}

5.2.4的updateModelLocked函数可知,当更新SW Vsync模型后,就会关闭硬件Vsync信号,这时候Fence就有效了, 对于 Fence, 可以参考Android中的GraphicBuffer同步机制-Fence, 这里简单的理解就是拿到真实硬件Vsync的状态,包含硬件Vsync发生的时间.

5.2.4.2 addPresentFence

bool DispSync::addPresentFence(const sp& fence) {
    Mutex::Autolock lock(mMutex);

   // 将当前硬件vsync的fence保存在 mPresentFences里, 目的是为了计算偏移
  // mPresentFences 最多保存8个硬件 偏移
    mPresentFences[mPresentSampleOffset] = fence;
    mPresentTimes[mPresentSampleOffset] = 0; 
    mPresentSampleOffset = (mPresentSampleOffset + 1) % NUM_PRESENT_SAMPLES;
    mNumResyncSamplesSincePresent = 0; // 将 mNumResyncSamplesSincePresent 置为0,

    for (size_t i = 0; i < NUM_PRESENT_SAMPLES; i++) {
        const sp& f(mPresentFences[i]);
        if (f != NULL) {  //这里 f 是有可能为NULL, 即只有一个 硬件 vsync 偏移时
            nsecs_t t = f->getSignalTime();  //猜测这个就是硬件 vsync的时间
            if (t < INT64_MAX) {
                mPresentFences[i].clear();
              //将每个vsync时间戳记录在 mPresentTimes 里,这里 kPresentTimeOffset是可以配置的,即可调的
                mPresentTimes[i] = t + kPresentTimeOffset;
            }
        }
    }
   //更新错误信息
    updateErrorLocked();

    // 这里,一般的情况是 mModelUpdated 已经被更新了,然后硬件vsync被disable了,
    // 所以这里只需要看SW vsync的真实的硬件vsync的误差是否在可
    // 允许的范围内即可
    return !mModelUpdated || mError > kErrorThreshold;
}

addPresentFence最后的返回, mError是方差,见下面5.2.4.3分析,当方差大于 kErrorThreshold后就返回true

return !mModelUpdated || mError > kErrorThreshold;

5.2.4.3 updateErrorLocked

void DispSync::updateErrorLocked() {
    if (!mModelUpdated) {
        return;
    }

    // Need to compare present fences against the un-adjusted refresh period,
    // since they might arrive between two events.
    
    //得到真实的 period, 具体见 5.2.4 updateModelLocked 里的分析
    nsecs_t period = mPeriod / (1 + mRefreshSkipCount);

    int numErrSamples = 0;
    nsecs_t sqErrSum = 0;

   //这里的 mReferenceTime 是第一个硬件vsync的时间戳 见 addResyncSample里的 mReferenceTime
    for (size_t i = 0; i < NUM_PRESENT_SAMPLES; i++) {
        nsecs_t sample = mPresentTimes[i] - mReferenceTime;
       // 这里 sample 一般来说是大于偏移的
        if (sample > mPhase) {
            nsecs_t sampleErr = (sample - mPhase) % period;
            if (sampleErr > period / 2) {
                sampleErr -= period;
            }
            //记录 偏移差的平方和
            sqErrSum += sampleErr * sampleErr;
            numErrSamples++;
        }
    }

     // 说到底mError就是方差
    if (numErrSamples > 0) {
        mError = sqErrSum / numErrSamples;
    } else {
        mError = 0;
    }

    if (kTraceDetailedInfo) {
        ATRACE_INT64("DispSync:Error", mError);
    }
}

5.2.4.4 硬件

接着返回 5.2.4.1 postComposition的最后,

        if (mPrimaryDispSync.addPresentFence(presentFence)) {
            ALOGD("in setPostCompositionTime will enableHardwareVsync");
            enableHardwareVsync();
        } else {
            disableHardwareVsync(false);
        }    

如果 addPresentFence见5.2.4.2 返回true, 那么就说明SW vsync和硬件Vsync的误差已经无法接受了,那么这时就得重新打开硬件Vsync,来重新调节SW vsync模型了。

六、总结

写文章太累了...



作者:wbo4958
链接:https://www.jianshu.com/p/d3e4b1805c92
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

你可能感兴趣的:(android进阶之爬坑,android,surfaceflinger,Vsync,SW,Vsync,APP,VSync)