Android性能优化之渲染

Google近期在Udacity上发布了Android性能优化的在线课程，目前有三个篇章，分别从渲染，运算与内存，电量三个方面介绍了如何去优化性能，这些课程是Google以前在Youtube上发布的Android性能优化典范专题课程的细化与补充。

下面是渲染篇章的学习笔记，部份内容和前面的性能优化典范有重合，欢迎你们一块儿学习交流！

引用自 http://www.howcode.cn 

1)Why Rendering Performance Matters

如今有很多App为了达到很华丽的视觉效果，会须要在界面上层叠不少的视图组件，可是这会很容易引发性能问题。如何平衡Design与Performance就很须要智慧了。

2)Defining ‘Jank’

大多数手机的屏幕刷新频率是60hz，若是在1000/60=16.67ms内没有办法把这一帧的任务执行完毕，就会发生丢帧的现象。丢帧越多，用户感觉到的卡顿状况就越严重。

3)Rendering Pipeline: Common Problems

渲染操做一般依赖于两个核心组件：CPU与GPU。CPU负责包括Measure，Layout，Record，Execute的计算操做，GPU负责Rasterization(栅格化)操做。CPU一般存在的问题的缘由是存在非必需的视图组件，它不只仅会带来重复的计算操做，并且还会占用额外的GPU资源。

4)Android UI and the GPU

了解Android是如何利用GPU进行画面渲染有助于咱们更好的理解性能问题。一个很直接的问题是：activity的画面是如何绘制到屏幕上的？那些复杂的XML布局文件又是如何可以被识别并绘制出来的？

Resterization栅格化是绘制那些Button，Shape，Path，String，Bitmap等组件最基础的操做。它把那些组件拆分到不一样的像素上进行显示。这是一个很费时的操做，GPU的引入就是为了加快栅格化的操做。

CPU负责把UI组件计算成Polygons，Texture纹理，而后交给GPU进行栅格化渲染。

然而每次从CPU转移到GPU是一件很麻烦的事情，所幸的是OpenGL ES能够把那些须要渲染的纹理Hold在GPU Memory里面，在下次须要渲染的时候直接进行操做。因此若是你更新了GPU所hold住的纹理内容，那么以前保存的状态就丢失了。

在Android里面那些由主题所提供的资源，例如Bitmaps，Drawables都是一块儿打包到统一的Texture纹理当中，而后再传递到GPU里面，这意味着每次你须要使用这些资源的时候，都是直接从纹理里面进行获取渲染的。固然随着UI组件的愈来愈丰富，有了更多演变的形态。例如显示图片的时候，须要先通过CPU的计算加载到内存中，而后传递给GPU进行渲染。文字的显示比较复杂，须要先通过CPU换算成纹理，而后交给GPU进行渲染，返回到CPU绘制单个字符的时候，再从新引用通过GPU渲染的内容。动画则存在一个更加复杂的操做流程。

为了可以使得App流畅，咱们须要在每帧16ms之内处理完全部的CPU与GPU的计算，绘制，渲染等等操做。

5)GPU Problem: Overdraw

Overdraw(过分绘制)描述的是屏幕上的某个像素在同一帧的时间内被绘制了屡次。在多层次重叠的UI结构里面，若是不可见的UI也在作绘制的操做，会致使某些像素区域被绘制了屡次。这样就会浪费大量的CPU以及GPU资源。

当设计上追求更华丽的视觉效果的时候，咱们就容易陷入采用复杂的多层次重叠视图来实现这种视觉效果的怪圈。这很容易致使大量的性能问题，为了得到最佳的性能，咱们必须尽可能减小Overdraw的状况发生。

幸运的是，咱们能够经过手机设置里面的开发者选项，打开Show GPU Overdraw的选项，观察UI上的Overdraw状况。

蓝色，淡绿，淡红，深红表明了4种不一样程度的Overdraw状况，咱们的目标就是尽可能减小红色Overdraw，看到更多的蓝色区域。

6)Visualize and Fix Overdraw - Quiz & Solution

这里举了一个例子，经过XML文件能够看到有好几处非必需的background。经过把XML中非必需的background移除以后，能够显著减小布局的过分绘制。其中一个比较有意思的地方是：针对ListView中的Avatar ImageView的设置，在getView的代码里面，判断是否获取到对应的Bitmap，在获取到Avatar的图像以后，把ImageView的Background设置为Transparent，只有当图像没有获取到的时候才设置对应的Background占位图片，这样能够避免由于给Avatar设置背景图而致使的过分渲染。

总结一下，优化步骤以下：

• 移除Window默认的Background
• 移除XML布局文件中非必需的Background
• 按需显示占位背景图片

7)ClipRect & QuickReject

前面有提到过，对不可见的UI组件进行绘制更新会致使Overdraw。例如Nav Drawer从前置可见的Activity滑出以后，若是还继续绘制那些在Nav Drawer里面不可见的UI组件，这就致使了Overdraw。为了解决这个问题，Android系统会经过避免绘制那些彻底不可见的组件来尽可能减小Overdraw。那些Nav Drawer里面不可见的View就不会被执行浪费资源。

可是不幸的是，对于那些过于复杂的自定义的View(一般重写了onDraw方法)，Android系统没法检测在onDraw里面具体会执行什么操做，系统没法监控并自动优化，也就没法避免Overdraw了。可是咱们能够经过canvas.clipRect()来帮助系统识别那些可见的区域。这个方法能够指定一块矩形区域，只有在这个区域内才会被绘制，其余的区域会被忽视。这个API能够很好的帮助那些有多组重叠组件的自定义View来控制显示的区域。同时clipRect方法还能够帮助节约CPU与GPU资源，在clipRect区域以外的绘制指令都不会被执行，那些部份内容在矩形区域内的组件，仍然会获得绘制。

除了clipRect方法以外，咱们还可使用canvas.quickreject()来判断是否没和某个矩形相交，从而跳过那些非矩形区域内的绘制操做。

8)Apply clipRect and quickReject - Quiz & Solution

上面的示例图中显示了一个自定义的View，主要效果是呈现多张重叠的卡片。这个View的onDraw方法以下图所示：

打开开发者选项中的显示过分渲染，能够看到咱们这个自定义的View部分区域存在着过分绘制。那么是什么缘由致使过分绘制的呢？

9)Fixing Overdraw with Canvas API

下面的代码显示了如何经过clipRect来解决自定义View的过分绘制，提升自定义View的绘制性能：

下面是优化事后的效果：

10)Layouts, Invalidations and Perf

Android须要把XML布局文件转换成GPU可以识别并绘制的对象。这个操做是在DisplayList的帮助下完成的。DisplayList持有全部将要交给GPU绘制到屏幕上的数据信息。

在某个View第一次须要被渲染时，Display List会所以被建立，当这个View要显示到屏幕上时，咱们会执行GPU的绘制指令来进行渲染。

若是View的Property属性发生了改变（例如移动位置），咱们就仅仅须要Execute Display List就够了。

然而若是你修改了View中的某些可见组件的内容，那么以前的DisplayList就没法继续使用了，咱们须要从新建立一个DisplayList并从新执行渲染指令更新到屏幕上。

请注意：任什么时候候View中的绘制内容发生变化时，都会须要从新建立DisplayList，渲染DisplayList，更新到屏幕上等一系列操做。这个流程的表现性能取决于你的View的复杂程度，View的状态变化以及渲染管道的执行性能。举个例子，假设某个Button的大小须要增大到目前的两倍，在增大Button大小以前，须要经过父View从新计算并摆放其余子View的位置。修改View的大小会触发整个HierarcyView的从新计算大小的操做。若是是修改View的位置则会触发HierarchView从新计算其余View的位置。若是布局很复杂，这就会很容易致使严重的性能问题。

11)Hierarchy Viewer: Walkthrough

Hierarchy Viewer能够很直接的呈现布局的层次关系，视图组件的各类属性。 咱们能够经过红，黄，绿三种不一样的颜色来区分布局的Measure，Layout，Executive的相对性能表现如何。

12)Nested Hierarchies and Performance

提高布局性能的关键点是尽可能保持布局层级的扁平化，避免出现重复的嵌套布局。例以下面的例子，有2行显示相同内容的视图，分别用两种不一样的写法来实现，他们有着不一样的层级。

下图显示了使用2种不一样的写法，在Hierarchy Viewer上呈现出来的性能测试差别：

13)Optimizing Your Layout

下图举例演示了如何优化ListItem的布局，经过RelativeLayout替代旧方案中的嵌套LinearLayout来优化布局。