Android Vsync 原理

我们知道Android是用Vsync来驱动系统的画面更新包括APPview draw ,surfaceflinger 画面的合成,display把surfaceflinger合成的画面呈现在LCD上.我们将在本文探讨Android的Vsync的实现.

Vsync的构成

在systrace中,我们经常可以看到如上图的信息.

• 红色框1是与Vsync相关event信息.这些Vsync event构成了android系统画面更新基础.
• 红色框2和红色框3是Vsync-app的信息.我们可以看到红色框2比红色框3稀疏.我们将会在本文说明其原因.
• 红色框4和红色框5是Vsync-sf的信息.我们可以看到红色框4比红色框5稀疏.我们将会在本文说明其原因.

Vsync 信号

Vsync信号由HW_VSYNC_ON_0,HW_VSYNC_0, Vsync-app和Vsync-sf四部分构成.

• HW_VSYNC_ON_0 代表PrimaryDisplay的VSync被enable或disable.0这个数字代表的是display的编号, 0是PrimaryDisplay,如果是Externalmonitor,就会是HW_VSYNC_ON_1.当SF要求HWComposer将Display的VSync打开或关掉时,这个event就会记录下来.
• HW_VSYNC_0 代表PrimaryDisplay的VSync发生时间点, 0同样代表display编号.其用来调节Vsync-app和Vsync-sfevent的输出.
• Vsync-app App,SystemUI和systemserver 等viewdraw的触发器.
• Vsync-sf Surfaceflinger合成画面的触发器.

通常为了避免Tearing的现象, 画面更新(Flip)的动作通常会在VSync开始的时候才做, 因为在VSync开始到它结束前, Display不会把framebuffer资料显示在display上, 所以在这段时间做Flip可以避免使用者同时看到前后两个部份画面的现象.目前user看到画面呈现的过程是这样的,app更新它的画面后,它需要透过BufferQueue通知SF, SF再将更新过的app画面与其它的App或SystemUI组合后, 再显示在User面前. 在这个过程里, 有3个component牵涉进来, 分别是App,SF, 与Display.以目前AndroidM的设计,这三个Component都是在VSync发生的时候才开始做事.我们将它们想成一个有3个stage的pipeline,这个pipeline的clock就LCD的TE 信号(60HZ)也即HW_VSYNC_0.

我们来看看android draw的pipeline.如下,

1. T = 0时, App正在画N, SF与Display都没内容可用

2. T = 1时, App正在画N+1, SF组合N, Display没Buffer可显示

3. T = 2时, App正在画N+2, SF组合N+1, Display显示N

4. T = 3时, App正在画N, SF组合N+2, Display显示N+1

5. ...

如果按照这个步骤, 当user改变一个画面时, 要等到2个VSync后, 画面才会显示在user面前, latency大概是33ms (2个frame的时间). 但是对大部份的操作来讲, 可能app加SF画的时间一个frame(16.6ms)就可以完成. 因此, Android就从HW_VSYNC_0中产生出两个VSync 信号,VSYNC-app是给App用的, VSYNC-sf是给SF用的, Display则是使用HW_VSYNC_0.VSYNC-app与VSYNC-sf可以分别给定一个phase, 简单的说

VSYNC-app = HW_VSYNC_0 + phase_app

VSYNC-sf =HW_VSYNC_0 + phase_sf

从而使App draw 和surfaceflinger的合成,错开时间运行.这样就有可能整个系统draw的pipeline 更加有效率,从而提高用户体验.

也就是说, 如果phase_app与phase_sf设定的好的话, 可能大部份user使用的状况, App+SF可以在一个frame里完成, 然后在下一个HW_VSYNC_0来的时候, 显示在display上.

理论上透过VSYNC-sf与VSYNC-app的确是可以有机会在一个frame里把App+SF做完, 但是实际上不是一定可以在一个frame里完成. 因为有可能因为CPU调度,GPUperformance 不够, 以致App或SF没办法及时做完. 但是即便如此,把app,surfaceflinger和displayVsync 分开也比用一个Vsync 来trigger appdraw,surfaceflinger合成,display 在LCD 上draw的性能要好很多.(FPS 更高).

那么是否我们收到LCD的Vsyncevent 就会触发Vsync-app和Vsync-SF呢.如果是这样我们就不会看到本文开头的Vsync-app和Vsync-SF的节奏不一致的情况(红色框2比红色框3稀疏).事实上, 在大多数情况下,APP的画面并不需要一直更新.比如我们看一篇文章,大部份时间,画面是维持一样的,如果我们在每个LCD的VSYNC来的时候都触发SF或APP, 就会浪费时间和Power.可是在画面持续更新的情况下,我们又需要触发SF和App的Vsync event.例如玩game或播影片时.就是说我们需要根据是否有内容的更新来选择Vsyncevent出现的机制.Vsync event 的触发需要按需出现. 所以在Android里, HW_VSYNC_0,Vsync-sf和Vsync-app都会按需出现. HW_VSYNC_0是根据是否需要调节sf和app的Vsyncevent而出现,而SF和App则会call requestNextVsync()来告诉系统我要在下一个VSYNC需要被trigger.也是虽然系统每秒有60个HW VSYNC,但不代表APP和SF在每个VSYNC都要更新画面. 因此, 在Android里,是根据SoftwareVSYNC(Vsync-sf,Vsync-app)来更新画面.Software VSYNC是根据HWVSYNC过去发生的时间,推测未来会发生的时间.因此,当APP或SF利用requestNextVsync时,Software VSYNC才会触发VSYNC-sf或VSYNC-app.

Vsync event的产生

下图是Vsyncevent 产生的示意图.

这里HW_VSYNC就是HW_VSYNC_0.

当SF从HWComposer收到VSYNC(HW_VSYNC_0)时, 它会利用DispSync::addResyncSample将新的VSYNC时间交给DispSync.addResyncSample决定是否还需要HW_VSYNC的输入, 如果不需要, 就会将HW_VSYNC关掉.

voidSurfaceFlinger::onVSyncReceived(int type, nsecs_t timestamp) {

bool needsHwVsync = false;

{ // Scope for the lock

Mutex::Autolock _l(mHWVsyncLock);

if (type == 0 &&mPrimaryHWVsyncEnabled) {

needsHwVsync =mPrimaryDispSync.addResyncSample(timestamp);

}

}

if (needsHwVsync) {

enableHardwareVsync();

} else {

disableHardwareVsync(false);

}

}

另一方面,在sufaceflinge合成图片后也会check是否需要开启HW_VSYNC来调整SW_VSYNC.

在SurfaceFlinger::postComposition()里, 会将PresentFence的时间通过addPresentFence交给DispSync,来检查SW_VSYNC是否需要校正, 如果需要, 就会将HW_VSYNC打开.

voidSurfaceFlinger::postComposition()

{

const LayerVector&layers(mDrawingState.layersSortedByZ);

const size_t count = layers.size();

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

layers[i]->onPostComposition();

}

const HWComposer& hwc =getHwComposer();

sp<Fence> presentFence =hwc.getDisplayFence(HWC_DISPLAY_PRIMARY);

if (presentFence->isValid()) {

if(mPrimaryDispSync.addPresentFence(presentFence)) {

enableHardwareVsync();

} else {

disableHardwareVsync(false);

}

}

const sp<const DisplayDevice>hw(getDefaultDisplayDevice());

if (kIgnorePresentFences) {

if (hw->isDisplayOn()) {

enableHardwareVsync();

}

}

…..

}

DispSync是利用HW_VSYNC和PresentFence来判断是否需要开启HW_VSYNC.HW_VSYNC 最少要3个, 最多是32个, 实际上要用几个则不一定,DispSync拿到3个HW_VSYNC后就会计算出SW_VSYNC,只要收到的PresentFence没有超过误差,则HW_VSYNC就会关掉,以便节省功耗. 不然会继续开启HW_VSYNC计算SW_VSYNC的值, 直到误差小于threshold.其计算的方法是DispSync::updateModelLocked().

基本思想如下,

• 计算目前收到HW_VSYNC间隔, 取平均值(AvgPeriod) HW_VSYNC
• 将每个收到的VSYNC时间与AvgPeriod算出误差. (Delta = Time %AvgPeriod)
• 将Delta转换成角度(DeltaPhase), 如果AvgPeriod是360度,DeltaPhase = 2*PI*Delta/AvgPeriod.
• 从DeltaPhase可以得到DeltaX与DeltaY (DeltaX =cos(DeltaPhase), DeltaY = sin(DeltaPhase))
• 将每个收到的VSYNC的DeltaX与DeltaY取平均, 可以得到AvgX与AvgY
• 利用atan与AvgX, AvgY可以得到平圴的phase (AvgPhase)
• AvgPeriod + AvgPhase就是SW_VSYNC.

• 当DispSync收到addPresentFence时(最多记录8个sample),每一个fence的时间算出(Time% AvgPeriod)的平方当作误差,将所有的Fence误差加总起来如果大于某个Threshold,就表示需要校正(DispSync::updateErrorLocked). 校正的方法是呼叫DispSync::beginResync()将所有的HW_VSYNC清掉, 开启HW_VSYNC.等至少3个HW_VSYNC再重新计算.