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

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

关注 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 条回复 时间 点赞

帅帅哒

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

插个眼

赞,欢迎继续!

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

整理的不错,期待下一篇

大赞,话说插眼什么意思

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

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

#1 楼 @sunhao 多谢浩哥

好好学习一下

mark,感谢分享。。。

不错。谢谢楼主

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

fenfenzhong [该话题已被删除] 中提及了此贴 07月29日 16:21

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

fenfenzhong [该话题已被删除] 中提及了此贴 08月02日 15:27

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

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