1 CPU与GPU工作流程
2 卡顿原因分析
3 解决过度绘制
4 hierarchy view 的使用
- CPU与GPU工作流程
cpu的任务繁多,做逻辑计算外,还要做内存管理 显示操作,因此在实际运算的时候性能会大打折扣,在没有GPU的时代,不能显示复杂的图形,其运算速度远跟不上今天复杂的三维游戏的要求.即使CPU的工作频率超过2GHz或者更高,对它绘制图形的提高也不大.这时GPU的设计就出来了。
- 格栅化
分析到这里，16毫秒的时间主要被两件事情所占用，第一件：将UI对象转换为一系列多边形和纹理；第二件：CPU传递处理数据到GPU。所以很明显，我们要缩短这两部分的时间，也就是说需要尽量减少对象转换的次数，以及上传数据的次数。
- 卡顿原因分析
在分析卡顿原理之前我们先来了解 60HZ这个东西
12fps : 由于人类眼睛的特殊生理结构,如果所看到画面之帧率高于每秒约10-12帧的时候,就会认为是连贯的
24FPS : 有声电影的拍摄及播放帧率约为每秒24帧,对一般人而言可以接受
30fps : 早期的高动态电子游戏,帧率少于每秒30帧的话就会显得不连贯,这是因为没有动态模糊是流畅度降低
60fps : 在与手机交互过程中,如触摸和反馈 60 帧以下人事能感觉出来的. 60 帧以上不能感受到变化
当帧率低于60fps 时感觉的画面的卡顿和迟滞现象
android 系统每隔16Ms发出 VSYNC信号(1000ms/60=16.66ms),触发对UI进行渲染,如果每次渲染都成功这样就能够达到流畅的画面所需要的60fps,为了能够实现60fps,这意味着计算渲染的大多数操作都必须在16ms内完成.
当这一帧画面渲染时间超过16ms的时候,垂直同步机制会让显示器硬件等待GPU完成格栅化渲染操作,这样会让这一帧画面,多停留了16ms,甚至更多,这样就造成了用户看起来很画面停顿.
16毫秒的时间主要被两件事情占用
- 将UI对象转换成一系列多边形和纹理
- CPU传递处理数据到GPU
所以要优化这两部分的时间,就是说需要尽量减少对象转换的次数,以及上传数据的次数(CPU减少xml转换对象的时间,GPU减少重复绘制时间)
解决过度绘制
GPU过度绘制几种情况
1. 自定义控件中 onDraw方法做了过度重复绘制
2.布局层次太深,重叠性太强.用户看不到的区域GPU也会渲染,导致耗时增加
关于解决过度绘制问题,我引用一篇博客http://blog.csdn.net/a740169405/article/details/53896497,里面写的很详细,我就不赘述了.
应用Hierarchy Viewer
目前Hierarchy Viewer只能在root过的机器才能使用. 主要是在没有root过的机器中view server这个服务是没有开启的. Hierarchy Viewer就无法连接到机器获取view层级信息.
开启H Viewer的步骤如下:
1：手机开启开发者模式, USB调试.
2：根据手机的Android系统版本:
4.0及以下, 没有root. 使用上述的开源工程ViewServer提供的方式.
4.0及以下, 已经root. 无需其他额外设置.
4.1及以上. 需要在PC端设置ANDROID_HVPROTO环境变量.
在Windows下可以这样设置: 打开环境变量, 添加名称ANDROID_HVPRORO, 值:ddm, 点击OK.
完成上述配置后, 你就可以打开Hierarchy Viewer了, 打开DDMS, 如下操作进入Hierarchy Viewer界面。
上图的三个联排的点是关键分析数据. 左起依次代表View的Measure, Layout和Draw的性能. 另外颜色表示该View的该项时间指数, 分为:
● 绿色, 表示该View的此项性能比该View Tree中超过50%的View都要快.
● 黄色, 表示该View的此项性能比该View Tree中超过50%的View都要慢.
● 红色, 表示该View的此项性能是View Tree中最慢的.
如果你的界面的Tree View中红点较多, 那就需要注意了. 一般来说:
1, Measure红点, 可能是布局中嵌套RelativeLayout, 或是嵌套LinearLayout都使用了weight属性.
2, Layout红点, 可能是布局层级太深.
3, Draw红点, 可能是自定义View的绘制有问题, 复杂计算等.