Android-UI性能分析

2017-01-01 10:46

引子

  • 今天在研究使用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查看)
  • 过度绘制,打开手机开发中调试里面开启GPU渲染

Paste_Image.png

- 绘制颜色的标识,从好到差:蓝色(1x次绘制),浅绿色(2x绘制),淡红色(3x绘制),红色(4x绘制)。

  • 当然这也只能看到大概的绘制效果,如果想知道更详细的控件分析呢,那么可以使用Systrace来分析,下篇开开始学习

其他参考