移动性能测试 Android 的 UI 呈现 (一)

fenfenzhong · 发布于 2016年03月17日 · 最后由 fenfenzhong 回复于 2016年08月03日 · 938 次阅读
本帖已被设为精华帖!

关注TesterHome蛮久了,今天第一次发帖。
在公司我主要关注移动测试,最近在尝试专项,专项水很深,自己深知功力不够,于是就碰到一点记录一点,以后我将会把自己的那些学习笔记逐渐贴上来,和大家分享

前言

在公司做的一个项目,类似于一个移动端数据收集、处理的平台吧,刚开始做,很多东西都在慢慢完善,功能也在持续添加,Q1接了老大一个新需求,统计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

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

Activity

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

Window

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

How to work

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

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

帧(Frame)

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

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

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

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

  1. OverDraw
  2. StrictMode
  3. Profile GPU rendering
  4. Hierachy View

传送门

Android 的 UI 呈现(二)

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 15 条回复
7059

帅帅哒

703

牛,这种学习太多值得学习,自己也查过很多资料,但是不善于总结

6859

插个眼

1123

赞,欢迎继续!

—— 来自TesterHome官方 安卓客户端

4365

整理的不错,期待下一篇

5273

大赞,话说插眼什么意思

—— 来自TesterHome官方 安卓客户端

7027

懂了 所以Window里面装着的是ViewGroup

5493

#1楼 @sunhao 多谢浩哥

5493

#7楼 @runaway_girl UI呈现(二)里有更详细的说明

96

好好学习一下

8023

mark,感谢分享。。。

8270

不错。谢谢楼主

96

最近在研究app自动化,一直在找这方面的信息,谢谢楼主分享!

5493 fenfenzhong [该话题已被删除] 中提及了此贴 07月29日 16:21
5493 fenfenzhong [该话题已被删除] 中提及了此贴 08月02日 15:27
96

@fenfenzhong 有没有统计游戏FPS的方法

5493

#16楼 @hopecao 游戏可以用SurfaceFlinger,root 过的话用service call SurfaceFlinger 1013 还挺准确的,跟引擎自带的统计出来的FPS相差不多,我不在游戏行业,但之前一个坛友跟我讨论时好像是这么说的

5493 fenfenzhong FPS 计算方法的比较 中提及了此贴 01月19日 11:13
5493 fenfenzhong Android 的 UI 呈现 (二) 中提及了此贴 08月08日 14:04
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册