Android性能测试之卡顿ANR测试


一直以来 Android 性能测试一直是 android 测试中一个被一部分人遗忘,有被一部分人无可奈何的东西。在绝大部分的创业公司,性能测试基本上都是被遗忘的,因为功能测试和稳定性测试才是重点,而在中等公司中一部分测试人员向对 Android 进行性能测试,却无从下手。 Android 性能测试一直存在测试维度少,测试数据难收集,已收集数据难量化的特点,这些特点又是因为 Android 手机版本碎片化、硬件多样化、 App 功能复杂造成的。

 

性能测试总的来说,可以分为卡顿 ANR 测试、流畅度测试、电量测试、流量测试。一个 APP 为什么需要性能测试,总的来说就是一些不严谨的代码,在低端机型造成卡顿,对手机上有限电量的浪费,昂贵流量的浪费,造成用户流失。

 

今天先说说卡顿 ANR 测试

 

卡顿 ANR Android 就是天生的朋友,从 Android 第一天诞生直到现在的 8 CPU Android 还是未能摆脱页面不流畅,卡,死机的诟病,所以个人认为卡顿 ANR 测试是性能测试最主要的一块。

 

卡顿简单的来说,就是手机没有及时响应、页面延迟,出现丢帧的现象,或者点击无响应。绝大多数的卡顿,稍等片刻系统就会恢复正常,但假如超过 5S, 就可能会引发手机 ANR, 造成更高级别的警告。

 

什么会引发 ANR

 

Android 里,应用程序的响应性是由 Activity Manager WindowManager 系统服务监视的 。当它监测到以下情况中的一个时, Android 就会针对特定的应用程序显示 ANR

ANR 一般有三种类型:

 

1 KeyDispatchTimeout(5 seconds) -- 主要类型按键或触摸事件在特定时间内无响应

2 BroadcastTimeout(10 seconds) --BroadcastReceiver 在特定时间内无法处理完成

3 ServiceTimeout(20 seconds) -- 小概率类型 Service 在特定的时间内无法处理完成

 

这三种原因都会造成 ANR ,但是第一种情况基本上占了所有 ANR 的百分之九十以上,第三种的情况微乎其微。这三种 ANR 不是孤立的,有可能会相互影响。例如一个应用程序进程中同时有一个正在显示的 Activity 和一个正在处理消息的 BroadcastReceiver ,它们都运行在这个进程的主线程中。如果 BR onReceive 函数没有返回,此时用户点击屏幕,而 onReceive 超过 5 秒仍然没有返回,主线程无法处理用户输入事件,就会引起第 1 ANR 。如果继续超过 10 秒没有返回,又会引起第 2 ANR 。发生 ANR 的主要原因是潜在的耗时操作,例如网络或数据库操作,或者高耗时的计算如改变位图尺寸,应该在子线程里(或者以数据库操作为例,通过异步请求的方式)来完成。然而,不是说你的主线程阻塞在那里等待子线程的完成——也不是调用 Thread.wait() 或是 Thread.sleep() 。替代的方法是,主线程应该为子线程提供一个 Handler ,以便完成时能够提交给主线程。以这种方式设计你的应用程序,将能保证你的主线程保持对输入的响应性并能避免由于 5 秒输入事件的超时引发的 ANR 对话框。

 

三种 ANR 发生时都会在 log 中输出错误信息,你会发现各个应用进程和系统进程的函数堆栈信息都输出到了一个 /data/anr/traces.txt 的文件中, ROOT 手机导出该文件后,分析此日志可以得出一些结论,但 traces 文件信息比较抽象,难理解。总的来说,日志难收集,结果难分析。

 

如何避免 ANR

 

1 运行在主线程里的任何方法都尽可能少做事情。特别是, Activity 应该在它的关键生命周期方法(如 onCreate() onResume() )里尽可能少的去做创建操作。(可以采用重新开启子线程的方式,然后使用 Handler+Message 的方式做一些操作,比如更新主线程中的 ui 等)

 

2 应用程序应该避免在 BroadcastReceiver 里做耗时的操作或计算。但不再是在子线程里做这些任务(因为 BroadcastReceiver 的生命周期短),替代的是,如果响应 Intent 广播需要执行一个耗时的动作的话,应用程序应该启动一个 Service 。(此处需要注意的是可以在广播接受者中启动 Service ,但是却不可以在 Service 中启动 broadcasereciver, 关于原因后续会有介绍,此处不是本文重点)

 

3 )避免在 Intent Receiver 里启动一个 Activity ,因为它会创建一个新的画面,并从当前用户正在运行的程序上抢夺焦点。如果你的应用程序在响应 Intent 广 播时需要向用户展示什么,你应该使用 Notification Manager 来实现。

 

TestBird

全部评论
额,到最后也没有说一个实现,我最近在360也在做卡顿和耗电量方面的分析测试,卡顿方面主要是靠Choreographer的doFrame接口实现,这个接口可以测到两帧间的耗时,一般超过16ms*2~3的时间就可以统计下来算为卡顿,耗电量方面主要是读取Linux下一个cpu_freq文件,他记录了cpu各个频率的时间,再加上具体转换计算就可以得出耗电量。
点赞 回复 分享
发布于 2017-07-13 18:33

相关推荐

04-11 21:31
四川大学 Java
野猪不是猪🐗:(ja)va学弟这招太狠了
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客企业服务