Android UI绘制优化

CPU与GPU工作流程

CPU 的任务繁多，做逻辑计算外，还要做内存管理、显示操作，因此在实际运算的时候性能会大打折扣，在没有 GPU 的时代，不能显示复杂的图形，其运算速度远跟不上今天复杂三维游戏的要求。即使 CPU的工作频率超过 2GHz 或更高，对它绘制图形提高也不大。这时 GPU
的设计就出来了


黄色的 Control 为控制器，用于协调控制整个 CPU 的运行，包括取出指令、控制其他模块的运行等；
绿色的 ALU （ Arithmetic Logic Unit ）是算术逻辑单元，用于进行数学、逻辑运算；
橙色的 Cache 和 DRAM 分别为缓存和 RAM ，用于存储信息。

卡顿原因分析

60Hz 刷新频率

• 12 fps ：由于人类眼睛的特殊生理结构，如果所看画面之帧率高于每秒约 10-12 帧的时候，就会认为是连贯的
• 24 fps ：有声电影的拍摄及播放帧率均为每秒 24 帧，对一般人而言已算可接受
• 30 fps ：早期的高动态电子游戏，帧率少于每秒 30 帧的话就会显得不连贯，这是因为没有动态模糊使流畅度降低
• 60 fps 在与手机交互过程中，如触摸和反馈 60 帧以下人是能感觉出来的。 60 帧以上不能察觉变化
  当帧率低于 60 fps 时感觉的画面的卡顿和迟滞现象

Android 系统每隔 16ms 发出 VSYNC 信号 (1000ms/60=16.66ms) ，触发对 UI 进行渲染， 如果每次渲染都成功这样就能够达到流畅的画面所需要的 60fps ，为了能够实现 60fps ，这意味着计算渲染的大多数操作都必须在 16ms 内完成。

卡顿原理分析

16 毫秒的时间主要被两件事情所占用
第一件：将 UI 对象转换为一系列多边形和纹理
第二件： CPU 传递处理数据到 GPU 。所以很明显，我们要缩短这两部分的时间，也就是说需要尽量减少对象转换的次数，以及上传数据的次数

如何减少这两部分的时间 以至于在 16ms 完成呢？
1、CPU 减少 xml 转换成对象的时间
2、GPU 减少重复绘制的时间

过度绘制

什么是过度绘制？
GPU的绘制过程，就像刷墙一样，一层一层的进行，16ms刷一次，这样就会造成图层覆盖的现象，既无用的的图层还被绘制在底层，造成不必要的浪费。

GPU过度绘制的几种情况

• 自定义控件中onDraw方法做了过多重复绘制；
• 布局层次太深，重叠性太强，用户看不到的区域GPU也会渲染，导致耗时增加；

过度绘制查看工具

那我们怎么才能查看到自己的布局是否有过度绘制了？

简单的小例子

下面我给界面做个优化吧~~

先上一张优化前的布局，方便优化后做比较

• 看到这张图片，不要惊讶，这个是我从码云上面下载了别人做的仿微信的APP；

我打开了开发者选项里面的过度绘制查看工具，我们可以看到这个布局上面，基本全是过度绘制了。深红色太多了！！！四层过度绘制了！！这如果是你的代码，并且这要是你们老板懂代码，估计会拉着你去黑咖啡了

我们现在需要做的就是一层一层的去减少
首先我查看了一下设置的app主题

我记得系统会给我们默认设置个背景色，好像现在是会有app启动时白屏或者黑屏的现象发生，虽然有些手机配置很高，感觉不出来，但是使用配置第一点的时候，会明显的感觉到~

我们做一下小小的调整，把主题默认的背景色去掉

我们来看看去掉主题的背景色后的效果

深红色变成了粉红色，原来的淡绿色区域变成了蓝色，有么有？所有的布局都减少了一层！

不过还是不行，还是想要进一步的优化，继续找找

发现原来fragment的外层activity还有一层背景色，我们把它去掉看看效果

原本蓝色的区域（一层过度绘制）也没了

不过我们要做就要做到优化完所有的，我们再来找找；

发现fragment也有种的父布局也加上了一个背景色，果断干掉他，来看看效果

现在没有主题色，没有父容器的背景色后，原本每条item还是蓝色，现在已经没有，没有过度绘制了，但是发现这些去掉了所有的背景色之后…好像默认变成了黑色了…我们开始还原原本该有的颜色吧

我们把应该有颜色的间隙部分，用TextView添加响应的高度，以及原来应该有的背景色，我们再来看看吧

是不是和原来效果图一样了？
到这里这个界面的优化完成了~ 那些文字和图片的蓝色区域，我们就不解决了，如果需要解决，那就自己去写自定义控件吧…

总结

布局优化的原则：

1. 减少不必要的嵌套；
2. 使用merger避免与父容器重叠；
3. 非业务需要，不要去添加背景色；

小总结：