Android Project Butter分析

随着时间的推移,Android OS系统一直在不断完善。但直到Android 4.0问世,有关UI显示不流畅的问题也一直未得到根本解决。在整个进化过程中,Android在显示系统这块也下了不少功夫,例如,使用硬件加速等技术,但本质原因似乎和硬件关系并不大,因为iPhone的硬件配置并不比那些价格相近的Android机器的硬件配置强,而iPhone UI的流畅性强却是有目共睹的。从Android 4.1(版本代号为Jelly Bean)开始,Android OS开发团队便力图在每个版本中解决一个重要问题。作为严重影响Android口碑问题之一的UI流畅性差的问题,首先在Android 4.1版本中得到了有效处理。其解决方法就是本文要介绍的Project Butter。Project Butter对Android Display系统进行了重构,引入了三个核心元素,即VSYNC、Triple Buffer和Choreographer。其中,VSYNC是理解Project Buffer的核心。VSYNC是Vertical Synchronization(垂直同步)的缩写,是一种在PC上已经很早就广泛使用的技术。读者可简单的把它认为是一种定时中断。接下来,本文将围绕VSYNC来介绍Android Display系统的工作方式。

Android系统UI交互滞后问题


在一个典型的显示系统中,frame buffer代表了屏幕即将要显示的一帧画面。假如CPU/GPU绘图过程与屏幕刷新所使用的buffer是同一块,那么当它们的速度不同步的时候,是很可能出现类似的画面“割裂”的。举个具体的例子来说,假设显示器的刷新率为66Hz,而CPU/GPU绘图能力则达到100Hz,也就是它们处理完成一帧数据分别需要0.015秒和0.01秒。

0.01秒时,由于两者速率相差不小,此时buffer中已经准备好了第1帧数据,显示器只显示了第1帧画面的2/3
0.015秒时,第1帧画面完整地显示出来了,此时buffer中有1/3的部分已经被填充上第2帧数据了
0.02秒时,Buffer中已经准备好第2帧数据,而显示屏出现了screen tearing,有三分之一是第2帧内容,其余的则属于第1帧画面

在单缓冲区的情况下,这个问题很难规避。所以引进了双缓冲技术,基本原理就是采用两块buffer。一块back buffer用于CPU/GPU后台绘制,另一块framebuffer则用于显示,当back buffer准备就绪后,它们才进行交换。那么什么时候切换两个缓冲区最合适呢?显示器有两个重要特性,行频和场频。行频(Horizontal ScanningFrequency)又称为“水平扫描频率”,是屏幕每秒钟从左至右扫描的次数; 场频(Vertical Scanning Frequency)也称为“垂直扫描频率”,是每秒钟整个屏幕刷新的次数。由此也可以得出它们的关系:
行频=场频*纵坐标分辨率。
当扫描完一个屏幕后,设备需要重新回到第一行以进入下一次的循环,此时有一段时间空隙,称为VerticalBlanking Interval(VBI)。这个时间点就是我们进行缓冲区交换的最佳时间。因为此时屏幕没有在刷新,也就避免了交换过程中出现screentearing的状况。VSync是VerticalSynchronization的简写,它利用VBI时期出现的vertical sync pulse来保证双缓冲在最佳时间点才进行交换。在没有VSync信号同步下的绘图过程:
没有VSYNC的绘图过程

  •  时间从0开始,进入第一个16ms:Display显示第0帧,CPU处理完第一帧后,GPU紧接其后处理继续第一帧。三者互不干扰,一切正常。
  • 时间进入第二个16ms:因为早在上一个16ms时间内,第1帧已经由CPU,GPU处理完毕。故Display可以直接显示第1帧。显示没有问题。但在本16ms期间,CPU和GPU却并未及时去绘制第2帧数据(注意前面的空白区),而是在本周期快结束时,CPU/GPU才去处理第2帧数据。
  • 时间进入第3个16ms,此时Display应该显示第2帧数据,但由于CPU和GPU还没有处理完第2帧数据,故Display只能继续显示第一帧的数据,结果使得第1帧多画了一次(对应时间段上标注了一个Jank)。
  • 通过上述分析可知,此处发生Jank的关键问题在于,为何第1个16ms段内,CPU/GPU没有及时处理第2帧数据?原因很简单,CPU可能是在忙别的事情(比如某个应用通过sleep固定时间来实现动画的逐帧显示),不知道该到处理UI绘制的时间了。可CPU一旦想起来要去处理第2帧数据,时间又错过了!

为解决这个问题,从Android 4.1Jelly Bean开始,Project Buffer引入了VSYNC,系统在收到VSync pulse后,将马上开始下一帧的渲染。结果如下图所示:

引入VSYNC的绘制过程

每收到VSYNC中断,CPU就开始处理各帧数据。大部分的Android显示设备刷新率是60Hz,这也就意味着每一帧最多只能有1/60=16ms左右的准备时间。假如CPU/GPU的FPS(FramesPer Second)高于这个值,那么显示效果将很好。但是,这时出现一个新问题:CPU和GPU处理数据的速度都能在16ms内完成,而且还有时间空余,但必须等到VSYNC信号到来后才处理下一帧数据,因此CPU/GPU的FPS被拉低到与Display的FPS相同。下图是采用双缓冲区的显示效果:

双缓冲下CPU/GPU FPS大于刷新频率

同时采用了双缓冲技术以及VSYNC,可以看到整个过程还是相当不错的,虽然CPU/GPU处理所用的时间时短时长,但总的来说都在16ms以内,因而不影响显示效果。A和B分别代表两个缓冲区,它们不断地交换来正确显示画面。如果CPU/GPU的FPS小于Display的FPS,会是什么情况呢?


双缓冲下CPU/GPU FPS小于刷新频率

当CPU/GPU的处理时间超过16ms时,第一个VSync到来时,缓冲区B中的数据还没有准备好,于是只能继续显示之前A缓冲区中的内容。而B完成后,又因为缺乏VSync信号,CPU/GPU只能等待下一个VSync的来临才开处理下一帧数据。于是在这一过程中,有一大段时间是被浪费。当下一个VSync出现时,CPU/GPU马上执行操作,此时它可操作的buffer是A,相应的显示屏对应的就是B。这时看起来就是正常的。只不过由于执行时间仍然超过16ms,导致下一次应该执行的缓冲区交换又被推迟了。也就是说在第二个16ms时间段,Display本应显示B帧,但却因为GPU还在处理B帧,导致A帧被重复显示,同时CPU无所事事,因为A 被Display在使用。B被GPU在使用。为什么CPU不能在第二个16ms处即VSync到来就开始工作呢?原因就是只有两个Buffer。如果有第三个Buffer的存在,CPU就可以开始工作,而不至于空闲。出于这一思路就引出了Triple Buffer。结果如图所示:


Triple Buffering

第二个16ms时间段,CPU使用C Buffer绘图。虽然刚开始还是会多显示A帧一次,但后续显示效果就比较好,第三个VSync信号到来时,由于GPU/CPU都处理完了B,因此B被显示,在第四个VSync信号到来时,GPU/CPU同时完成了A和C,并着手开始处理B,此时C被显示。从上图可以看出,CPU绘制的第C帧数据要到第四个16ms才能显示,这比双Buffer情况多了16ms延迟。我们知道,应用程序这边的本地窗口Surface在SurfaceFlinger服务进程端有一个对应的BufferQueue对象,该对象用于管理Surface的图形绘制缓冲区。BufferQueue中最多有32个BufferSlot,不过在实际使用时具体值是可以设置的。在Layer对象的onFirstRef函数中初始化了图形缓冲区的个数:
#ifdef TARGET_DISABLE_TRIPLE_BUFFERING
#warning "disabling triple buffering"
    mSurfaceTexture->setBufferCountServer(2);
#else
    mSurfaceTexture->setBufferCountServer(3);
#endif

Project Buffer分析


Project Buffer的三个关键点:
1. 需要VSYNC定时中断;
2. 当双Buffer不够使用时,该系统可分配第三块Buffer;
3. 图形buffer的绘制工作又VSYNC信号触发;


  • HardwareComposer封装了相关的HAL层,如果硬件厂商提供的HAL层实现能定时产生VSYNC中断,则直接使用硬件的VSYNC中断,否则HardwareComposer内部会通过VSyncThread来模拟产生VSYNC中断(其实现很简单,就是sleep固定时间,然后唤醒)。
  • 当VSYNC中断产生时(不管是硬件产生还是VSyncThread模拟的),VSyncHandler的onVSyncReceived函数将被调用。所以,对VSYNC中断来说,VSyncHandler的onVSyncReceived,就是其中断处理函数。
VSyncHandler的实例是EventThread。下边是EventThread类的声明:

class EventThread : public Thread, public DisplayHardware::VSyncHandler
EventThread本身运行在一个单独的线程中,并继承了VSyncHandler。EventThread在其线程函数threadLoop中等待下一次VSYNC的到来,并派发该中断事件给VSYNC监听者。通过EventThread,VSYNC中断事件可派发给多个该中断的监听者去处理。


IDisplayEventConnection是一个纯虚类,它代表VSYNC中断的监听者。其实体类是EventThread的内部类Connection。IDisplayEventConnection定义了一个getDataChannel函数,该函数返回一个BitTube实例,其内部实现为socketpair。这个实例提供的read/write方法,用于传送具体的信号数据。EventThread最重要的一个VSYNC监听者就是MessageQueue的mEvents对象,来自EventThread的VSYNC中断信号,将通过MessageQueue转化为一个REFRESH消息并传递给SurfaceFlinger的onMessageReceived函数处理。DisplayEventReceiver是一个abstract class,其JNI的代码部分会创建一个IDisplayEventConnection的VSYNC监听者对象。这样,来自EventThread的VSYNC中断信号就可以传递给Choreographer对象了。当Choreographer收到VSYNC信号时,就会调用使用者通过postCallback设置的回调函数。

没有更多推荐了,返回首页