# 引子 - 今天在研究使用HierarchyViewer工具 - 打开ViewHierarchy,选择一个Activity的，选中某个View，选择工具中的Show Extras选项 - 观察单个view，选择单个view后会出现如下图所示图形。这里会看到Measure、Layout、Draw的耗时，查了下这里的三个参数，牵扯的知识挺广，其中还有有个**60fps**的概念也是比较重要。  - 如果无法出现上面的耗时统计点击菜单 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查看） - 过度绘制，**打开手机开发中调试里面开启GPU渲染**   - 绘制颜色的标识，从好到差：蓝色(1x次绘制),浅绿色(2x绘制),淡红色(3x绘制),红色(4x绘制)。 - 当然这也只能看到大概的绘制效果，如果想知道更详细的控件分析呢，那么可以使用**Systrace**来分析，下篇开开始学习 ## 其他参考 - [主要原文](https://testerhome.com/topics/4441) - [如何测量Android应用的帧率FPS和统计](http://jingyan.baidu.com/article/ac6a9a5e7e5f352b653eacfa.html) - 简单的测量fps - adb shell dumpsys gfxinfo "你自己的应用名字" > fps.txt