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