GUI系统之SurfaceFlinger(12)VSync信号的产生和处理

文章都是通过阅读源码分析出来的,还在不断完善与改进中,其中难免有些地方理解得不对,欢迎大家批评指正。
转载请注明:From LXS. http://blog.csdn.net/uiop78uiop78/

GUI系统之SurfaceFlinger章节目录:
blog.csdn.net/uiop78uiop78/article/details/8954508


1.1 VSync的产生和处理

前面小节ProjectButter中我们学习了Android 4.1显示系统中的新特性,其中一个就是加入了VSync同步。我们从理论的角度分析了采用这一机制的必要性和运作机理,那么SurfaceFlinger具体是如何实施的呢?

先来想一下有哪些东西要考虑:

·          VSync信号的产生和分发

如果有硬件主动发出这一信号,那是最好的了;否则就得通过软件定时模拟来产生

·          VSync信号的处理

当信号产生后,SurfaceFlinger如何在最短的时间内响应,具体处理流程是怎么样子的

1.1.1 VSync信号的产生和分发

在Android源码surfaceflinger目录下有一个displayhardware文件夹,其中HWComposer的主要职责之一,就是用于产生VSync信号。

/*frameworks/native/services/surfaceflinger/displayhardware/HWComposer.cpp*/

HWComposer::HWComposer(const sp<SurfaceFlinger>& flinger,EventHandler& handler, nsecs_t refreshPeriod)

: mFlinger(flinger), mModule(0), mHwc(0), mList(0), mCapacity(0),mNumOVLayers(0),

 mNumFBLayers(0), mDpy(EGL_NO_DISPLAY),mSur(EGL_NO_SURFACE),

      mEventHandler(handler),mRefreshPeriod(refreshPeriod),

      mVSyncCount(0),mDebugForceFakeVSync(false)

{

    charvalue[PROPERTY_VALUE_MAX];

   property_get("debug.sf.no_hw_vsync", value, "0"); //系统属性

    mDebugForceFakeVSync =atoi(value);

    bool needVSyncThread =false;//是否需要软件模拟VSync

    int err = hw_get_module(HWC_HARDWARE_MODULE_ID, &mModule);//加载HAL模块

    if (err == 0) {

        err = hwc_open(mModule, &mHwc);//打开module

        if (err == 0) {

if(mHwc->registerProcs) { //注册硬件设备事件回调

                mCBContext.hwc= this;

               mCBContext.procs.invalidate = &hook_invalidate;

               mCBContext.procs.vsync = &hook_vsync;

                mHwc->registerProcs(mHwc, &mCBContext.procs);

               memset(mCBContext.procs.zero, 0, sizeof(mCBContext.procs.zero));

            }

            if(mHwc->common.version >= HWC_DEVICE_API_VERSION_0_3) {

                if(mDebugForceFakeVSync) {//用于调试

                   mHwc->methods->eventControl(mHwc, HWC_EVENT_VSYNC, 0);

                }

            } else {//有可能支持VSync的硬件模块是这个版本以后才加入的,老版本仍然需要软件模拟

               needVSyncThread = true;

            }

        }

    } else {

        needVSyncThread =true; //硬件模块打开失败,只能用软件模拟

    }

    if (needVSyncThread) {

        mVSyncThread = new VSyncThread(*this);//创建一个产生VSync信号的线程

    }

}

这个函数的核心就是决定VSync的“信号发生源”——硬件或者软件模拟。

假如当前系统可以成功加载HWC_HARDWARE_MODULE_ID=“hwcomposer”,并且通过这个库模块能顺利打开设备(hwc_composer_device_t),其版本号又大于HWC_DEVICE_API_VERSION_0_3的话,我们就采用“硬件源”(此时needVSyncThread为false),否则需要创建一个新的VSync线程来模拟产生信号。

(1)硬件源

如果mHwc->registerProcs不为空的话,我们注册硬件回调mCBContext.procs。定义如下:

    struct cb_context{

        callbacksprocs;

        HWComposer*hwc;

    };

调用registerProcs()时,传入的参数是&mCBContext.procs。后期当有事件产生时,比如vsync或者invalidate,硬件模块将分别通过procs.vsync和procs.invalidate来通知HWComposer。

void HWComposer::hook_vsync(struct hwc_procs* procs, int dpy,int64_t timestamp) {

   reinterpret_cast<cb_context *>(procs)->hwc->vsync(dpy,timestamp);

}

上面这个函数中,procs即前面的&mCBContext.procs,从指针地址上看它和&mCBContext是一致的,因而我们可以强制类型转换为cb_context来进行操作,并由此访问到hwc中的vsync实现:

void HWComposer::vsync(int dpy, int64_t timestamp) {

   mEventHandler.onVSyncReceived(dpy, timestamp);

}

HWComposer将VSync信号直接通知给mEventHandler,这个Handler由HWComposer构造时传入,换句话说,我们需要看下是谁创建了HWComposer。

/*frameworks/native/services/surfaceflinger/displayhardware/DisplayHardware.cpp*/

void DisplayHardware::init(uint32_t dpy)

{…

mHwc = newHWComposer(mFlinger, *this, mRefreshPeriod);

从这里可以看出来,HWComposer中的mEventHandler就是DisplayHardware对象,所以后者必须要继承自HWComposer::EventHandler,以此处理产生的onVSyncReceived事件。

(2)软件源

软件源和硬件源的最大区别是它需要启动一个新线程VSyncThread,其运行优先级与SurfaceFlinger的工作线程是一样的,都是-9。从理论的角度讲,任何通过软件定时来实现的机制都不可能是100%可靠的,即使优先级再高也可能出现延迟和意外。不过如果“不可靠”的机率很小,而且就算出现意外时不至于是致命错误,那么还是可以接受的。所以说VSyncThread从实践的角度来讲,的确起到了很好的作用。

bool HWComposer::VSyncThread::threadLoop() {

   /*Step1. 系统是否使能了VSync信号发生机制*/

    { // 自动锁控制范围

        Mutex::Autolock_l(mLock);

        while (!mEnabled) {//VSync信号开关

           mCondition.wait(mLock);

        }

    }

    /*Step2. 计算产生VSync信号的时间*/

    const nsecs_t period = mRefreshPeriod;//信号的产生间隔

    const nsecs_t now =systemTime(CLOCK_MONOTONIC);

    nsecs_t next_vsync =mNextFakeVSync;//产生信号的时间

    nsecs_t sleep = next_vsync- now; //需要休眠的时长

    if (sleep < 0) {//已经过了时间点

        sleep = (period - ((now - next_vsync) %period));

        next_vsync = now +sleep;

    }

    mNextFakeVSync =next_vsync + period; //再下一次的VSync时间

    struct timespec spec;

    spec.tv_sec  = next_vsync / 1000000000;

    spec.tv_nsec = next_vsync% 1000000000;

 

    int err;

    do {

        err = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &spec, NULL);//进入休眠

    } while (err<0&& errno == EINTR);

 

    if (err == 0) {

        mHwc.mEventHandler.onVSyncReceived(0, next_vsync);//和硬件源是一样的回调

    }

    return true;

}

Step1@ VSyncThread::threadLoop. 关于自动锁的使用我们已经分析过很多次了,不再赘述。这里要注意的是mEnabled这个变量,它是用于控制是否产生VSync信号的一个使能变量。当系统希望关闭VSync信号发生源时,调用VSyncThread::setEnabled(false),否则传入true。假如mEnabled为false时,VSyncThread就处于等待状态,直到有人再次使能这个线程。

Step2@ VSyncThread::threadLoop. 接下来的代码用于真正产生一个VSync信号。可以想象一下,无非就是这些步骤:

·          计算下一次产生VSync信号的时间

·          进入休眠

·          休眠时间到了后,就代表应该发出VSync信号了,通知感兴趣的人

·          循环往复

 

变量mRefreshPeriod指定了产生VSync信号的间隔。它是在DisplayHardware::init中计算出来的:

mRefreshPeriod = nsecs_t(1e9 / mRefreshRate);

如果mRefreshRate为60Hz的话,mRefreshPeriod就差不多是16ms。

因为mNextFakeVSync代表的是“下一次”产生信号的时间点,所以首先将next_vsync=mNextFakeVSync。接着计算sleep,也就是离产生信号的时间点还有多长(同时也是需要休眠的时间)。那么如果sleep的结果小于0呢?代表我们已经错过了这一次产生信号的最佳时间点,这是有可能发生的。在这种情况下,就计算下一次最近的VSync离现在还剩多少时间,公式如下:

sleep = (period - ((now - next_vsync) % period));

我们以下图来表述下采用这个公式的依据:


图 11‑33 休眠时间推算简图

 

这个图的前提是now超时时间不超过一个period。因而公式中还要加上%period。

计算完成sleep后,mNextFakeVSync= next_vsync +period。这是因为mNextFakeVSync代表的是下一次threadLoop需要用到的时间点,而next_vsync是指下一次(最近一次)产生VSync的时间点。

如何在指定的时间点再产生信号呢?有两种方法,其一是采用定时器回调,其二就是采用休眠的形式主动等待,这里使用的是后一种。

可想而知这里的时间要尽可能精准,单位是nanosecond,即纳秒级。函数clock_nanosleep的第一个入参是CLOCK_MONOTONIC,这种时钟更加稳定,且不受系统时间的影响。

当休眠时间到了后,表示产生信号的时刻到了。根据前面的分析,就是通过mEventHandler.onVSyncReceived()回调来通知对消息感兴趣的人,这个做法软硬件都一样。

一次信号产生完成后,函数直接返回true,似乎没有看到循环的地方?这是因为当threadLoop返回值为“真”时,它将被系统再一次调用,从而循环起来。不清楚的可以参阅一下Thread类的实现。

 

接下来看下DisplayHardware如何处理这个VSync信号的。

中间过程很简单,我们就不一一解释。在DisplayHardware::onVSyncReceived中,它又再次调用内部mVSyncHandler的onVSyncReceived(),将消息向上一层传递。这个变量由EventThread在onFirstRef时通过DisplayHardware::setVSyncHandler()设置,代表的是EventThread对象本身,如下:

void EventThread::onFirstRef() {

   mHw.setVSyncHandler(this);//this指针代表EventThread对象

 

所以VSync信号被进一步递交到了EventThread中。显然,它也不是终点。

void EventThread::onVSyncReceived(int, nsecs_t timestamp) {

    Mutex::Autolock _l(mLock);

    mVSyncTimestamp =timestamp;

    mCondition.broadcast();//有人在等待事件的到来

}

等待VSync事件的地方很多,其中最重要的是EventThread::threadLoop(),这个函数将负责对VSync进行分发,决定谁有权利来最终处理这一事件。

这个函数的主体逻辑还是比较简单的,不过因为很长,内部又夹杂着多个循环体,显得不好理解,因此我们只摘选最重要的一部分来加快大家的阅读。

bool EventThread::threadLoop() {

    nsecs_t timestamp;

   DisplayEventReceiver::Event vsync;

    Vector<wp<EventThread::Connection> > displayEventConnections;

    do {//Step1. 第一个循环体

        Mutex::Autolock_l(mLock);

        do {…//Step2. 第二个循环体,决定是否上报VSync

        } while(true);

 

        //跳出循环,接下来就要准备分发VSync了

        mDeliveredEvents++;

        mLastVSyncTimestamp =timestamp;

 

        const size_t count =mDisplayEventConnections.size();

        for (size_t i=0 ;i<count ; i++) {

            …//Step3. 第三个循环中逐个判断各connection是否需要上报

            if (reportVsync) {

                displayEventConnections.add(connection);

            }

        }

    } while(!displayEventConnections.size());//只要size不等于0就可以退出循环了

 

    // 终于开始分发了。。。

    vsync.header.type =DisplayEventReceiver::DISPLAY_EVENT_VSYNC;

    vsync.header.timestamp =timestamp;

vsync.vsync.count =mDeliveredEvents;

const size_t count =displayEventConnections.size();

    for (size_t i=0 ;i<count ; i++) {//Step4. 第四个循环体,分发事件

        sp<Connection>conn(displayEventConnections[i].promote());

        if (conn != NULL) {

            status_t err =conn->postEvent(vsync);//通知connection发起者

            if (err == -EAGAIN|| err == -EWOULDBLOCK) {

                //这两个错误是指对方当前不接受事件,有可能是暂时性的

            } else if (err< 0) {

                //发生了致命错误,一律移除

               removeDisplayEventConnection(displayEventConnections[i]);

            }

        } else {//connection已经死了,将它移除

           removeDisplayEventConnection(displayEventConnections[i]);

        }

    }

   …

    return true;

}

一共有四个循环体,看起来很乱,我们先以伪代码的形式来重新表述一遍:

do {//第一个循环体

   do {

//第二个循环体,判断当前系统是否允许上报VSync

   } while(true);

   for (size_t i=0 ; i<count ; i++) {

      //第三个循环体,逐个计算需要上报的connection个数

   }

} while (!displayEventConnections.size());/*一旦需要上报的连接数超过0,

就可以退出循环了*/

for (size_t i=0 ; i<count ; i++) {

/*第四个循环,开始实际的分发。这时要先考虑connection是否死亡,然后就是判断分发后是否有异常返回,比如EWOULDBLOCK等等。对于暂态的错误,理论上是要再重发的,不过当前系统还没有这么做。的确,一方面这将使程序逻辑变得复杂,另一方面,即便丢一两个VSYNC,也无伤大局。所以从源代码注释来看,将来这部分也不会改善。*/

}

 

相信大家结合这段伪代码再来对照源码,就比较清楚了。

对VSYNC信号感兴趣的人,可以通过registerDisplayEventConnection()来与EventThread建立一个连接。搜索代码可以发现,当前系统中建立了连接的对象是MessageQueue,具体代码在MessageQueue::setEventThread()中。

我们以下图来总结本小节的内容:


图 11‑34 VSYNC信号的产生与分发

 

整体逻辑关系相对复杂,建议大家在做源码分析时,以下面两条线索进行:

l  VSync信号的传递流向

l  各个类的静态依赖关系。比如DisplayHardware持有一个HWComposer对象,同时这个对象的mEventHandler成员变量又指向DisplayHardware



©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值