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 设置背景图而导致的过度渲染.
总结一下, 优化步骤如下:
移除 Windows 默认的 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 来优化布局.
最后
如果你看到了这里, 觉得文章写得不错就点个赞呗? 如果你觉得那里值得改进的, 请给我留言. 一定会认真查询, 修正不足. 谢谢.
有一句老话说的好:"比你优秀的对手在学习, 你的仇人在磨刀, 你的闺蜜在减肥, 隔壁老王在练腰, 我们必须不断学习, 否则我们将被学习者超越." 当然一个人学习是枯燥的, 还需要一个良好的学习氛围, 因此我组建了一个学习交流探讨的社群, 欢迎大家一起来交流探讨共同进步. 还有一些收集整理的资料, 感兴趣的可以加群, 一起学习, 共同进步!
针对 Android 开发的同行, 小编这边给大家整理了一些资料, 其中分享内容包括但不限于 [高级 UI, 性能优化, 移动架构师, NDK, 混合式开发(ReactNative+Weex) 微信小程序, Flutter 等全方面的 Android 进阶实践技术] 希望能帮助大家学习提升进阶, 也节省大家在网上搜索资料的时间来学习, 也是可以分享给身边好友一起学习的!
希望读到这的您能转发分享和关注一下我, 以后还会更新技术干货, 谢谢您的支持!
来源: http://www.jianshu.com/p/4bc54c24adca