Android图形显示系统——上层显示1:界面绘制大纲-阿里云开发者社区

开发者社区> 开发与运维> 正文

Android图形显示系统——上层显示1:界面绘制大纲

简介: Android显示之应用界面绘制 越到上层,跟业务关联越直接,代码就越繁杂,Android上层显示的代码正是如此。此外,java语言本身繁复的特点(比C语言多了满屏的try-catch,比C++少了析构处理的优雅简洁,和更高级的语言scala、python等就别比了),更加剧了这一现象。 直接去看代码,往往会看得一头雾水,知其然而不知其所以然。在这时候,就要把代码扔掉,仔

Android显示之应用界面绘制

越到上层,跟业务关联越直接,代码就越繁杂,Android上层显示的代码正是如此。此外,java语言本身繁复的特点(比C语言多了满屏的try-catch,比C++少了析构处理的优雅简洁,和更高级的语言scala、python等就别比了),更加剧了这一现象。
直接去看代码,往往会看得一头雾水,知其然而不知其所以然。在这时候,就要把代码扔掉,仔细去理清需要实现什么,怎么实现,画一幅架构设计图出来,然后再跟代码去对比。Android这部分代码并不是圣经,有很多待商榷的地方,心中要有主见,批判性地看。

由于中间各种事耽搁,加上懒,一直没空写长篇博文,间隔了很长一段时间,请读者先回顾显示概述与下层显示:
http://blog.csdn.net/jxt1234and2010/article/details/44164691
另外,由于Android显示还是有不少人写的,某些模块有写得比较好的文章我就直接上链接,不自己写了,见谅。
下层显示关键词:SurfaceFlinger
上层显示关键词:View

初步章节安排:
1、界面绘制
2、布局计算
3、硬件加速下层实现
4、典型控件
5、资源管理

UI引擎设计原则

易用性

用户是很懒的,其实程序员也一样。 让应用开发者直接使用OpenGL去开发界面,无异于让他们赤手空拳打坦克。即便是使用图形引擎的接口,也已经相当繁琐了。
最理想的情形,是由编辑器搞定界面,所见即所得,配配参数就ok,如Unity3D。
一般都会提供足够多的默认控件,但如果应用有更绚丽的效果要求,也会提供接口实现。

高效性

作为UI引擎,掌控着足够完整的渲染流程,优化空间是相当大的。相对而言,难度也更大。这个高效反映在两方面,一是图形引擎的高效,一是脏区域识别的高效。

图形引擎的高效

第一个重要的点是下层图形引擎的选用
图形引擎的高效反映在两个方面:单体性能和复合性能。单体性能即渲染单个物体的性能,复合性能则是指在多个物体一起渲染的性能(多个物体一起渲染,有一些优化手段,比如作遮挡判断,消除非必要渲染,又比如作区域分划,多线程绘制各区域上的物体)。
图形引擎可以基于CPU渲染,也可以基于GPU渲染。就一般的UI渲染而言,CPU图形引擎优化得足够,倒也能满足要求,不会比GPU引擎差多少。

识别脏区域

与游戏界面的实时变换不同,对普通应用UI界面的渲染而言,大部分情况下一个页面的大部分面积处于不变状态。变化的区域又称脏区域。如何尽可能多地识别不变的部分,并作渲染规避,是UI引擎需要完成的很重要的工作。

比较理想的UI引擎的设计结构如下图:
UI引擎
应用开发者可以在三个层次上去实现UI效果。从上往下,自由度越来越高,开发难度也会越来越大。

Android的设计

UI引擎Android
Android并没有开发新的界面语言,而是采用xml+java的形式。由xml文件确定大致布局,java代码中做控制和微调。Android没有明确的UI解析引擎,UI解析反映在View、Layout等类的实现中。
应用开发者使用View的API(UI接口)、Canvas的API(引擎API)进行开发。

View

Android的控件和布局管理都抽象为View。部分View用于布局解析(各种Layout),部分View用于管理(复合View),部分View是实际的控件(TextView、ImageView、WebView等)。
具体的渲染流程完全取决于应用所选择的View的子类。
所有View组成一个树,布局时逐层创建树节点,渲染时逐级渲染。当调用invalidate刷新View时,由下往上逐层上报dirty区域。
具体可看这篇文章,写得比较清楚:
http://blog.csdn.net/xu_fu/article/details/7829721
一个View无论其渲染流程怎样,都必须保证其绘制内容固定在屏幕的指定范围,这是Android上层显示的设计原则。对于使用系统的图形引擎的应用,这可以通过在大图层上划分一块区域,设置裁剪范围而实现。但如果不使用系统图形引擎,就只好新建一个图层,并将主图层对应位置挖洞。
在View的invalidate函数中,将需要重绘的View作标志。并将其区域与上一级View的脏区域作合并,最终反映到ViewRootImpl的mDirty中来。
invalidate顺着View树脉络,一层一层往上刷新。
Invalidate
invalidate之后,该View即需要绘制,即是dirty的。

Canvas

Canvas是Android系统提供的图形引擎API,由于早期Android的图形渲染由Skia完成,Canvas接口也与Skia的API非常像。
绝大部分控件使用Canvas的API进行界面渲染,如TextView、ImageView及用户自定义,重载onDraw(Canvas canvas)的View。
比较特殊的是WebView,它不使用Canvas的API渲染,而是由Canvas获取Surface信息后,走web引擎渲染。

绘制主线

触发

众所周知,ViewRootImpl类的performTraversals方法,是所有界面布局、绘制的入口,但这个方法是怎么触发的呢?
在应用初起、View更新(触发invalidate)、动画、创建新Surface等情形下,会通过 scheduleTraversals 方法,向 Choreographer 类注册一个回调,Choreographer 类是用来接受vsync信号的,这样,在LCD发出vsync信号之后(也即新一帧开启),该回调被执行,即doTraversal -> performTraversals。
详情参见:
http://blog.csdn.net/farmer_cc/article/details/18619429

注:
1、performTraversals的调用是应用级的,也就是说,有可能会有多个应用去调这个函数。

主流程

流程
1、计算总大小,创建一个Surface用于存储渲染结果。
2、进行布局测量,算出每个View的范围。
3、进行layout,实例化所有子View。
4、一切就绪,执行渲染。
详细的看这篇文章吧:
http://blog.csdn.net/aaa2832/article/details/7849400
由这条绘制主线我们可以看出,跟View相关的一切操作,布局,初始化,渲染,全部在一个线程(事实上是主线程)完成,如果在这个过程中,其他线程修改了View的属性值,便会造成布局计算后的结果与后面实际渲染的需求不一致。
Android里面对此的解决方案是限制,即众所周知的只能在主线程更新UI。

渲染流程

软件渲染

drawSoftware
简洁明快的流程:
1、调 surface.lockCanvas,取得渲染入口Canvas。
2、从顶层View开始,按树递归调用View的draw方法。在draw方法中,所有View中的onDraw实现被调用。
3、调 surface.unlockCanvasAndPost
第1步对应的下层逻辑还是有点复杂的:
(1)dequeueBuffer获取一块新GraphicBuffer。
(2)将新GraphicBuffer锁定(lock),指明为CPU所访问。
(3)优化:如果存在上一帧所渲染的GraphicBuffer,且长宽与当前窗口一致,那么复制上一帧非dirty区域的内容到新一帧。如果不存在,将dirty区域设为全屏(即所有区域都要渲染)。
(4)将GraphicBuffer映射为一个SkBitmap,对应创建一个SkCanvas与之绑定,SkCanvas设置裁剪区域为第(3)步得到的dirty区域。
(5)SkCanvas包装为上层的Canvas传回。
第3步对应的下层逻辑就是 queueBuffer。
请注意,不是只需要绘制dirty的View的,因为View有可能会重叠,发生透明度混合,重叠部分影响到非dirty的View时,也应该绘制,Android并没有计算哪些View需要重绘,就笼统地让所有View执行onDraw方法。

软件渲染流程中,布局、渲染、事件响应全部集中在主线程,比较容易造成阻塞。

硬件渲染

为何要有硬件渲染这套流程,而不是仅改造图形引擎为用gpu的呢?
这是因为直接按软件渲染那套流程走下来,是不适合用gpu渲染的,强行换用OpenGL实现,效率会低得可怜。
硬件加速中draw的实现在ThreadedRenderer.java之中(这是5.0的,不同版本可能有不同,重点看原理)。
1、把创建好的Surface扔给硬件加速的Renderer,供其初始化(eglCreateWindowSurface要用)。
2、更新显示列表(updateRootDisplayList):创建一个记录命令的Canvas,将View中对Canvas的draw操作变成记录命令,非dirty的View不需要重新记录。
3、执行渲染(nSyncAndDrawFrame)。这一步是放渲染线程里面发一个任务,让其做一次绘制,一般不需要等渲染线程绘制完成。
具体实现在 DrawTask的drawFrame函数,后续章节详述:
frameworks/base/libs/hwui/renderthread/DrawFrameTask.cpp

从设计而言,硬件加速的渲染流程要比软件渲染流程好一些,显示列表的存在,给复合优化带来可能,即使不用gpu加速,也都有优势。

关于硬件加速几个常见问题和误区:
1、为何开启硬件加速要额外的内存?
很多文章里面将其误认为是开启OpenGL所需要的额外内存,其实不然。OpenGL上下文的内存消耗不会达到MB级,这个额外内存是hwui引擎所需要的缓存,大头是字体。具体大小可以通过设置系统属性修改。通过 adb shell getprop,可查看相关的属性(ro.hwui开头)。
HWUI
hwui内部机理是将文字解析到一个大的texture上,渲染具体文本时计算对应文字范围,取此texture中的一部分。因此有一个宽/高的设置,不像skia里面是一维的大小。
关于为什么要有字体缓存,可以看一下这篇文章:
http://mobile.51cto.com/abased-442805.htm
另外,在Android系统内存不足时,会去部分回收这个Cache。
2、显示列表机制是否显著提升了UI渲染性能?
显著提升渲染性能靠的是GPU,显示列表机制是将GPU用上的一种方法。
由于Android早期API全部基于CPU渲染,因此在UI渲染时所有资源(最主要还是图像Bitmap)都在CPU所能访问的内存中。GPU渲染时,必须要把对应的资源复制到显存中。这一个复制的过程,自然不希望每一帧时都做一遍。
保存所有命令及相应资源到一个显示列表上,然后回放,是一个可取的方案,其最大的好处是应用开发者仍然可以按原先的API进行开发,只需要打开一个开关就能用到硬件加速。
3、硬件加速是否可以使所有的界面绘制都用上GPU?
答案是否。请看下面的“非主线渲染”。

非主线渲染

就View层级设计而言,Android希望一个应用只有一个图层,并在这个图层上布局所有的控件,并且应用不用感知这个图层的内存所在,最多调Canvas接口即可,系统帮忙搞定图形渲染、Buffer循环、送显合成等繁琐事务。
但很可惜,这种方案不能满足所有需求:
1、对视频、照相等应用而言,它们需要直接访问物理内存(主要是硬件解码器和ISP等需要),把它们的显示放到一个图层的部分区域,不太现实。
2、所有UI操作和绘制集中在主线程,即使是硬件加速,也需要在主线程创建显示列表,做动画时,容易阻塞事件响应。
3、这种方案下,应用开发者无法自定义渲染流程,直接使用OpenGL等图形API进行开发,这样意味着使用不了游戏引擎。

SurfaceView应运而生,它的原理,就是打洞覆盖:另起一个图层(即新建一个Surface),并把主图层的相应区域置为透明,然后渲染就发生在新图层中,最终显示效果自然是依赖SurfaceFlinger的叠加。
用法参考:
http://blog.csdn.net/ithomer/article/details/7280968
其中,SurfaceHolder往下会对应着一个Buffer循环队列,这个是物理共享内存的抽象,因此可以做为视频、相机预览流的指定输入。
网上的教程中,SurfaceView的用法都在另一个线程中,先lockCanvas,调用Canvas的接口绘制画面之后,调unlockCanvasAndPost。这种方式,便是典型的调CPU引擎-Skia渲染的方式。
尽管应用开发者可以用SurfaceView直接开发基于OpenGL渲染的程序(SurfaceHolder可以用于创建OpenGL上下文),Google还是很仁慈地提供了GLSurfaceView,这个类帮开发者创建好了上下文和相应的渲染线程,开发者可以直接在回调函数中使用OpenGL,简单很多。

请注意:
1、SurfaceView不会自动起一个单独的线程去渲染,只是这个View上面的渲染可以在任意线程完成。开发者执意在主线程去渲染这个View,也是可以的,就像以前QQ某一版的引导页一样,CPU差一点的机器滑都滑不动(净给我们这些做系统优化的出难题)。
2、SurfaceView虽然可以把渲染流程移到另一个线程执行,但它的存在同时增加了SurfaceFlinger的合成负担(图层数增加),不要以为这就是一个很高效的View,如果是出于提升性能的目的而使用,请仔细权衡一下得失。
3、硬件加速属性不影响SurfaceView的渲染方式,lockCanvas必然得到用CPU绘制的Canvas。要在SurfaceView中用上GPU渲染,只好自已建上下文或用GLSurfaceView,接入3D引擎。补充,2015.8.14之后,Android提供了一个lockHardwareCanvas方法,用此方法可以得到硬件加速的Canvas,Android 6.0上已经可以使用,这可是个大福音
4、SurfaceView系列的渲染流程不在performTraversals主线中,因此一般也不受vsync限制(当然,可以设计流程使之受限),也不会像主线渲染必须由invalidate触发。不过,如果渲染太快,在下层显示的窗口管理模块,可以使之阻塞在申请Buffer的步骤上。

Android的设计吐槽

Android的发展也有些年头了,图形显示部分更是一改再改,几乎面目全非,总算是满足了手机硬件发展的需求,实现了一个比较高效,对开发者相对友好的界面绘制系统,相对于其他系统来说,其实也算优秀了。然而,作为一个逐渐演进的复杂系统,背负着不少历史的包袱,总会有各种各样的不合理,这里就来吐槽一下:
1、主线程单一管理界面
个人认为的最大槽点,没有之一。所有UI操作集中到一个线程后无法并行,而measure/layout/draw都是耗时大户。在应用启动、屏幕旋转、列表滑动等场景,屡屡出现性能问题。ART模式开启,加快了java代码执行效率后,好了一些,但指标仍然不好看。

2、脏区域识别之后并没有充分地优化
软件渲染时,尽管限制了渲染区域,但所有View的onDraw方法一个不丢的执行了一遍。
硬件渲染时,避免了没刷新的View调onDraw方法更新显示列表,但显示列表中的命令仍然一个不落的在全屏幕上执行了一遍。
一个比较容易想到的优化方案就是为主流程中的View建立一个R-Tree索引,invalidate这一接口修改为可以传入一个矩形范围R,更新时,利用R-Tree索引找出包含R的所有叶子View,令这些View在R范围重绘一次即可。

这个槽点其实影响倒不是很大,大部分情况下View不多,且如果出现性能问题,基本上都是一半以上的屏幕刷新。

3、图层分配方案比较浪费内存和内存传输带宽(DDR带宽)
下图是对小米平板上相机应用 dumpsys SurfaceFlinger的一个结果
小米相机
由上图可以看出,SurfaceView的Layer(相机的预览Surface)和com.android.camera的Layer(主渲染流程的Surface)是一样大的,都差不多占了全屏。
但实际上,com.android.camera只有几个图标,这个Layer绝大部分是透明的。考虑到TrippleBuffer机制,按透明部分约为1024*2048的大小算,就浪费了1024*2048*4*3=24M的内存。
而且在SurfaceFlinger作合成时,透明部分也要参与,按最省内存传输带宽的在线合成(只需要一读)方式,预览帧按30fps算,透明部分所需要的DDR带宽就是8M*30/s = 240M/s。一般手机上的DDR带宽才800M/s(高端手机应该有1600),这就占用了几乎1/3。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章