Android性能优化Google课程翻译一:Render

Context:

我自己写下Google关于Android性能优化的视频课程的翻译，希望转载者不要删除我的博客地址http://blog.csdn.net/zhjali123

术语：

1.texture、meshes。举个例子，做一个飞机模型，你要先雕刻出立体的飞机模型（mesh），但是模型还没有上色，这是你要用张纸把它包起来，在上面画迷彩，这层有迷彩的纸就是（texture，中文叫纹理）。

Lesson1：Render（渲染）

1.Android设备最好的性能是1秒钟更新60帧(电影一般是24帧），1000ms/60帧 合计16ms/frame。这意味着你要在16ms内处理你所有的绘画逻辑。如果你错过了这个16ms，页面不会绘制，这就叫做 dropped frame。然而动画的运算并不会停止，所以呈现给用户的就是在平滑性上发生了跳跃。这就叫做laggy或者janky体验。

2.Android的渲染通道分为两个关键区域：CPU和GPU。

CPU（measure测量-->layout布局--->record记录--->execute执行，进行多边形polygon、纹理Texture处理）---->GPU(rasterization光栅化：将图案映射为像素组成的矩阵）

CPU的问题：不必要的layout，视图层次（View Hierachy）中无意义的计算、拆分（torn down）、重建（rebuilt）

XML转换到屏幕显示的原理过程：

XML----转换---->Screen，核心步骤：rasterization光栅化（如图）。Rasterization是非常的消耗资源，所以上个世纪90年代引入了单独的图像处理单元GPU。GPU使用一些指定的基础指令集（set of primitive: polygons多边形，textures 文理，images 图像)，而CPU在画东西到屏幕前，会给GPU输入这些指令（a set of primitive)。这一过程通常使用的API就是Android的OpenGL ES。

这意味着如果画一个button，他会在CPU中先转化为polygons多边形、texture纹理((computer graphics) An image applied to a polygon to create the appearance of a surface:图像被添加到一个多边形上来创造事物的外观)------------》传递给GPU进行rasterization光栅化。

其中有两处耗时操作：

1.在CPU中将button等事物 转换成相应的形状（polygons），绘制它的表面（texture）

2.CPU将数据传送GPU

对应措施：

你要减少CPU中绘制的事物和CPU往GPU上载数据，而OpenGL ES提供了向GPU上传数据和保存数据的API。所以，当你下次绘制一个button时，你只需要在GPU中引用它（也就是在GPU中完成polygons、texture），告诉OpenGL如何进行绘制它。一条经验之谈就是：优化渲染的性能意味着，尽可能快的上传数据到GPU和在GPU上尽可能长的保留数据。

从HoneyComb版本开始，整个View的渲染就在GPU中，并不断优化，所以你不用关心这个。例如：任何你的theme提供的资源如Bitmaps、Drawables等，被整合到一个单独的texture（感觉就是事物表面的意思）中,然后使用meshes上传到GPU像是点9图。这样每次你需要绘制这些资源时，你就不用做任何转换，他们已经存储在GPU中了。

然而随着UI事物更加先进，绘制流程也更加复杂。例如绘制一个image，这意味着上传Image到CPU再到GPU。使用Path则完全不同，你需要在CPU中创建一连串的polygons多边形，甚至在GPU中创建masking texture(蒙版纹理）来定义path。绘制字符，首先你必须在CPU中将绘制image---》上传到GPU---》在屏幕上绘制每一个字符串中字符的正方形，这些都被Android系统所处理。而这存在程序员都会遇的GPU问题OverDraw（过度绘制）

OverDraw：是一个单独的Frame（帧）中像素被重新绘制了多少次。例如UI卡片，上面有层VIew，绝大部分View在下边。这意味这我们费时的绘制大部分是不可见的。

查看OverDraw:进入手机开发者模式，打开show GPU overdraw开关。紫色（应该算是吧）：一次绘制；绿色2次绘制；粉色3次绘制；红色4次绘制（如图2）

下一篇博客讲怎么解决OverDraw

今天晚上在继续翻译吧！