[关闭]
@ltlovezh 2019-12-14T01:38:47.000000Z 字数 16338 阅读 383

Android图形系统之VSync

图形系统 VSync


从Android4.1开始,Google引入了Project Butter,即“黄油计划”。目的是改善用户抱怨最多的系统缺陷:UI响应速度,Google希望这一新计划可以让Android系统摆脱UI交互上给人带来的滞后感,而能像黄油一样顺滑。
Project Butter对Android Display系统进行了重构,引入了三个核心元素:VSync、Triple Buffer和Choreographer。今天我们主要看下VSync信号的来龙去脉。

VSync信号的产生

VSync信号是由HWC硬件模块根据屏幕刷新率产生。DispSync是VSync事件核心类,根据HWC产生的硬件VSync信号,训练了一个模拟的VSync事件源,并且通过内部的DispSyncThread线程向外分发DispSync::Callback回调,DispSyncSource就是实现了该回调接口。
为了处理VSync信号,SurfaceFlinger启动了两个EventThread线程:

  1. mEventThread:服务于客户端APP UI渲染。
  2. mSFEventThread:服务于SurfaceFlinger合成和上屏。

两个VSync线程在SurfaceFlinger::init中完成初始化,如下所示:

  1. // start the EventThread vsyncSrc 表示渲染用的Vsync
  2. sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync, vsyncPhaseOffsetNs, true, "app");
  3. // 客户端UI渲染使用的VSync线程
  4. mEventThread = new EventThread(vsyncSrc, *this);
  5. // sfVsyncSrc表示SF合成用的VSync
  6. sp<VSyncSource> sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync, sfVsyncPhaseOffsetNs, true, "sf");
  7. // SF使用的VSync线程
  8. mSFEventThread = new EventThread(sfVsyncSrc, *this);
  9. //MessageQueue向SF的EventThread注册监听器
  10. mEventQueue.setEventThread(mSFEventThread);

DispSyncSource实现了DispSync::Callback回调接口,可以从DispSync接收VSync事件。上述代码创建了两个DispSyncSource对象,vsyncSrc是给CPU服务,驱动客户端APP UI线程渲染;sfVsyncSrc是给GPU服务,驱动SF主线程合成上屏。两个DispSyncSource分别指定了不同的时间戳偏移量(相对于标准的VSync时间戳),可以精细控制VSync的回调时机,通过adb shell dumpsys SurfaceFlinger可以查看这两个偏移量(后面详细介绍):

  1. // app phase就是vsyncSrc偏移量,sf phase是sfVsyncSrc偏移量,refresh是主屏的刷新周期
  2. DispSync configuration: app phase 1000000 ns, sf phase 1000000 ns, early sf phase 1000000 ns, present offset 0 ns (refresh 16666666 ns)

每个DispSyncSource对象与一个EventThread相关联,DispSync的VSync事件会通过DispSyncSource传递到EventThread::onVSyncEvent,再通过EventThread::Connection向外分发。

基于DispSync的VSync架构如下所示:
DispSync

  1. DispSync借助硬件VSync(HW_VSYNC)训练了一个模拟的VSync模型(SW-VSYNC)。
  2. 模拟的VSync模型为驱动APP绘制的VSync信号添加了时间戳偏移(phase-app),生成了Vsync-app事件。
  3. 模拟的VSync模型为驱动SF合成的VSync信号添加了时间戳偏移(phase-sf),生成了Vsync-sf事件。
  4. Vsync-appVsync-sf是外界真正接触到的VSync事件。
  5. addPresentFence用来检查模拟的VSync模型与硬件VSync之间是否超过了一定误差,若是,则需要重启硬件Vsync,训练新的VSync模型。

下面详细看下DispSync是如何训练出模拟的VSync事件?在Android图形系统系统篇之HWC一文中,我们提到HWC2::Device构造函数会通过Device::registerCallbacks向显示设备注册三个Display回调:热插拔,刷新和VSync信号,这里的显示设备就是hwc2_device_t。所以,VSync信号的起源是hwc2_device_t,然后经过一系列回调到达SurfaceFlinger.onVSyncReceived方法。onVSyncReceived通过addResyncSample方法把硬件VSync时间戳交给DispSync,训练一个模拟的VSync事件模型。addResyncSample主要逻辑:

  1. 几个关键变量:mReferenceTime记录第一个硬件VSync时间戳;mResyncSamples存储所有硬件Vsync时间戳(数组长度为NUM_PRESENT_SAMPLES,目前为32);mNumResyncSamples表示参与计算的时间戳个数。在时间戳个数达到MIN_RESYNC_SAMPLES_FOR_UPDATE(常量,目前为6)时,会触发真正的模型计算updateModelLocked
  2. 计算过程:首先,计算出相邻时间戳时间差的均值(排除了最大和最小值),作为模拟的Vsync的时间周期mPeriod(这个值理论上等于16.66666...ms);然后根据每个硬件时间戳相比于mPeriod的偏差,计算出平均偏差mPhase,范围是(-mPeriod/2 , mPeriod/2];最后把mPeriodmPhasemReferenceTime设置给DispSyncThread线程。
  3. DispSyncThread线程根据上面计算出的mPeriodmPhasemReferenceTime以及每个DispSync::Callback要求的Phase,定时回调每个Callback,其中Callback的时间戳参数,不是系统时间,而是基于第一个硬件Vsync时间戳mReferenceTime计算出来的。
  4. 如果训练的模拟VSync时间戳与硬件VSync时间戳在一定的误差范围内,则addResyncSample返回false,表示模拟的硬件VSync模型已经OK,不再需要硬件VSync时间戳了,否则返回true,表示需要更多的硬件VSync时间戳来训练模型
  5. 如果DispSync检测到硬件VSync与模拟的VSync模型之间存在较大误差,则会重新训练新的VSync模型。

核心代码如下所示:

  1. // 收到HWComposer的Vsync信号
  2. void SurfaceFlinger::onVSyncReceived(int32_t type, nsecs_t timestamp) {
  3. bool needsHwVsync = false;
  4. { // Scope for the lock
  5. Mutex::Autolock _l(mHWVsyncLock);
  6. // type为0,表示主显示屏
  7. if (type == 0 && mPrimaryHWVsyncEnabled) {
  8. // 训练模型,返回false,则表示模型训练成功
  9. needsHwVsync = mPrimaryDispSync.addResyncSample(timestamp);
  10. }
  11. }
  12. if (needsHwVsync) {
  13. enableHardwareVsync();
  14. } else { // 关闭硬件VSync
  15. disableHardwareVsync(false);
  16. }
  17. }
  18. // DispSyncThread线程注册的监听器
  19. struct EventListener {
  20. const char* mName;
  21. nsecs_t mPhase; // 时间戳偏移量
  22. nsecs_t mLastEventTime; // 上次VSync事件的时间戳
  23. sp<DispSync::Callback> mCallback; // 对应的回调,即DispSyncSource
  24. };

为了控制硬件VSync的打开与关闭,专门提供了一个线程EventControlThread,当内部的mVsyncEnabled状态改变时,会调用到下面的SurfaceFlinger::setVsyncEnabled方法:

  1. void SurfaceFlinger::setVsyncEnabled(int disp, int enabled) {
  2. // 打开 or 关闭HWC VSync,最终调用到下面的 Display::setVsyncEnabled
  3. getHwComposer().setVsyncEnabled(disp,
  4. enabled ? HWC2::Vsync::Enable : HWC2::Vsync::Disable);
  5. }
  6. // 硬件模块
  7. Error Display::setVsyncEnabled(Vsync enabled)
  8. {
  9. auto intEnabled = static_cast<int32_t>(enabled);
  10. // 打开 or 关闭HWC VSync
  11. int32_t intError = mDevice.mSetVsyncEnabled(mDevice.mHwcDevice, mId, intEnabled);
  12. return static_cast<Error>(intError);
  13. }

此外,必须在屏幕亮着时,硬件VSync才能工作,否则只能依赖训练好的模拟硬件VSync,甚至需要在EventThread中通过软件方式进行VSync兜底(后面会介绍),下面是屏幕打开和关闭的逻辑:

  1. void SurfaceFlinger::setPowerModeInternal(const sp<DisplayDevice>& hw, int mode){
  2. int32_t type = hw->getDisplayType();
  3. // current hwc power mode
  4. int currentMode = hw->getPowerMode();
  5. if (mode == currentMode) {
  6. return;
  7. }
  8. if (currentMode == HWC_POWER_MODE_OFF) {
  9. getHwComposer().setPowerMode(type, mode);
  10. if (type == DisplayDevice::DISPLAY_PRIMARY) {
  11. // 通知为客户端服务的EventThread:显示器打开了
  12. mEventThread->onScreenAcquired();
  13. // 显示器打开后,需要重新基于硬件VSync信号,训练软件VSync
  14. resyncToHardwareVsync(true);
  15. }
  16. mHasPoweredOff = true;
  17. repaintEverything();
  18. } else if (mode == HWC_POWER_MODE_OFF) {
  19. if (type == DisplayDevice::DISPLAY_PRIMARY) {
  20. // 显示器关闭了,则关闭硬件VSync,停止软件VSync训练
  21. disableHardwareVsync(true); // also cancels any in-progress resync
  22. // 通知为客户端服务的EventThread:显示器关闭了
  23. mEventThread->onScreenReleased();
  24. }
  25. getHwComposer().setPowerMode(type, mode);
  26. // from this point on, SF will stop drawing on this display
  27. } else {
  28. getHwComposer().setPowerMode(type, mode);
  29. }
  30. }

为什么屏幕的打开与关闭只通知了mEventThread,而没通知mSFEventThread,因为前者是为客户端进程服务,即使主屏幕关闭了,客户端依然要依赖VSync事件做一些工作,所以在mEventThread中必须通过软件的方式为VSync事件兜底(就是等待模拟的硬件VSync 16ms,若超时了,就使用系统时间戳)。而后者是为SurfaceFlinger的合成上屏服务,当对应的屏幕关闭后,就不再需要上屏了,所以mSFEventThread就可以不工作了。

adb shell dumpsys SurfaceFlinger可以查看mEventThread的dump信息,如下所示:

  1. // 是否在使用VSync,可能是硬件VSync,也可能是EventThread的软件VSync
  2. VSYNC state: enabled
  3. // 当屏幕亮着的,就是disabled,如果关闭屏幕,这里为enabled
  4. soft-vsync: disabled
  5. // 表示感兴趣的Connection的个数
  6. numListeners=90,
  7. // 表示接收到的VSync的累加值(包括硬件VSync和EventThread的软件VSync)
  8. events-delivered: 181752
  9. // 下面是具体Connection的count,-1表示该Connection不会接收VSync信号,Connection->count的具体含义下面👇会详细介绍。
  10. 0x76fa631480: count=-1
  11. 0x76fa633d00: count=-1
  12. ......

如果模拟的硬件VSync事件(DispSyncThread产生)是正常的,那么EventThread::onVSyncEvent负责接收VSync事件,并更新vsync.count计数和header.timestamp时间戳。

  1. // 接收到DispSyncSource传过来的VSync信号
  2. void EventThread::onVSyncEvent(nsecs_t timestamp) {
  3. Mutex::Autolock _l(mLock);
  4. // 表示VSync事件,也可能是热插拔事件
  5. mVSyncEvent[0].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
  6. mVSyncEvent[0].header.id = 0;
  7. // 更新VSync时间戳
  8. mVSyncEvent[0].header.timestamp = timestamp;
  9. // VSync的累加计数,即dump信息中的events-delivered值
  10. mVSyncEvent[0].vsync.count++;
  11. mCondition.broadcast();
  12. }

如果屏幕关闭了,那么在EventThread::waitForEvent中通过Condition.waitRelative为VSync信号兜底,核心代码如下所示:

  1. // SurfaceFlinger通知屏幕关闭了,模拟的硬件VSync信号可能不准,需要使用软件模拟,即16ms
  2. void EventThread::onScreenReleased() {
  3. Mutex::Autolock _l(mLock);
  4. if (!mUseSoftwareVSync) {
  5. // disable reliance on h/w vsync
  6. mUseSoftwareVSync = true;
  7. mCondition.broadcast();
  8. }
  9. }
  10. // SurfaceFlinger通知屏幕打开了,不再需要使用软件模拟VSync
  11. void EventThread::onScreenAcquired() {
  12. Mutex::Autolock _l(mLock);
  13. if (mUseSoftwareVSync) {
  14. // resume use of h/w vsync
  15. mUseSoftwareVSync = false;
  16. mCondition.broadcast();
  17. }
  18. }
  19. // 下面是EventThread::waitForEvent中产生软件VSync的地方
  20. bool softwareSync = mUseSoftwareVSync;
  21. // 如果屏幕没关闭,那么继续等待模拟的硬件VSync信号(超时时间为1S),否则等待时间为16ms。在waitRelative期间,如果模拟的硬件VSync信号到了,那么就继续使用模拟的硬件VSync,否则就自己更新vsync.count和`header.timestamp`时间戳。
  22. nsecs_t timeout = softwareSync ? ms2ns(16) : ms2ns(1000);
  23. if (mCondition.waitRelative(mLock, timeout) == TIMED_OUT) {
  24. // 这里的代码块是处理等待超时的情况,即模拟的硬件VSync信号在16ms内没到达,就需要软件模拟了
  25. if (!softwareSync) {
  26. // 硬件Vsync失效了,下面是模拟的Vsync信号
  27. ALOGW("Timed out waiting for hw vsync; faking it");
  28. }
  29. mVSyncEvent[0].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
  30. mVSyncEvent[0].header.id = DisplayDevice::DISPLAY_PRIMARY;
  31. // 软件方式,更新为系统时间戳
  32. mVSyncEvent[0].header.timestamp = systemTime(SYSTEM_TIME_MONOTONIC);
  33. mVSyncEvent[0].vsync.count++;
  34. }

屏幕关闭后,DispSyncThread线程还在继续发送模拟的硬件VSync事件,所以正常情况下,还是通过EventThread::onVSyncEvent更新vsync.count计数和header.timestamp时间戳。只有在超过16ms,没有接收到模拟的硬件VSync时,系统才会主动更新vsync.count计数和header.timestamp时间戳。

针对服务于CPU的mEventThreadvsync.count计数和header.timestamp时间戳一般情况下都是通过EventThread::onVSyncEvent方法来更新,若屏幕关闭了,并且在16ms内EventThread::onVSyncEvent方法未更新VSync信息,那么就在EventThread::waitForEvent中主动更新VSync信息。
而针对服务于GPU的mSFEventThread,只会通过EventThread::onVSyncEvent方法更新vsync.count计数和header.timestamp时间戳。

总结下:不管是服务于CPU的mEventThread,还是服务于GPU的mSFEventThread,都是通过DispSyncSource接收模拟的硬件VSync事件。差异点在于,当有EventThread::Connection请求了VSync事件,但是此时又没有VSync时,waitRelative等待超时的时间是不同的:在屏幕亮着的情况是1000ms,而屏幕关闭后则是16ms。而SurfaceFlinger只会通知mEventThread屏幕的打开与关闭。所以mSFEventThread等待超时的时间只能是1000ms。

上文中有提到vsync.count计数和EventThread::Connection.count值,它们主要是控制通知EventThread::Connection的频率,当VSync信号到来时,vsync.count会不断累加,比较简单。而EventThread::Connection.count的取值主要分为三类:

  1. count >= 1 :当vsync.count % count为0时,通知对应的EventThread::Connection
  2. count == 0 :可以通知对应的EventThread::Connection,但是立即赋值为-1,表示下次不再继续通知
  3. count ==-1 : 不会通知对应的Connection

核心代码在waitForEvent中,如下所示:

  1. // 根据count决定对应的connection是否应该被通知,signalConnections是收集需要通知的connection列表。
  2. if (connection->count == 0) {
  3. // 此次通知,下次就不通知VSync事件了
  4. connection->count = -1;
  5. signalConnections.add(connection);
  6. added = true;
  7. } else if (connection->count == 1 || (vsyncCount % connection->count) == 0) {
  8. // continuous event, and time to report it 持续的VSync事件
  9. signalConnections.add(connection);
  10. added = true;
  11. }

EventThread::Connection提供了setVsyncRaterequestNextVsync方法修改这个count,最终会调用到EventThread对应的方法,如下所示:

  1. // 设置指定Connection接收VSync事件的固定频率
  2. void EventThread::setVsyncRate(uint32_t count, const sp<EventThread::Connection>& connection) {
  3. if (int32_t(count) >= 0) {
  4. Mutex::Autolock _l(mLock);
  5. const int32_t new_count = (count == 0) ? -1 : count;
  6. if (connection->count != new_count) {
  7. // 更新connection->count
  8. connection->count = new_count;
  9. mCondition.broadcast();
  10. }
  11. }
  12. }
  13. // 请求接收下一次的VSync事件,请求一次,接收下一次VSync
  14. void EventThread::requestNextVsync(
  15. const sp<EventThread::Connection>& connection) {
  16. Mutex::Autolock _l(mLock);
  17. mFlinger.resyncWithRateLimit();
  18. // 更新connection->count
  19. if (connection->count < 0) {
  20. connection->count = 0;
  21. mCondition.broadcast();
  22. }
  23. }
  • setVsyncRate只需要指定一次,后续根据vsync.count % connection->count == 0来接收VSync事件
  • requestNextVsync则是请求下一次VSync事件,请求一次,接收一次,View.invalidate和SF合成,都是使用这种方式。

上文有提到,当模拟的VSync模型与硬件VSync在一定误差内时,会关闭硬件VSync。那么随着时间推移,如果误差越来越大,如何调整模拟的硬件VSync模型那?
原来,SurfaceFlinger在处理Layer合成的最后一步(handleMessageRefresh -> postComposition)会通过addPresentFencePresent Fence交给DispSync, DispSync会检查Present Fence与模拟的VSync周期之间的误差,若误差偏大就会打开HWCVSync,重新走addResyncSample训练逻辑。核心代码如下所示:

  1. // handleMessageRefresh -> postComposition
  2. void SurfaceFlinger::postComposition(){
  3. const HWComposer& hwc = getHwComposer();
  4. sp presentFence = hwc.getDisplayFence(HWC_DISPLAY_PRIMARY);
  5. if (presentFence->isValid()) {
  6. if (mPrimaryDispSync.addPresentFence(presentFence)) {
  7. // 打开HWC VSync,重新训练DispSync的VSync模型
  8. enableHardwareVsync();
  9. } else {
  10. // 关闭HWC VSync
  11. disableHardwareVsync(false);
  12. }
  13. }
  14. }
  15. // 添加Present Fence,检查VSync模型误差
  16. bool DispSync::addPresentFence(const sp<Fence>& fence) {
  17. // 保存Present Fence,最大长度为NUM_PRESENT_SAMPLES,目前是8
  18. mPresentFences[mPresentSampleOffset] = fence;
  19. mPresentTimes[mPresentSampleOffset] = 0;
  20. mPresentSampleOffset = (mPresentSampleOffset + 1) % NUM_PRESENT_SAMPLES;
  21. mNumResyncSamplesSincePresent = 0;
  22. for (size_t i = 0; i < NUM_PRESENT_SAMPLES; i++) {
  23. const sp<Fence>& f(mPresentFences[i]);
  24. if (f != NULL) {
  25. nsecs_t t = f->getSignalTime();
  26. if (t < INT64_MAX) {
  27. mPresentFences[i].clear();
  28. // 记录Present Fence的时间戳
  29. mPresentTimes[i] = t + kPresentTimeOffset;
  30. }
  31. }
  32. }
  33. // 检查误差
  34. updateErrorLocked();
  35. // 若误差超过一定阈值,则返回true,表示需要重启硬件VSync
  36. return !mModelUpdated || mError > kErrorThreshold;
  37. }
  38. // 检查已经保存的Present Fence与现有VSync周期的均方误差
  39. void DispSync::updateErrorLocked() {
  40. // Need to compare present fences against the un-adjusted refresh period, since they might arrive between two events.
  41. nsecs_t period = mPeriod / (1 + mRefreshSkipCount);
  42. int numErrSamples = 0;
  43. nsecs_t sqErrSum = 0;
  44. for (size_t i = 0; i < NUM_PRESENT_SAMPLES; i++) {
  45. // mReferenceTime表示之前记录的第一个硬件VSync时间戳
  46. nsecs_t sample = mPresentTimes[i] - mReferenceTime;
  47. if (sample > mPhase) {
  48. // 相对于现有VSync周期的误差
  49. nsecs_t sampleErr = (sample - mPhase) % period;
  50. if (sampleErr > period / 2) {
  51. sampleErr -= period;
  52. }
  53. // 求取误差平方和
  54. sqErrSum += sampleErr * sampleErr;
  55. numErrSamples++;
  56. }
  57. }
  58. // 计算出均方误差
  59. if (numErrSamples > 0) {
  60. mError = sqErrSum / numErrSamples;
  61. } else {
  62. mError = 0;
  63. }
  64. }

DispSync收到addPresentFence添加的Present Fence时(目前最多8个),会计算出Present Fence与现有VSync周期的均方误差,若均方误差超过常量:kErrorThreshold = 160000000000,就会打开硬件VSync,重新训练DispSync模拟的硬件VSync模型。

最后,总结下VSync模型的运转流程:当HWC发出VSync信号时,SurfaceFlinger将会收到回调并且发送给DispSyncDispSync将会记录这些硬件VSync时间戳,当累计了足够的硬件VSync以后(目前是大于等于6个),就开始计算VSync周期和偏移:mPeriod和mPhase。DispSyncThread将会利用mPeriod和mPhase模拟硬件VSync,并且通知对VSync感兴趣的Listener,这些Listener包括SurfaceFlinger和客户端APP。这些Listener以Connection形式注册到EventThread。DispSyncThread与EventThread通过DispSyncSource作为中间人进行连接。EventThread收到模拟的硬件VSync后,将会通知所有感兴趣的Connection,然后SurfaceFlinger开始合成,APP开始渲染。当收到足够多的硬件VSync并且在误差允许范围内,将会通过EventControlThread关闭HWC的硬件VSync。
通过流程图表示如下:

OK,上述分析了VSync事件的起源和分发逻辑,下面我们详细看下VSync事件的两种使用场景:一个是驱动SurfaceFlinger合成上屏;一个是驱动客户端APP UI渲染。

驱动SurfaceFlinger合成上屏

上文SurfaceFlinger::init代码中完成了MessageQueuemSFEventThread的绑定,即MessageQueuemSFEventThread注册了EventThread::Connection,并通过BitTube监听Connection写入的事件(通过EventThread::Connection::postEvent写事件到BitTube),例如:VSync和热插拔事件。核心代码如下所示:

  1. // 主线程`MessageQueue`绑定`mSFEventThread`,
  2. void MessageQueue::setEventThread(const sp<EventThread>& eventThread)
  3. {
  4. mEventThread = eventThread;
  5. // 创建EventThread::Connection
  6. mEvents = eventThread->createEventConnection();
  7. mEventTube = mEvents->getDataChannel();
  8. // 监听BitTube的方式(用Looper),一旦有数据到来则调用cb_eventReceiver(),this表示透传的参数
  9. mLooper->addFd(mEventTube->getFd(), 0, Looper::EVENT_INPUT,
  10. MessageQueue::cb_eventReceiver, this);
  11. }
  12. // 接收EventThread的VSync事件,分发到MessageQueue线程
  13. int MessageQueue::cb_eventReceiver(int fd, int events, void* data) {
  14. MessageQueue* queue = reinterpret_cast<MessageQueue *>(data);
  15. return queue->eventReceiver(fd, events);
  16. }
  17. // 创建的Connection在第一次被引用时,才会注册到EventThread
  18. void EventThread::Connection::onFirstRef() {
  19. // 当第一次引用Connection时,就会把它添加到所属EventThread维护的Connection队列
  20. mEventThread->registerDisplayEventConnection(this);
  21. }

OK,MessageQueuemSFEventThread注册EventThread::Connection后,就可以接收VSync事件了,那么SurfaceFlinger是一直接收VSync事件,还是按需请求的那?还记得上面介绍的connection->count吗?实际上是通过Connection::requestNextVsync按需请求的,这个“按需”就是指有Layer更新了。这里我们通过两个时序图详细看下:

驱动SurfaceFlinger合成上屏的VSync是什么时候请求的:
SurfaceFlinger请求VSync
SurfaceFlinger是怎么接收VSync信号的:
SurfaceFlinger接收VSync

  1. 当View.invalidate调用后,最终会触发ViewRootImplSurfaceFlingermEventThread请求接收下一次的VSync事件(后面详细介绍)。
  2. 客户端收到VSync事件后,最终通过performTraversals触发View体系的绘制。
  3. 这里以软件绘制为例,通过Surface拿到CanvasCanvas底层实际对应的是从SurfaceFlinger申请的GraphicBuffer。当Canavs绘制完成后,通过Surface.unlockCanvasAndPost触发GraphicBuffer的入队流程,即通过BufferQueueProducerGraphicBuffer入队到`BufferQueue。
  4. 入队后,通过BufferQueueCore中的mConsumerListener回调一步步通知到SurfaceFlinger
  5. SurfaceFlinger通过MessageQueuemSFEventThread请求下一次的VSync信号。
  6. Vsync到来后,通过MessageQueue分发到SurfaceFlinger主线程,并且最终通过handleMessageRefresh进行Layer的合成与上屏。

驱动客户端APP UI渲染

同样的,驱动客户端APP UI渲染的VSync逻辑,也可以分为客户端请求VSync信号和客户端接收VSync信号,一样可以通过两个时序图来看下:

客户端请求VSync:
客户端请求VSync
客户端接收VSync:
客户端接收VSync

客户端APP怎么请求VSync事件那?实际是View请求重绘时,通过ChoreographerSurfaceFlingermEventThread线程请求接收下一次的VSync事件。

  1. 当View.invalidate调用后,最终会触发ViewRootImplChoreographer注册一个TraversalRunnable
  2. Choreographer本地保存这个TraversalRunnable后,会通过DisplayEventReceiver.java调用到Native层,最终一步步调用到mEventThread线程,修改connection->count = 0(请求接收下一次VSync)。
  3. Vsync到来后,会从SurfaceFlinger进程一步步回调到客户端进程,最终触发ViewRootImpl之前注册TraversalRunnable,启动View树的渲染。

那么这里的EventThread::Connection是怎么注册到mEventThread线程的那?其实在创建DisplayEventReceiver就已经完成了注册,如下所示:

  1. // DisplayEventReceiver的构造函数
  2. DisplayEventReceiver::DisplayEventReceiver() {
  3. // 跨进程获取SurfaceFlinger句柄
  4. sp<ISurfaceComposer> sf(ComposerService::getComposerService());
  5. if (sf != NULL) {
  6. // 向SurfaceFlinger的mEventThread线程注册Connection
  7. mEventConnection = sf->createDisplayEventConnection();
  8. if (mEventConnection != NULL) {
  9. // 需要监听的句柄
  10. mDataChannel = mEventConnection->getDataChannel();
  11. }
  12. }
  13. }
  14. // 添加感兴趣的Connection到mEventThread线程,用于通知客户端APP VSync事件
  15. sp<IDisplayEventConnection> SurfaceFlinger::createDisplayEventConnection() {
  16. return mEventThread->createEventConnection();
  17. }

VSync偏移

在基于VSync的渲染模型中,涉及到三个组件:APP、SurfaceFlinger和Display,它们都是在VSync到来时开始工作。假如我们请求了View重绘,那么整个渲染流程如下所所示:
VSync偏移

  1. View.invalidate请求重绘,通过Choreographer请求接收下一个VSync信号。
  2. 第一个VSync信号到来时,View开始绘制,绘制完成后通过BufferQueue通知到SurfaceFlinger,SurfaceFlinger通过MessageQueue请求接收下一个VSync信号。
  3. 第二个VSync信号到来时,SurfaceFlinger开始合成Layer,并把结果交给HWC
  4. 第三个VSync信号到来时,Display开始展示合成好的图像数据。

同时需要注意到:屏幕开始显示帧N时,SurfaceFlinger开始为帧N+1合成Layer,客户端开始处理View渲染并生成帧N+2,即:从View绘制到显示在屏幕上,延迟至少为两帧,大概33ms。

但是对大部分场景来说,APP渲染+SurfaceFlinger合成可能在16ms内就可以完成。为了缩短帧延迟,可以在设备的BoardConfig.mk文件中为驱动APP渲染和SurfaceFlinger合成的VSync信号分别配置时间戳偏移:VSYNC_EVENT_PHASE_OFFSET_NSSF_VSYNC_EVENT_PHASE_OFFSET_NS(即SurfaceFlinger::init中创建DispSyncSource时传入的vsyncPhaseOffsetNs与sfVsyncPhaseOffsetNs偏移)。若不设置,则默认都是0,即相对于模拟的硬件VSync信号,都没有时间戳偏移。
disp_sync_phase

理想情况下,App可以在phase-sf - phase-app时间内完成绘制,SurfaceFlinger可以在VSync周期 - phase-sf时间内完成合成,那么在下一个VSync信号时就可以上屏,即帧延迟为16ms。
但是若APP绘制耗时超过了phase-sf - phase-app,那就只能等到下一个VSync-sf信号才能开始合成,即等待SurfaceFlinger开始合成的时间由VSync周期变成了VSync周期 + phase-sf - phase-app,若同时SurfaceFlinger的合成耗时超过了VSync周期 - phase-sf,那么就要再等下一个VSync才能上屏,整体延迟了3帧,即将近50ms。所以一般情况下,系统都会将phase-sf - phase-app设置为VSync周期。

总结

本文主要介绍了VSync信号的来龙去脉,以及驱动客户端APP渲染和SurfaceFlinger合成上屏的逻辑。

参考文章

  1. Implement-Vsync
  2. Systrace 基础知识 - Vsync 解读
添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注