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

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

关注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

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
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册