引子
- 今天在研究使用HierarchyViewer工具
- 打开ViewHierarchy,选择一个Activity的，选中某个View，选择工具中的Show Extras选项
- 观察单个view，选择单个view后会出现如下图所示图形。这里会看到Measure、Layout、Draw的耗时，查了下这里的三个参数，牵扯的知识挺广，其中还有有个60fps的概念也是比较重要。
Paste_Image.png
- 如果无法出现上面的耗时统计点击菜单 Profile Node，重新加载之后就有了
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的生命周期，那些回调函数(oncreate,onstart这些)是用来控制页面的交互效果
Window
- 真正的显示视图容器
每个Activity在构造的时候，会初始化一个Window（PhoneWindow，可以通过getWindow（）方法拿到），每个Window对应一个DecorView（实际上是一个ViewGroup，可以往里添加东西）
setContentView（）方法，其实是来自于PhoneWindow
那么它们到底是怎么协调工作的呢？
- 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查看）
- 手机太low，CPU + GPU合力工作效率低下，这个过程涉及到CPU将图形计算为多边形，在交由GPU去栅格化（Rasterization）
- 过度绘制，打开手机开发中调试里面开启GPU渲染
Paste_Image.png
- 绘制颜色的标识，从好到差：蓝色(1x次绘制),浅绿色(2x绘制),淡红色(3x绘制),红色(4x绘制)。
- 当然这也只能看到大概的绘制效果，如果想知道更详细的控件分析呢，那么可以使用Systrace来分析，下篇开开始学习
其他参考
- 主要原文
- 如何测量Android应用的帧率FPS和统计
- 简单的测量fps
- adb shell dumpsys gfxinfo "你自己的应用名字" > fps.txt
