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