学习：Android性能优化典范

android性能优化
创建更快更优秀的android应用
渲染机制、内存与GC、电量优化

0）render performance
大多数用户所感知的卡顿问题最重要的根源都是因为渲染性能
Android系统无法及时完成复杂界面渲染操作
Android系统每隔16ms发出VSYNC信号，触发UI渲染
只有每次渲染成功，才能够达到流畅画面所需要的60fps的帧率，这也就意味着程序的大多数操作都必须在16ms内完成
如果你的某个操作超过16ms，系统得到VSYNC信号的时候就无法进行正常渲染，出现丢帧现象


用户容易在UI执行动画或者滑动listView的时候感知到卡顿不流畅，是因为这里的操作相对复杂，容易发生丢帧的现象，从而感觉卡顿。
有很多原因可以导致丢帧，
1.也许是因为你的layout太过复杂，无法在16ms内完成渲染，
2.有可能因为你的UI上有层叠太多的绘制单元，
3.还有可能是因为动画执行的次数过多。这些都会导致CPU或者GPU负载过重。

可以使用辅助工具定位问题
可以使用HierarchyViewer来查找Activity中的布局是否过于复杂，
也可以使用手机设置里面的开发者选项，打开Show GPU Overdraw等选项进行观察。
你还可以使用TraceView来观察CPU的执行情况，更加快捷的找到性能瓶颈

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

当设计上追求更华丽的视觉效果的时候，我们就容易陷入采用越来越多的层叠组件来实现这种视觉效果的怪圈。这很容易导致大量的性能问题，为了获得最佳的性能，我们必须尽量减少Overdraw的情况发生。

幸运的是，我们可以通过手机设置里面的开发者选项，打开ShowGPU Overdraw的选项，可以观察UI上的Overdraw情况。

蓝色，淡绿，淡红，深红代表了4种不同程度Overdraw情况，我们的目标就是尽量减少红色Overdraw，看到更多的蓝色区域。

Overdraw有时候是因为你的UI布局存在大量重叠的部分，还有的时候是因为必须得重叠背景。例如某个Activity有个一个背景，然后里面的Layout又有自己的背景，同时子View又分别有自己的背景。仅仅是通过移除非必须的背景图片，这就能够减少大量的红色Overdraw区域，增加蓝色区域的占比。这一措施能够显著提升程序性能。

2）Understanding VSYNC

为了理解App是如何进行渲染的，我们必须了解手机硬件是如何工作，那么就必须理解什么是VSYNC。
在讲解VSYNC之前，我们需要了解两个相关的概念：

Refresh Rate ：代表了屏幕在一秒内的刷新屏幕的次数，这取决于硬件的固定参数，例如60Hz。
Frame Rate ：代表了GPU在一秒内绘制操作的帧数，例如30fps，60fps。

GPU会获取图形数据进行渲染，然后硬件负责把渲染后的内容呈现到屏幕上，他们两者不停的进行协作。

理解图像渲染里面的两重与三重缓存机制，这个概念比较复杂，请移步查看这里：
http://source.android.com/devices/graphics/index.html，还有这里http://article.yeeyan.org/view/37503/304664。

通常来说，帧率超过刷新频率只是一种理想的状况，在超过60fps的情况下，GPU所产生的帧数据会因为等待VSYNC的刷新信息而被Hold住，这样能够保持每次刷新都有实际的新数据可以显示。但是我们遇到更多的情况是帧率小于刷新频率。

在这种情况下，某些帧显示的画面会与上一帧的画面相同。更糟糕的事情是，帧率从超过60fps突然掉到60fps以下，这样就会发生LAG,JANK,HITCHING等卡顿掉帧的的不顺滑的情况。这也是用户感受不好的原因所在。

3）Tool：Profile GPU Rendering
性能的问题如此的麻烦，幸好我们可以有工具进行调试。打开手机的开发者选项，选择Profile GPU Rendering，选中 On Screen as bars的选项。

选择了这样以后，我们可以在手机画面上看到丰富的GPU绘制图形信息，分别关于StatusBar，NavBar，激活的程序Activity区域的GPU Rendering信息。

随着界面的刷新，界面上会滚动垂直的柱状图来表示每帧画面所需要渲染的时间，柱状图越高表示花费的渲染时间越长。

中间有一根绿色的横线，代表16ms，我们需要确保每一帧花费的总时间都低于这条横线，这样才能够避免出现卡顿的问题。

每一条柱状线都包含三部分，蓝色代表测量绘制DisplayList的时间，红色代表OpenGL渲染DisplayList所需要的时间，黄色代表CPU等待GPU处理的时间。

4）Why 60fps?
我们通常都会提到60fps与16ms，可是知道为何是以程序是否达到60fps来作为App性能的衡量标准吗？这是因为人眼与大脑之间的协作无法感知草果60fps的画面更新。

12fps大概类似手动快速翻动书籍的频率，这明显是可以改知道不够顺滑的。24fps使得人眼感知的是连续线性运动，这其实是归功于运动模糊的效果。24fps是电影胶卷圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。但是低于30fps是无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，当然好过60fps是没有必要的。
开发app的性能就是保持60fps，这意味着每一帧你只有16ms=1000/60的时间来处理所有的任务。

5）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计算，绘制，渲染等等操作。

6）Invalidations，Layouts，and Performance

顺滑精妙的动画是app设计里面最重要的元素之一，这些动画能够显著提升用户体验。下面会讲解android系统是如何处理UI组件的更新操作的。

通常来说，Android需要把XML布局文件转换成GPU能够识别并绘制的对象。这个操作实在DisplayList的帮助下完成的。DisplayList持有所有将要交给GPU绘制到屏幕上的数据信息。

在某个View第一次需要被渲染时，DisplayList会因此而被创建，当这个View要显示到屏幕上时，我们会执行GPU的绘制指令来进行渲染。如果你在后续有执行勒事移动这个View的位置等操作需要再次渲染这个View时，我们就仅仅需要额外操作一次渲染指令就够了。然而如果你修改了View中的某些可见组件，那么之前的DisplayList就无法继续使用了，我们需要从头创建一个DisplayList并且重新执行渲染指令并更新到屏幕上。

需要注意的是：任何时候View中的绘制内容发生变化时，都重新执行创建DisplayList，渲染DisplayList，更新到屏幕上等一系列操作。这个流程的表现性能取决于你的View的复杂程度，View的状态变化以及渲染管道的执行性能。举个例子，假设某个按钮的Button需要增到到目前的两倍，在增到Button大小之前需要通过父View重新计算并摆放其他子Viw饿位置。修改Vie的大小浍出发整个HierarcyView重新计算大小的操作。如果是修改View的位置则会触发HierarchView重新计算其他View的位置。如果布局很复杂，这就会很容导致严重的性能问题。我们需要尽量减少Overdraw

我们可以通过前面介绍的Monitor GPU Rendering来查看渲染的表现性能如何，另外也可以通过开发者选项里面的Show GPU view updates来查看时图更新的操作，最后我们还可以通过HierarchyViewer这个工具来查看布局，使得布局尽量扁平化，移除非必须的UI组件，这些操作能够减少Measure，Layout的计算时间。

7）Overdraw，Cliprect，QuickReject
引起性能问题的一个很重要的方面是因为过多复杂的绘制操作。我们可以通过工具来检查并修复标准UI组件Overdraw 问题，但是针对高度自定义的UI组件则显得有些力不从心。

又一个窍门是我们通过执行几个APIs方法来显著提神绘制操作的性能。前面有提到过，非可见UI组件绘制更新会导致Overdraw。例如NavDrawer从前置可见的Activity滑出后，如果哈继续绘制那些在Nav Drawer里面不可见组件，这就导致了Overdraw。为了解决这个问你题，Android系统会通过避免绘制那些完全不可见的组件来尽量减少Overdraw。那些Nav Drawer里面不可见的View就不会被执行浪费资源

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

出了clipRect方法之外，我们还可以使用canvas。quickreject（）来判断是否没和某个据悉区域相交，从而跳过那些非居心区域内的绘制操作。做了哪些优化之后，我们可以通过上面介绍的ShowGPU Overdraw来查看效果。