Android 4.4 Graphic系统详解（2） VSYNC的生成

最新推荐文章于 2024-06-23 09:14:52 发布
最新推荐文章于 2024-06-23 09:14:52 发布
阅读量1.3k 收藏 2
点赞数
分类专栏： Android

http://blog.csdn.net/lee_3do/article/details/39288211

VSYNC 的概念

VSYNC（Vertical Synchronization）是一个相当古老的概念，对于游戏玩家，它有一个更加大名鼎鼎的中文名字—-垂直同步。
“垂直同步(vsync)”指的是显卡的输出帧数和屏幕的垂直刷新率相同，这完全是一个CRT显示器上的概念。其实无论是VSYNC还是垂直同步这个名字，因为LCD根本就没有垂直扫描的这种东西，因此这个名字本身已经没有意义。但是基于历史的原因，这个名称在图形图像领域被沿袭下来。
在当下，垂直同步的含义我们可以理解为，使得显卡生成帧的速度和屏幕刷新的速度的保持一致。举例来说，如果屏幕的刷新率为60Hz，那么生成帧的速度就应该被固定在1/60 s。

Android中的VSYNC — 黄油计划

从Android 4.1开始，谷歌致力于解决Android系统中最饱受诟病的一个问题，滑动不如iOS流畅。因谷歌在4.1版本引入了一个重大的改进—Project Butter，也即是黄油计划。
Project Butter对Android Display系统进行了重构，引入了三个核心元素，即VSYNC、Triple Buffer和Choreographer。关于后面两个概念我们会在后面开专题讲解，这里我们重点讲解VSYNC的作用。（关于黄油计划，网上已经有大量文字讲解说明，请参考http://blog.csdn.net/innost/article/details/8272867http://blog.csdn.net/xuesen_lin/article/details/8954869）。
玩过大型PC游戏的玩家都知道，VSYNC最重要的作用是防止出现画面撕裂（screentearing）。所谓画面撕裂，就是指一个画面上出现了两帧画面的内容，如下图。
此处输入图片的描述

为什么会出现这种情况呢？这种情况一般是因为显卡输出帧的速度高于显示器的刷新速度，导致显示器并不能及时处理输出的帧，而最终出现了多个帧的画面都留在了显示器上的问题。这也就是我们所说的画面撕裂。

提到垂直同步这里就多提一句，其实我认为对于PC上的大型游戏来说，只有配置足够高，高到显卡输出帧率可以稳定的高于显示器的刷新频率，才有开启垂直同步的必要。因为只有这个时候，画面撕裂才会真正成为一个问题。而对于很多情况下主机性能不足导致游戏输出帧率低于显示器的刷新频率的情况下，尤其是帧率稳定在40~60之间时，开启垂直同步可能会导致帧率倍数级的下降（具体原因我们在Graphic架构一文中提到过，当帧生成速度不及VSync速度时，帧率的下降不是平缓的，而且很可能是倍数级的。当然这在android系统上并非严重问题，因为android上很少有高速的复杂场景的频繁切换。事实上，在Android的普通应用场景下，VSync的使用不仅不会降低帧率，还可以有效解决卡顿问题）。

回到正文中来，那么VSync除了可以解决画面的撕裂的问题，还可以解决别的什么问题吗？我们来看下图：
此处输入图片的描述

这个图中有三个元素，Display是显示屏幕，GPU和CPU负责渲染帧数据，每个帧以方框表示，并以数字进行编号，如0、1、2等等。VSync用于指导双缓冲区的交换。
以时间的顺序来看下将会发生的异常：
Step1. Display显示第0帧数据，此时CPU和GPU渲染第1帧画面，而且赶在Display显示下一帧前完成
Step2. 因为渲染及时，Display在第0帧显示完成后，也就是第1个VSync后，正常显示第1帧
Step3. 由于某些原因，比如CPU资源被占用，系统没有及时地开始处理第2帧，直到第2个VSync快来前才开始处理
Step4. 第2个VSync来时，由于第2帧数据还没有准备就绪，显示的还是第1帧。这种情况被Android开发组命名为“Jank”。
Step5. 当第2帧数据准备完成后，它并不会马上被显示，而是要等待下一个VSync。
所以总的来说，就是屏幕平白无故地多显示了一次第1帧。原因大家应该都看到了，就是CPU没有及时地开始着手处理第2帧的渲染工作，以致“延误军机”。

其实总结上面的这个情况之所以发生，首先的原因就在于第二帧没有及时的绘制（当然即使第二帧及时绘制，也依然可能出现Jank，这就是同时引入三重缓冲的作用。我们将在三重缓冲一节中再讲解这种情况）。那么如何使得第二帧即使被绘制呢？
这就是我们在Graphic系统中引入VSYNC的原因，考虑下面这张图：

此处输入图片的描述

如上图所示，一旦VSync出现后，立刻就开始执行下一帧的绘制工作。这样就可以大大降低Jank出现的概率。另外，VSYNC引入后，要求绘制也只能在收到VSYNC消息之后才能进行，因此，也就杜绝了另外一种极端情况的出现—-CPU（GPU）一直不停的进行绘制，帧的生成速度高于屏幕的刷新速度，导致生成的帧不能被显示，只能丢弃，这样就出现了丢帧的情况—-引入VSYNC后，绘制的速度就和屏幕刷新的速度保持一致了。

VSYNC信号的生成

那么VSYNC信号是如何生成的呢？
Android系统中VSYNC信号分为两种，一种是硬件生成的信号，一种是软件模拟的信号。
硬件信号是由HardwareComposer提供的，HWC封装了相关的HAL层，如果硬件厂商提供的HAL层实现能定时产生VSYNC中断，则直接使用硬件的VSYNC中断，否则HardwareComposer内部会通过VSyncThread来模拟产生VSYNC中断（其实现很简单，就是sleep固定时间，然后唤醒）。

回到我们上一节中讲到的SurfaceFlinger的启动过程inti函数上来，上一节我们提到init函数内会创建一个HWComposer对象。

[cpp]  view plain copy 在CODE上查看代码片 派生到我的代码片
  1. HWComposer::HWComposer(  
  2.         const sp<SurfaceFlinger>& flinger,  
  3.         EventHandler& handler)  
  4.     : mFlinger(flinger),  
  5.       mFbDev(0), mHwc(0), mNumDisplays(1),  
  6.       mCBContext(new cb_context),  
  7.       mEventHandler(handler),  
  8.       mDebugForceFakeVSync(false)  
  9. {  
  10. ...  
  11.     //首先是一些和VSYNC有关的信息的初始化  
  12.     //因为在硬件支持的情况下，VSYNC的功能就是由HWC提供的  
  13.     for (size_t i=0 ; i<HWC_NUM_PHYSICAL_DISPLAY_TYPES ; i++) {  
  14.         mLastHwVSync[i] = 0;  
  15.         mVSyncCounts[i] = 0;  
  16.     }  
  17.     //根据配置来看是否需要模拟VSYNC消息  
  18.     char value[PROPERTY_VALUE_MAX];  
  19.     property_get("debug.sf.no_hw_vsync", value, "0");  
  20.     mDebugForceFakeVSync = atoi(value);  
  21.     ...  
  22.     // don't need a vsync thread if we have a hardware composer  
  23.     needVSyncThread = false;  
  24.     // always turn vsync off when we start,只是暂时关闭信号，后面会再开启  
  25.     eventControl(HWC_DISPLAY_PRIMARY, HWC_EVENT_VSYNC, 0);      
  26.   
  27.     //显然，如果需要模拟VSync信号的话，我们需要线程来做这个工作  
  28.     if (needVSyncThread) {  
  29.         // we don't have VSYNC support, we need to fake it  
  30.         //VSyncThread类的实现很简单，无非就是一个计时器而已，定时发送消息而已  
  31.         //TODO VSYNC专题  
  32.         mVSyncThread = new VSyncThread(*this);  
  33.     }  
  34. ...  
  35. }  
  36.   
  37. HWComposer::HWComposer(  
  38.         const sp<SurfaceFlinger>& flinger,  
  39.         EventHandler& handler)  
  40.     : mFlinger(flinger),  
  41.       mFbDev(0), mHwc(0), mNumDisplays(1),  
  42.       mCBContext(new cb_context),  
  43.       mEventHandler(handler),  
  44.       mDebugForceFakeVSync(false)  
  45. {  
  46. ...  
  47.     //首先是一些和VSYNC有关的信息的初始化  
  48.     //因为在硬件支持的情况下，VSYNC的功能就是由HWC提供的  
  49.     for (size_t i=0 ; i<HWC_NUM_PHYSICAL_DISPLAY_TYPES ; i++) {  
  50.         mLastHwVSync[i] = 0;  
  51.         mVSyncCounts[i] = 0;  
  52.     }  
  53.     //根据配置来看是否需要模拟VSYNC消息  
  54.     char value[PROPERTY_VALUE_MAX];  
  55.     property_get("debug.sf.no_hw_vsync", value, "0");  
  56.     mDebugForceFakeVSync = atoi(value);  
  57.     ...  
  58.     // don't need a vsync thread if we have a hardware composer  
  59.     needVSyncThread = false;  
  60.     // always turn vsync off when we start,只是暂时关闭信号，后面会再开启  
  61.     eventControl(HWC_DISPLAY_PRIMARY, HWC_EVENT_VSYNC, 0);      
  62.   
  63.     //显然，如果需要模拟VSync信号的话，我们需要线程来做这个工作  
  64.     if (needVSyncThread) {  
  65.         // we don't have VSYNC support, we need to fake it  
  66.         //VSyncThread类的实现很简单，无非就是一个计时器而已，定时发送消息而已  
  67.         //TODO VSYNC专题  
  68.         mVSyncThread = new VSyncThread(*this);  
  69.     }  
  70. ...  
  71. }  


我们来看下上面这段代码。
首先mDebugForceFakeVSync是为了调制，可以通过这个变量设置强制使用软件VSYNC模拟。
然后针对不同的屏幕，初始化了他们的mLastHwVSync和mVSyncCounts值。
如果硬件支持，那么就把needVSyncThread设置为false，表示不需要软件模拟。
接着通过eventControl来暂时的关闭了VSYNC信号，这一点将在下面讲解eventControl时一并讲解。
最后，如果需要软件模拟Vsync信号的话，那么我们将通过一个单独的VSyncThread线程来做这个工作(fake VSYNC是这个线程唯一的作用)。我们来看下这个线程。

软件模拟

[cpp]  view plain copy 在CODE上查看代码片 派生到我的代码片
  1. bool HWComposer::VSyncThread::threadLoop() {  
  2.     const nsecs_t period = mRefreshPeriod;  
  3.     //当前的时间  
  4.     const nsecs_t now = systemTime(CLOCK_MONOTONIC);  
  5.     //下一次VSYNC到来的时间  
  6.     nsecs_t next_vsync = mNextFakeVSync;  
  7.     //为了等待下个时间到来应该休眠的时间  
  8.     nsecs_t sleep = next_vsync - now;  
  9.     //错过了VSYNC的时间  
  10.     if (sleep < 0) {  
  11.         // we missed, find where the next vsync should be  
  12.         //重新计算下应该休息的时间  
  13.         sleep = (period - ((now - next_vsync) % period));  
  14.         //更新下次VSYNC的时间  
  15.         next_vsync = now + sleep;  
  16.     }  
  17.     //更新下下次VSYNC的时间  
  18.     mNextFakeVSync = next_vsync + period;  
  19.   
  20.     struct timespec spec;  
  21.     spec.tv_sec  = next_vsync / 1000000000;  
  22.     spec.tv_nsec = next_vsync % 1000000000;  
  23.   
  24.     int err;  
  25.     do {  
  26.         //纳秒精度级的休眠  
  27.         err = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &spec, NULL);  
  28.     } while (err<0 && errno == EINTR);  
  29.   
  30.     if (err == 0) {  
  31.         //休眠之后，到了该发生VSYNC的时间了  
  32.         mHwc.mEventHandler.onVSyncReceived(0, next_vsync);  
  33.     }  
  34.     return true;  
  35. }  


这个函数其实很简单，无非就是一个简单的时间计算，计算过程我已经写在了程序注释里面。总之到了应该发生VSYNC信号的时候，就调用了mHwc.mEventHandler.onVSyncReceived(0, next_vsync)函数来通知VSYNC的到来。

我们注意到mEventHandler实际上是在HWC创建时被传入的，我们来看下HWC创建时的代码.

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. mHwc = new HWComposer(this,  
  2.         *static_cast<HWComposer::EventHandler *>(this));  
  3.   
  4.   
  5. class SurfaceFlinger : public BnSurfaceComposer,  
  6.                    private IBinder::DeathRecipient,  
  7.                    private HWComposer::EventHandler  

可以看到这个mEventHandler实际上就是SurfaceFlinger。也就是说，VSYNC信号到来时，SurfaceFlinger的onVSyncReceived函数处理了这个消息。
这里我们暂时先不展开SurfaceFlinger内的逻辑处理，等我们下面分析完硬件实现后，一并进行分析

硬件实现

上面我们讲了软件如何模拟一个VSYNC信号并通知SurfaceFlinger,那么硬件又是如何实现这一点的呢？
我们再一次回到HWC的创建过程中来：

   
 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. if (mHwc) {  
  2.        ALOGE("Lee Using %s version %u.%u", HWC_HARDWARE_COMPOSER,  
  3.              (hwcApiVersion(mHwc) >> 24) & 0xff,  
  4.              (hwcApiVersion(mHwc) >> 16) & 0xff);  
  5.        if (mHwc->registerProcs) {  
  6.            mCBContext->hwc = this;  
  7.            mCBContext->procs.invalidate = &hook_invalidate;  
  8.            mCBContext->procs.vsync = &hook_vsync;  
  9.            if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1))  
  10.                mCBContext->procs.hotplug = &hook_hotplug;  
  11.            else  
  12.                mCBContext->procs.hotplug = NULL;  
  13.            memset(mCBContext->procs.zero, 0, sizeof(mCBContext->procs.zero));  
  14.            mHwc->registerProcs(mHwc, &mCBContext->procs);  
  15.        }  

来看下上面这段实现。
当HWC有vsync信号生成时，硬件模块会通过procs.vsync来通知软件部分，因此也就是调用了hook_vsync函数。

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. void HWComposer::hook_vsync(const struct hwc_procs* procs, int disp,  
  2.         int64_t timestamp) {  
  3.     cb_context* ctx = reinterpret_cast<cb_context*>(  
  4.             const_cast<hwc_procs_t*>(procs));  
  5.     ctx->hwc->vsync(disp, timestamp);  
  6. }  
  7.   
  8. void HWComposer::vsync(int disp, int64_t timestamp) {  
  9.     //只有真实的硬件设备才会产生VSYNC  
  10.     if (uint32_t(disp) < HWC_NUM_PHYSICAL_DISPLAY_TYPES) {  
  11.         {  
  12.             mLastHwVSync[disp] = timestamp;  
  13.         }  
  14.         mEventHandler.onVSyncReceived(disp, timestamp);  
  15. }  

我们发现最后殊途同归，硬件信号最终也通过onVSyncReceived函数通知到了SurfaceFlinger了。下面我们来分析下SurfaceFlinger的处理过程。

Surfaceflinger对VSYNC消息的处理

在4.4之前，本来SurfaceFlinger对VSYNC的处理比较简单，只是通知EventThread进行处理即可，但是KK再次对VSYNC这一段的逻辑进一步的细化和复杂化。不得不说，Google为了提升Android UI的流畅性真是费尽心思。

虽然只是一个简单的信号，但是KK的处理已经相当复杂。先来直接看下Surfaceflinger的onVSyncReceived函数：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. void SurfaceFlinger::onVSyncReceived(int type, nsecs_t timestamp) {  
  2.     bool needsHwVsync = false;  
  3.     {  
  4.         if (type == 0 && mPrimaryHWVsyncEnabled) {  
  5.             needsHwVsync = mPrimaryDispSync.addResyncSample(timestamp);  
  6.         }  
  7.     }  
  8.     if (needsHwVsync) {  
  9.         enableHardwareVsync();  
  10.     } else {  
  11.         disableHardwareVsync(false);  
  12.     }  
  13. }  

这段代码很短，但是相当让人困惑，困惑至少有以下三点：

  1. mPrimaryHWVsyncEnabled是干嘛的，是被什么时候赋值的？
  2. enableHardwareVsync和disableHardwareVsync又起到了什么作用？
  3. mPrimaryDispSync是什么？addResyncSample有什么作用？

Surfaceflinger的init函数

要回答这三个问题，我们首先还是得回到SurfaceFlinger的init函数中来。

EventThread的创建

上一节中SF的创建过程中我们提到了EventThread的创建。

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. {  
  2. ...  
  3.     // start the EventThread  
  4.     sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync,  
  5.             vsyncPhaseOffsetNs, true);  
  6.     mEventThread = new EventThread(vsyncSrc);  
  7.     sp<VSyncSource> sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync,  
  8.             sfVsyncPhaseOffsetNs, true);  
  9.     mSFEventThread = new EventThread(sfVsyncSrc);  
  10.     mEventQueue.setEventThread(mSFEventThread);  
  11.   
  12.     mEventControlThread = new EventControlThread(this);  
  13.     mEventControlThread->run("EventControl", PRIORITY_URGENT_DISPLAY);  
  14.   
  15.     // set a fake vsync period if there is no HWComposer  
  16.     if (mHwc->initCheck() != NO_ERROR) {  
  17.         mPrimaryDispSync.setPeriod(16666667);  
  18.     }  
  19. ...  
  20. }  

这里看起来更奇怪了。首先这里有两个看起来几乎一样的DispSyncSource，看起来唯一的区别就是一个偏移时间的不同。
而其实，这两个DispSyncSource就是KK引入的重大变化。Android 4.4(KitKat)引入了VSync的虚拟化，即把硬件的VSync信号先同步到一个本地VSync模型中，再从中一分为二，引出两条VSync时间与之有固定偏移的线程。示意图如下：
此处输入图片的描述
而Google这样修改的目的又是什么呢？
回忆一下我们在Graphic架构一文中指出的，在当前三重缓冲区的架构下，即对于一帧内容，先等App UI画完了，SurfaceFlinger再出场对其进行合并渲染后放入framebuffer，最后整到屏幕上。而现有的VSync模型是让大家一起开始干活。
这个架构其实会产生一个问题，因为App和SurfaceFlinger被同时唤醒，导致他们二者总是一起工作，必然导致VSync来临的时刻，这二者之间产生了CPU资源的抢占。因此，谷歌给这两个工作都加上一个小小的延迟，让这两个工作并不是同时被唤醒，这样大家就可以错开使用资源的高峰期，提高工作的效率。
这两个延迟，其实就分别对应上面代码中的vsyncSrc（绘制延迟）和sfVsyncSrc（合成延迟）。

了解了这些背景知识后，我们来继续看代码，DispSyncSource的初始化如此简单，这里不再详述（当然这里的变量mPrimaryDispSync的值来源让人困惑）。
在创建了两个DispSyncSource变量后，我们使用它们来初始化了两个EventThread。下面我们来详细看下EventThread的创建流程：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1.   EventThread::EventThread(const sp<VSyncSource>& src)  
  2.     : mVSyncSource(src),  
  3.       mUseSoftwareVSync(false),  
  4.       mVsyncEnabled(false),  
  5.       mDebugVsyncEnabled(false) {  
  6.   
  7.     for (int32_t i=0 ; i<DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES ; i++) {  
  8.         mVSyncEvent[i].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;  
  9.         mVSyncEvent[i].header.id = 0;  
  10.         mVSyncEvent[i].header.timestamp = 0;  
  11.         mVSyncEvent[i].vsync.count =  0;  
  12.     }  
  13. }  
  14.   
  15. void EventThread::onFirstRef() {  
  16.     run("EventThread", PRIORITY_URGENT_DISPLAY + PRIORITY_MORE_FAVORABLE);  
  17. }  

EventThread的构造函数很简单。重点是它的onFirstRef函数启动了一个EventThread线程，于是下面的代码才是重点：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. bool EventThread::threadLoop() {  
  2.     DisplayEventReceiver::Event event;  
  3.     Vector< sp<EventThread::Connection> > signalConnections;  
  4.     signalConnections = waitForEvent(&event);  
  5.   
  6.     // dispatch events to listeners...  
  7.     const size_t count = signalConnections.size();  
  8.     for (size_t i=0 ; i<count ; i++) {  
  9.         const sp<Connection>& conn(signalConnections[i]);  
  10.         // now see if we still need to report this event  
  11.         status_t err = conn->postEvent(event);  
  12.         if (err == -EAGAIN || err == -EWOULDBLOCK) {  
  13.             // The destination doesn't accept events anymore, it's probably  
  14.             // full. For now, we just drop the events on the floor.  
  15.             // FIXME: Note that some events cannot be dropped and would have  
  16.             // to be re-sent later.  
  17.             // Right-now we don't have the ability to do this.  
  18.             ALOGW("EventThread: dropping event (%08x) for connection %p",  
  19.                     event.header.type, conn.get());  
  20.         } else if (err < 0) {  
  21.             // handle any other error on the pipe as fatal. the only  
  22.             // reasonable thing to do is to clean-up this connection.  
  23.             // The most common error we'll get here is -EPIPE.  
  24.             removeDisplayEventConnection(signalConnections[i]);  
  25.         }  
  26.     }  
  27.     return true;  
  28. }  

上面的函数本身并不复杂，其中调用了一个waitForEvent的函数。这个函数相当之长，为了防止代码展开太多，我们这里暂时不再详细分析这个函数。我们目前只需要知道这个函数的最重要的作用是等待Event的到来，并且查找对event感兴趣的监听者，而在没有event到来时，线程处于休眠状态，等待event的唤醒（我们将在下一篇文章VSYNC的接收和处理中展开分析这个函数）。

这样，EventThread线程就运行起来，处在等待被event唤醒的状态下。

MessageQueue和EventThread建立连接

简单说明完EventThread之后，我们再次回到SurfaceFlinger的init过程中来。回到刚才我们本小节开始我们分析的代码中来：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. {  
  2. ...  
  3.     // start the EventThread  
  4.     sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync,  
  5.             vsyncPhaseOffsetNs, true);  
  6.     mEventThread = new EventThread(vsyncSrc);  
  7.     sp<VSyncSource> sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync,  
  8.             sfVsyncPhaseOffsetNs, true);  
  9.     mSFEventThread = new EventThread(sfVsyncSrc);  
  10.     mEventQueue.setEventThread(mSFEventThread);  
  11. ...  
  12. }  

下面这句 mEventQueue.setEventThread(mSFEventThread);其实很重要，这个函数将SurfaceFlinger的MessageQueue真正和我们刚才创建的EventThread建立起了连接，这样SurfaceFlinger才能真正接收到来自HWC的VSYNC信号。
我们来看下这段代码：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. void MessageQueue::setEventThread(const sp<EventThread>& eventThread)  
  2. {  
  3.     mEventThread = eventThread;  
  4.     mEvents = eventThread->createEventConnection();  
  5.     mEventTube = mEvents->getDataChannel();  
  6.     mLooper->addFd(mEventTube->getFd(), 0, ALOOPER_EVENT_INPUT,  
  7.             MessageQueue::cb_eventReceiver, this);  
  8. }  

这里代码逻辑其实很简单，就是创建了一个到EventThread的连接，得到了发送VSYNC事件通知的BitTube，然后监控这个BitTube中的套接字，并且指定了收到通知后的回调函数，MessageQueue::cb_eventReceiver。这样一旦VSync信号传来，函数cb_eventReceiver将被调用。

上面这个过程的原理，应该是使用了linux中的socket通信原理，因为和本文主题关系不大，不再展开。而MessageQueue在收到VSync消息后做了什么，我们将在下一篇文章VSync的接收和处理中详细说明。

EventControlThread

回到SurfaceFlinger的init过程中来，在EventThread创建好，MessageQueue和EventThread建立连接之后，SurfaceFlinger又创建了一个EventControlThread。

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. {  
  2. ...  
  3.     mEventQueue.setEventThread(mSFEventThread);  
  4.   
  5.     mEventControlThread = new EventControlThread(this);  
  6.     mEventControlThread->run("EventControl", PRIORITY_URGENT_DISPLAY);  
  7.   
  8.     // set a fake vsync period if there is no HWComposer  
  9.     if (mHwc->initCheck() != NO_ERROR) {  
  10.         mPrimaryDispSync.setPeriod(16666667);  
  11.     }  
  12. ...  
  13. }  

我们来看下这个EventControlThread是做什么的：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. EventControlThread::EventControlThread(const sp<SurfaceFlinger>& flinger):  
  2.         mFlinger(flinger),  
  3.         mVsyncEnabled(false) {  
  4. }  
  5.   
  6. bool EventControlThread::threadLoop() {  
  7.     Mutex::Autolock lock(mMutex);  
  8.     bool vsyncEnabled = mVsyncEnabled;  
  9.     mFlinger->eventControl(HWC_DISPLAY_PRIMARY, SurfaceFlinger::EVENT_VSYNC,  
  10.             mVsyncEnabled);  
  11.     while (true) {  
  12.         status_t err = mCond.wait(mMutex);  
  13.         if (err != NO_ERROR) {  
  14.             ALOGE("error waiting for new events: %s (%d)",  
  15.                 strerror(-err), err);  
  16.             return false;  
  17.         }  
  18.         if (vsyncEnabled != mVsyncEnabled) {  
  19.             mFlinger->eventControl(HWC_DISPLAY_PRIMARY,  
  20.                     SurfaceFlinger::EVENT_VSYNC, mVsyncEnabled);  
  21.             vsyncEnabled = mVsyncEnabled;  
  22.         }  
  23.     }  
  24.     return false;  
  25. }  
  26. void SurfaceFlinger::eventControl(int disp, int event, int enabled) {  
  27.     getHwComposer().eventControl(disp, event, enabled);  
  28. }  

其实EventControlThread的功能很简单，从名字里面我们就可以看出来，这个线程最重要的作用就是给HWC硬件发送消息，来通知开启或者关闭VSync消息的。
从代码来看，线程开始时，根据当前状态来通知硬件是否要发送VSync信号（刚开始时应该是关闭的）。然后进入等待：mCond.wait(mMutex)，等待的信号来源也很简单：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. void EventControlThread::setVsyncEnabled(bool enabled) {  
  2.     Mutex::Autolock lock(mMutex);  
  3.     mVsyncEnabled = enabled;  
  4.     mCond.signal();  
  5. }  

也就是说，一旦有人调用了EventControlThread的setVsyncEnabled函数时，将发送通知，然后条件被触发，EventControlThread根据当前最新的状态来重新给硬件发送命令，来告知硬件是否要开启VSync信号。那么是谁在什么时候调用了setVsyncEnabled函数呢？我们这里先不跟进，等到下一小节我们讲完屏幕的点亮和熄灭后大家就会明白这一段。

onScreenAcquired

Surfaceflinger的init函数中，除了和EventThread相关的代码外，还有一段显示设备的初始化：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. {  
  2. ...  
  3.     // set initial conditions (e.g. unblank default device)  
  4.     initializeDisplays();  
  5. ...  
  6. }  

我们在上一篇文档SF的创建过程中已经讲解过，其中initializeDisplays函数调用了一个重要的函数onScreenAcquired，前面文档中我们也说过，这个函数不仅在这里会被调用，同样会在屏幕点亮时被调用。

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. void SurfaceFlinger::onScreenAcquired(const sp<const DisplayDevice>& hw) {  
  2.     ...  
  3.     if (type < DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES) {  
  4.         // built-in display, tell the HWC  
  5.         getHwComposer().acquire(type);  
  6.         if (type == DisplayDevice::DISPLAY_PRIMARY) {  
  7.             // FIXME: eventthread only knows about the main display right now  
  8.             mEventThread->onScreenAcquired();  
  9.             resyncToHardwareVsync(true);  
  10.         }  
  11.     }  
  12.     ...  
  13. }  

首先我们来看下EventThread类的onScreenAcquired函数：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. void EventThread::onScreenAcquired() {  
  2.     Mutex::Autolock _l(mLock);  
  3.     if (mUseSoftwareVSync) {  
  4.         // resume use of h/w vsync  
  5.         mUseSoftwareVSync = false;  
  6.         mCondition.broadcast();  
  7.     }  
  8. }  

记得我们前面在讲EventThread时提到的，EventThread开始threadLoop以后，会在waitForEvent中等待被通知，而这个被等待的通知。就是在这个onScreenAcquired函数中发出的通知，mCondition.broadcast()（当VSYNC信号到达时，也会发出这个通知）。

继续看下resyncToHardwareVsync函数：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. void SurfaceFlinger::resyncToHardwareVsync(bool makeAvailable) {  
  2.     if (makeAvailable) {  
  3.         mHWVsyncAvailable = true;  
  4.     } else if (!mHWVsyncAvailable) {  
  5.         ALOGE("resyncToHardwareVsync called when HW vsync unavailable");  
  6.         return;  
  7.     }  
  8.     const nsecs_t period =  
  9.             getHwComposer().getRefreshPeriod(HWC_DISPLAY_PRIMARY);  
  10.   
  11.     mPrimaryDispSync.reset();  
  12.     mPrimaryDispSync.setPeriod(period);  
  13.   
  14.     if (!mPrimaryHWVsyncEnabled) {  
  15.         mPrimaryDispSync.beginResync();  
  16.         mEventControlThread->setVsyncEnabled(true);  
  17.         mPrimaryHWVsyncEnabled = true;  
  18.     }  
  19. }  

这个函数是一个比较重要的函数。主要的功能就是打开HWC的VSync功能。
首先是获取HWC的信号发送间隔，设置给mPrimaryDispSync，然后重置mPrimaryDispSync。
如果之前没有使用HWC的VSYNC，那么还需要重新开始mPrimaryDispSync的计数，然后调用EventControlThread的setVsyncEnabled函数，我们前面已经讲过这个函数的作用——就是打开硬件的VSYNC功能—-我们前面提出了什么时候调用setVsyncEnabled函数疑问，现在这个疑问可以被回答了，这个函数是在屏幕点亮时被调用了。

init中VSync的简单小节

这样我们简单的学习完了init中和VSync有关的一些知识。其实主要的流程代码就是下面的一小段：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. {  
  2. ...  
  3.     // start the EventThread  
  4.     sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync,  
  5.             vsyncPhaseOffsetNs, true);  
  6.     mEventThread = new EventThread(vsyncSrc);  
  7.     sp<VSyncSource> sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync,  
  8.             sfVsyncPhaseOffsetNs, true);  
  9.     mSFEventThread = new EventThread(sfVsyncSrc);  
  10.     mEventQueue.setEventThread(mSFEventThread);  
  11.   
  12.     mEventControlThread = new EventControlThread(this);  
  13.     mEventControlThread->run("EventControl", PRIORITY_URGENT_DISPLAY);  
  14.   
  15.     // set a fake vsync period if there is no HWComposer  
  16.     if (mHwc->initCheck() != NO_ERROR) {  
  17.         mPrimaryDispSync.setPeriod(16666667);  
  18.     }  
  19. ...  
  20.     // initialize our drawing state  
  21.     mDrawingState = mCurrentState;  
  22.   
  23.     // set initial conditions (e.g. unblank default device)  
  24.     initializeDisplays();  
  25. ...  
  26. }  
  1. 首先就是创建了两个DispSyncSource和EventThread，这两组线程可以各自配置延迟，分别对应渲染和合成。这样渲染和合成就可以在收到真正的VSync信号之后错开执行。EventThread创建之后将会等待VSync信号的通知，一旦收到信号后将会分发给感兴趣的监听者。
  2. mEventQueue（MessageQueue）和EventThread建立连接，实际上就是注册成为了一个监听者。
  3. 创建了一个EventControlThread线程，用以和硬件HWC通信，控制HWC是否生成VSync信号。
  4. 最后mPrimaryDispSync.setPeriod(16666667)是指如果硬件不能生成VSync信号，那么软件将模拟生成，并且生成的周期设置为16.6ms左右。
    5.最后在调用initializeDisplays函数初始化显示的过程中，我们又调用了onScreenAcquired函数，这个函数主要是唤醒了EventThread的等待，重置了mPrimaryDispSync，并且设置mPrimaryHWVsyncEnabled为true，并且通知硬件打开VSYNC通知。

基本流程如下图所示：
此处输入图片的描述
其中红色部分我们会在下一章VSync的接收和处理中再次展开讲解。

onVSyncReceived函数

这样，经过漫长的讲解，我们又从VSync的角度重新分析了SurfaceFlinger的init函数中的一些细节，现在我们终于可以回到这一小节开始之前我们提出的那几个问题：

当Surfaceflinger的收到VSync消息时的onVSyncReceived函数：

 
 

  
  

   
   

    
    [cpp] 
    
    view plain
    
    copy
    
    在CODE上查看代码片
    
    派生到我的代码片
    
    

   
   

  
  

  
  
  1. void SurfaceFlinger::onVSyncReceived(int type, nsecs_t timestamp) {  
  2.     bool needsHwVsync = false;  
  3.     {  
  4.         if (type == 0 && mPrimaryHWVsyncEnabled) {  
  5.             needsHwVsync = mPrimaryDispSync.addResyncSample(timestamp);  
  6.         }  
  7.     }  
  8.     if (needsHwVsync) {  
  9.         enableHardwareVsync();  
  10.     } else {  
  11.         disableHardwareVsync(false);  
  12.     }  
  13. }  

这段代码很短，但是相当让人困惑，困惑至少有以下三点：

  1. mPrimaryHWVsyncEnabled是干嘛的，是被什么时候赋值的？
  2. enableHardwareVsync和disableHardwareVsync又起到了什么作用？
  3. mPrimaryDispSync是什么？addResyncSample有什么作用？

现在我们可以尝试来回答上面的这三个疑问了：

  1. mPrimaryHWVsyncEnabled是用来标识主屏幕对应的HWC的VSYNC功能有没有被开启。这个值在SurfaceFlinger创建时被赋值为false，在onScreenAcquired屏幕被点亮时，被设置为true。
  2. enableHardwareVsync所起的作用其实跟我们前面提到的resyncToHardwareVsync函数作用基本一样，也是打开硬件的VSync功能。而disableHardwareVsync自然就是关闭硬件的VSync功能。 
       
   
    
    
    
    
     
     
    
      
      [cpp] 
      
      view plain
      
      copy
      
      在CODE上查看代码片
      
      派生到我的代码片
      
      
    
     
     
    
    
    
    
    
    
    1. void SurfaceFlinger::enableHardwareVsync() {  
    2.  if (!mPrimaryHWVsyncEnabled && mHWVsyncAvailable) {  
    3.      mPrimaryDispSync.beginResync();  
    4.      mEventControlThread->setVsyncEnabled(true);  
    5.      mPrimaryHWVsyncEnabled = true;  
    6.  }  
    7. }  
  3. mPrimaryDispSync的类型是DispSync（当然这个变量的创建时刻依然有待确认），表示了一个基于硬件VSync信号的同步模型，它会根据从HWComposer来的硬件VSync信号的采样来进行同步。
    了解了上面三个问题之后，我们终于可以来看下这段代码中最重要的一个函数调用—-addResyncSample。
    我们将在下一章的VSync消息的处理一章中详细分析这个函数以及后续消息的处理流程。
fu_shuwu
关注
专栏目录
android vsync,Vsync同步机制 一
weixin_28977143的博客
05-28 1362
什么是Vsync同步机制？Vsync(垂直同步信号量)，用来同步渲染，让AppUI和SurfaceFlinger可以按硬件产生的VSync节奏进行工作。Vsync要解决的问题：Vsync要解决的问题为什么会产生这样的问题？CPU负责对UI进行更新，GPU负责对UI进行渲染，两者的频率不一致，会导致CPU还未更新完成，就被GPU渲染到了屏幕上。所以会出现图片上的问题。如何解决这个问题？解决这个问题的...
【Graphic】Android5.0 Graphic(1) VSync与Project Butter
mandagod的博客
09-22 1056
VSync的概念   典型的现实系统中，Frame Buffer代表了显示一帧画面的缓冲数据。GPU/CPU绘图过程与屏幕刷新使用的是同一块缓冲，它们的速度不同的时候，就会出现画面“割裂”的显示。假如屏幕的刷新率为66HZ，而CPU/GPU的绘图能力有100HZ，它们分别处理完成一帧数据需要0.015秒和0.01秒。 From：https://en.wikip
最容易被忽略的重要知识点！Android屏幕刷新机制—VSync、Choreographer-全面理解！
最新发布
2401_85729264的博客
06-23 589
小编这些年深知大多数初中级Android工程师，想要提升自己，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！资料⬅专栏获取屏障消息和普通消息的区别在于。
Android Vsync 原理浅析
weixin_30832143的博客
07-30 235
Preface Android中，Client测量和计算布局，SurfaceFlienger（server）用来渲染绘制界面，client和server的是通过匿名共享内存（SharedClient）通信。 每个应用和SurfaceFlienger之间都会创建一个SharedClient，一个SharedClient最多可以创建31个SharedBufferStack，每个surface对应一个S...
android vsync
02-23 842
http://blog.csdn.net/wanna_ku/article/details/7819742 http://www.uml.org.cn/mobiledev/201301081.asp
Android VSYNC
rd_w_csdn的博客
01-20 473
本文讲述了 刷新率和帧频，图像撕裂现象产生的原因，垂直同步如何规避，
Android的Graphic系统分析之skia.doc
07-13
在Android系统中，Skia主要负责图形的绘制，生成的库文件为libskia.so，处理包括点、线、矩形、多边形等各种几何形状的绘制。 SkCanvas是Skia库中的核心类，它提供了图形绘制的基本接口，允许开发者将各种形状和...
image-process.rar_android_android graphic_android image_android
09-24
`android_graphic`和`android_image`涉及的是Android图形库和图像处理技术。在这个`image-process.rar`压缩包中，我们很可能会找到关于如何在Android应用中操作和处理图像的详细资料。下面将深入探讨Android图形系统...
Android屏幕刷新机制—VSync、Choreographer-全面理解！
2401_84132298的博客
04-23 854
上面讲到，Google在Android 4.1系统中对Android Display系统进行了优化：在收到VSync pulse后，将马上开始下一帧的渲染。即一旦收到VSync通知，CPU和GPU就立刻开始计算然后把数据写入buffer。本节就来讲 “drawing with VSync” 的实现——。Choreographer，意为 舞蹈编导、编舞者。在这里就是指 对CPU/GPU绘制的指导—— 收到VSync信号 才开始绘制，保证绘制拥有完整的16.6ms，避免绘制的随机性。
Android Vsync原理简析，移动客户端开发面经
m0_64382868的博客
12-04 467
这就跟我们抄作文一样，们从上到下，从左到右，一行一行的"挪移"到另一张纸上，当我们抄完一页，就翻到下一页继续抄，聪明的人抄的时候会看看，不会抄名字、性别、父母信息啥的，但是屏幕很傻，给什么抄什么，往死里抄，不带思考的那种，甚至在抄第一页的过程中，你给他偷偷翻个页，他还接着往下抄，造成不连贯的后果，屏幕不管这个，都说了各司其职，它的"职"就是抄，至于抄的不对，就是因为你翻页了，在计算机体系中，能翻页的，就是cpu，那最终就会怪罪于cpu"控制不力"，所以屏幕和cpu的协调沟通就极其重要。 我们来看两个概念:
android vsync,Android 显示系统：Vsync机制
weixin_39565910的博客
05-28 486
一、Vsync简介：屏幕的刷新过程是每一行从左到右(行刷新，水平刷新，Horizontal Scanning)，从上到下(屏幕刷新，垂直刷新，Vertical Scanning)。当整个屏幕刷新完毕，即一个垂直刷新周期完成，会有短暂的空白期，此时发出 VSync 信号。所以，VSync 中的 V 指的是垂直刷新中的垂直-Vertical。Android系统每隔16ms发出VSYNC信号，触发对UI...
Android VSync详解
小匠码农
04-28 1584
Android VSync
Android 显示 一、 Vsync
04-17 1287
Android 显示系统：Vsync机制 典型的显示系统中，一般包括CPU、GPU、Display三个部分， CPU负责计算帧数据， GPU对计算好的图形数据进行渲染，渲染好后放在buffer（图像缓冲区）里， Display负责把buffer里的数据呈现到屏幕上 一、Vsync简介： 　　屏幕的刷新过程是每一行从左到右（行刷新，水平刷新，Horizontal Scanning），从上到下（屏幕刷新，垂直刷新，Vertical Scanning）。当整个屏幕刷新完毕，即一个垂直刷新周期完成，会有短.
Android Vsync详解
王学明
03-21 6917
简介 Android4.1(Jelly Bean)引入了Vsync(垂直同步信号量)，用来同步渲染，让AppUI和SurfaceFlinger可以按硬件产生的VSync节奏进行工作。 切入正题 他们怎么做到的 那么，你如何使一个8个月的Galaxy Nexus运行像一个Galaxy S III？这要大量的艰苦工作。这个艰苦工作的详细由两个我最喜欢的I / O主持人Chet Haase...
Android图形-Vsync机制
haigand的专栏
08-11 429
当Vsync信号来的时候，就会唤醒EventThread线程，执行所有注册到EventThread的connection的分发出去，就是通过BitTube的mSendFd分发出去，分发出去后mReceivedFd就能接收到数据。那么如果刷新率>帧率，那么就是说，出图的速度低于屏幕刷新的速度，这是就会造成刷新的时候经常出现读取到的图像数据是同一幅图像的数据，但刷新率
Android VSYNC与图形系统中的撕裂、双缓冲、三缓冲浅析
工宗浩生财指南针
06-20 916
同步是防止画面撕裂的关键，VSYNC同步能防止画面撕裂VSYNC+双缓冲在Android中能有序规划渲染流程，降低延时Android已经采用了双缓冲，双缓冲不仅仅是两份存储，它是一个概念，双缓冲是一条链路，不是某一个环节，是整个系统采用的一个机制，需要各个环节的支持，从APP到SurfaceFlinger、到图像显示都要参与协作三缓冲在UI复杂情况下能保证画面的连续性，提高柔韧性。
【Android】Android SurfaceFlinger之VSync
Making Life Better. Making Others Better.
03-17 2629
1、VSync简介在Android GUI系统的多缓冲机制中，一个关键性的角色是VSync，充分利用了CPU/GPU与Display的交互机制，让UI表现更流畅。VSync即Vertical Sync，因为Display是逐行扫描的，从上到下，当扫描到最后一行时便返回第一行进行下一轮扫描，从最后一行返回到第一行有一段时间间隔，此时发出一个VSync信号，通知系统进行swap buffer（认为这个时
Android 屏幕刷新机制 VSync+Choreographer
zenmela2011的专栏
02-02 1714
1.显示系统基础知识 一个典型的显示系统一般包括CPU、GPU、Display三部分，其中CPU负责计算帧数据，并把计算好的数据交给GPU，GPU会对图形数据进行渲染，渲染好后放到图像缓冲区buffet里存起来，然后Display（屏幕或显示器）负责把buffer里的数据呈现到屏幕上。如下图： 这里涉及几个基础概念： ①屏幕刷新频率 指一秒内屏幕刷新的次数，即一秒内显示了多少帧图像，单位是赫兹Hz。常见的屏幕刷新频率是60Hz。 注：刷新频率取决于硬件的固定参数，不会变的。 ②逐行扫描 显
Android 4.4 Graphic架构详解：底层数据流与视图工作原理
本文档深入探讨了Android 4.4版本的图形架构，重点针对系统级别的图形处理机制，以及它在应用框架（Application Framework）和多媒体系统中的运用。理解这个架构对于开发者来说至关重要，特别是对于那些想要设计高效...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值