叁叁肆

这个世界会好吗

453篇博客

Android UI机制演变小记

叁叁肆2018-09-19 14:05

本文来自网易云社区

作者:宋文海


常常听到这样一种疑问,为什么Android没有iOS那么流畅?为了解决这个问题,Google几乎在每个版本的Android系统更新中的都有这方面的优化,Android 3.0开始引入硬件加速,4.0引入Vsync、Triple buffer,4.1引入Choreographer,5.0引入Render Thread。

其中Choreographer机制在SDK中提供了一组API给应用开发者使用,和应用层开发息息相关。Choreographer可以看成和Handler类似的任务处理中心,区别在于Handler是基于Looper不断的进行轮询调度,而Choreographer是结合底层的Vsync事件进行有规律的调度。理想情况下,如果采用60fps的显示屏,即1秒显示60帧,那么Choreographer最快可以做到1/60秒进行一次调度,否则就是发生了丢帧。有了Choreographer,UI相关的任务可以做到在Vsync事件到来时统一处理。

Choreographer接受三种类型的任务,CALLBACK_INPUT、CALLBACK_ANIMATION和CALLBACK_TRAVERSAL。当Vsync事件达到时,Choreographer会按此顺序执行任务。从调度顺序来看,CALLBACK_INPUT是最高的,因为用户对触摸事件是最敏感的。常见的invalidate方法通过ViewRootImpl投递了一个CALLBACK_TRAVERSAL类型的任务,当Vsync事件到来时执行我们熟悉的performTraversal方法。动画方面,3.0之前的View Animation通过在draw方法中drawAnimation来执行,新的Property Animation通过CALLBACK_ANIMATION来执行动画,说明动画的优先级在Android新版本中得到了提高。

和Handler类似,Choreographer也是通过post方法来提交任务,Choreographer提供了两种post方法,postCallback(Runnbale)和postFrameCallback(FrameCallback)。FrameCallback的接口方法比Runnbale的接口方法多一个表示当前帧时间的参数,通过这个参数可以判断出是否发生了丢帧。

Choreographer是一个ThreadLocal的单例,创建Choreographer的线程必须要有Looper。既然Choreographer是基于Vsync事件进行任务调度的,为什么还需要Looper。从下面的构造函数可以看到,是FrameHandler和FrameDisplayEventReceiver成员需要Looper。 

private Choreographer(Looper looper) {
    mLooper = looper;
    mHandler = new FrameHandler(looper);
    mDisplayEventReceiver = USE_VSYNC ? new FrameDisplayEventReceiver(looper) : null;

    ···
}

FrameDisplayEventReceiver需要用Looper是因为它在native层构建NativeDisplayEventReceiver时要用到Looper中的MessageQueue;在Native层,Vsync事件和Looper中的派发的事件共用同一个MessageQueue。


上图是Choreographer请求和派发Vsync事件的流程图。如图可见,请求和派发Vsync事件时都需要FrameHandler来进行调度。 在请求Vsync事件的流程中,如果是延时请求,需要通过FrameHandler来控制时间;如果某个线程拿了另一个线程的Choreographer请求Vsync事件的时候,isRunningOnLooperThreadLocked返回false,此时需要通过FrameHandler来切换线程,确保事件调度都在Choreographer所在线程中实施。

通过上面两幅图可以看到,第一幅图因为没有在Vsync事件到来时及时处理,导致丢帧;第二幅图,引入Choreographer后,每一帧都在Vsync事件到来时刷新,避免了丢帧。


上面两种情况每一帧都能在两次Vsync事件之间完成,万一某些帧的处理时间很长,丢帧还是不可避免。如上图所示,由于B帧处理时间过长,A缓冲区被屏幕占用,无法开始下一帧的处理,导致下一帧继续丢帧。为了避免这种情况,Android引入了Triple buffer,三缓冲机制。


当B帧处理超时,A帧缓冲区被屏幕占用的情况下,CPU可以拿第三个缓冲区C进行处理,即使C帧处理也超时了,但仍然可以避免丢帧。

Triple buffer的引入提高了CPU和GPU的并行程度,一定程度上提高了UI流畅性。而Render Thread的引入,则进一步提高了CPU内部的并行程度。引入Render Thread之前,所有CPU部分和UI相关的操作都在进行UI Thread进行。从Android 5.0开始,UI Thread中的那些和绘制相关的处理被移到了Render Thread中处理,这部分处理更偏向于和GPU交互,可以和UI Thread并行执行。

从上图可以看到,前一帧由于UI Thread操作过多,第二帧Vsync信号到来时Render Thread还在进行操作;尽管如此,得益于UI Thread和Render Thread可以并行操作,后一帧的UI Thread也开始执行了。因此,Render Thread的引入进一步提高了UI处理的并行性,从而提高了UI流畅度。

随着这些机制的逐步引入,Android的UI流畅度有了很大提高。虽然在硬件加速方面,由于Android硬件多样化,和积淀已久的iOS还有差距,但是相信随着时间推移,差距也会越来越小。而且,Android还在陆续引入Art虚拟机,Doze休眠等提高系统整体性能的机制,这些机制也能从侧面提高UI流畅度,相信Android的UI体验还会越来越好。



网易云免费体验馆0成本体验20+款云产品!

更多网易研发、产品、运营经验分享请访问网易云社区