Android(安卓)UI绘制原理(一)

最近在做类似于一个移动端数据收集、处理的平台，统计FPS，我只知道DPS啊，于是各种google，看了不少好东西，主要几个如下：
https://testerhome.com/topics/2232
http://blog.csdn.net/itfootball/article/details/43084527
https://testerhome.com/topics/1919
https://androidtest.org/android-graphics-performance-pattens/
以及老罗的一系列文章：http://blog.csdn.net/luoshengyang/article/details/7846923（高深，建议睡醒了看）
一个库：https://github.com/ChromiumWebApps/chromium/blob/master/build/android/pylib/perf/surface_stats_collector.py

加上以前看过的一些google官方的Android UI测试方法，于是总结了一下：关于Android 的UI呈现

View

Android界面上，View才是真正的显示视图
View 包含两种， View和ViewGroup，这种关系就像Java awt编程中的Component和Container，即ViewGroup是一种View，但里面又可以容纳View和另外的ViewGroup
View 的直接子类：Widget（就是各种控件，比如Button）
ViewGroup 的直接子类：Layout（也就对应于Android的六大布局组件，Relative，Table，Absolute，Frame，Grid和Linear）

Activity

并不是显示视图的容器，而是控制单元（提供交互）
Activity的生命周期，那些回调函数是用来控制页面的交互效果

Window

真正的显示视图容器
每个Activity在构造的时候，会初始化一个Window（PhoneWindow，可以通过getWindow（）方法拿到），每个Window对应一个DecorView（实际上是一个ViewGroup，可以往里添加东西）
setContentView（）方法，其实是来自于PhoneWindow

How to work

那么它们到底是怎么协调工作的呢？

layout里的xml布局文件为原料
LayoutInflater.inflate（）方法，用来实例化xml文件为view对象
我们看到的setContentView（R.layout.main）方法，写完整了其实应该长这样：getWindow().setContentView(LayoutInflater.from(this).inflate(R.layout.main,null))

帧（Frame）

我们看到的动画效果，其实是由很多个图片快速、连续显示造成的，每一幅图片就是一帧
FPS（frames per second）不是DPS（每秒造成的伤害），而是每秒渲染了多少帧
Hz：一般用来指屏幕刷新频率
普通电影的FPS是24，是考虑到了制作成本。FPS达到30时，画面会显得平滑连续。Android屏幕刷新列率为60Hz，相应的，FPS应该也要达到60，小了会卡顿，大了会画面撕裂
既然每秒要加载60帧，那么每一帧的渲染时间应该为 1000/60 = 16.67 （ms）

那么什么因素可能会导致16.67ms内完不成一帧的渲染呢？

手机太low，CPU + GPU合力工作效率低下，这个过程涉及到CPU将图形计算为多边形，在交由GPU去栅格化（Rasterization）
横竖屏切换，需要用savedInstanceState保存的view信息进行重画
动画效果太多
GC太多（Dalvik虚拟机 10~20 ms，改进为ART之后虽降低到2~3ms，但也会影响）
UI线程阻塞（Android 4.0 之后加入了render thread来减轻UI线程负担）
界面试图结构过于复杂（可以通过Hierachy View查看）
过度绘制

一些常见的UI测试方法，具体指标应该参照官方文档说明

OverDraw
StrictMode
Profile GPU rendering
Hierachy View