Android 性能检测工具

trace文件

trace.txt是系统用于保存ANR Log的文件，通过这个文件可以找到系统检测到的ANR的应用。

ANR的定义

在Android上，如果你的应用程序有一段时间响应不够灵敏，系统会向用户显示一个对话框，这个对话框称作应用程序无响应（ANR：Application Not Responding）对话框。用户可以选择“等待”而让程序继续运行，也可以选择“强制关闭”。所以一个流畅的合理的应用程序中不能出现anr，而让用户每次都要处理这个对话框。因此，在程序里对响应性能的设计很重要，这样系统不会显示ANR给用户。

ANR的类型

• KeyDispatchTimeout(5 seconds) —-主要类型
  按键或触摸事件在特定时间内无响应
• BroadcastTimeout(10 seconds)
  BroadcastReceiver在特定时间内无法处理完成
• ServiceTimeout(20 seconds) —-小概率类型
  Service在特定的时间内无法处理完成

KeyDispatchTimeout超时原因

（1）当前的事件没有机会得到处理（即UI线程正在处理前一个事件，没有及时的完成或者looper被某种原因阻塞住了）
（2）当前的事件正在处理，但没有及时完成

如何避免KeyDispatchTimeout

（1）UI线程尽量只做跟UI相关的工作
（2）耗时的工作（比如数据库操作，I/O，连接网络或者别的有可能阻碍UI线程的操作）把它放入单独的线程处理
（3）尽量用Handler来处理UIthread和别的thread之间的交互

UI线程

首先要知道事件发生的线程，一般来说大多数可能是UI线程操作超时，那么UI线程都有哪些呢：
(1). Activity 生命周期
(2). View post 的runnable方法 、 handler（MainLooper） 的 handleMessage()
(3). Asycktask 的 onPreExecute(), onPostExecute() , onProgressUpdate()方法
(4). Broadcast 的onReceive()
(5). Service

其他原因造成的anr

(1). 线程死锁
(2). cpu 饥饿

如何去分析ANR

我们写一个主线程阻塞的demo：

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        doANR();
    }

    private void doANR() {
        try {
            Thread.sleep(60000); //阻塞
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

出现Application Not Responding的提示后，系统会将日志LOG写到到data\anr\traces.txt文件，将手机上的traces.txt导出到电脑的d目录下：

adb pull /data/anr/traces.txt d:/

Log中定位ANR信息：

"main" prio=5 tid=1 Sleeping
  | group="main" sCount=1 dsCount=0 obj=0x7523f450 self=0x55a8df6b20
  | sysTid=10299 nice=-1 cgrp=top_visible sched=0/0 handle=0x7f97788fd0
  | state=S schedstat=( 958207562 23237861 227 ) utm=65 stm=30 core=0 HZ=100
  | stack=0x7fef1d1000-0x7fef1d3000 stackSize=8MB
  | held mutexes=
  at java.lang.Thread.sleep!(Native method)
  - sleeping on <0x04746b7d> (a java.lang.Object)
  at java.lang.Thread.sleep(Thread.java:1046)
  - locked <0x04746b7d> (a java.lang.Object)
  at java.lang.Thread.sleep(Thread.java:1000)
  at com.hx.tools.MainActivity.doANR(MainActivity.java:17) /**就是这里**/
  at com.hx.tools.MainActivity.onCreate(MainActivity.java:12)
  at android.app.Activity.performCreate(Activity.java:6367)
  at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1110)
  at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2404)
  at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2511)
  at android.app.ActivityThread.access$900(ActivityThread.java:165)
  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1375)
  at android.os.Handler.dispatchMessage(Handler.java:102)
  at android.os.Looper.loop(Looper.java:150)
  at android.app.ActivityThread.main(ActivityThread.java:5621)
  at java.lang.reflect.Method.invoke!(Native method)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:794)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:684)

其他关于死锁以及cpu饥饿的Log分析可以参考Android ANR 分析学习总结。

TraceView

TraceView 是 Android SDK 中内置的一个工具，它可以加载 trace 文件，用图形的形式展示代码的执行时间、次数及调用栈，便于我们分析。
通过TraceView，可以得到以下两种数据：

• 单次执行最耗时的方法
• 执行次数最多的方法

trace 文件是 log 信息文件的一种，生成 trace 文件有三种方法：

• 使用代码
• 使用 Android Studio
• 使用 DDMS

代码生成 trace文件

/**开始 trace，保存文件到 "/sdcard/mytrace.trace" */
Debug.startMethodTracing("mytrace"); 
... 
//结束
Debug.stopMethodTracing(); 

代码很简单，当你调用开始代码的时候，系统会生产 trace 文件，并且产生追踪数据，当你调用结束代码时，会将追踪数据写入到 trace 文件中，6.0以上系统请自己完成运行时权限。使用代码生成 trace 方式的好处是容易控制追踪的开始和结束，缺点就是步骤稍微多了一点。

本地的trace文件我们就可以使用SDK下的TraceView或DDMS来直接打开分析了。

Android Studio 生成 trace 文件

Android Studio 内置的 Android Monitor 可以很方便的生成 trace 文件到电脑。
在 CPU 监控的那栏会有一个闹钟似的的按钮，未启动应用时是灰色：

启动应用后，这个按钮会变亮，点击后开始追踪，相当于代码调用 startMethodTracing：

当要结束追踪时再次点击这个按钮，就会生成 trace 文件了。
生成 trace 后 Android Studio 自动加载的 traceview 图形如下：

从这个图可以大概了解一些方法的执行时间、次数以及调用关系，也可以搜索过滤特定的内容。

左上角可以切换不同的线程，这其实也是直接用 Android Studio 查看 trace 文件的缺点：无法直观地对比不同线程的执行时间。

鼠标悬浮到黄色的矩形上，会显示对应方法的开始、结束时间，以及自己占用和调用其他方法占用的时间比例：

DDMS 生成 trace 文件

DDMS 即 Dalvik Debug Monitor Server ，是 Android 调试监控工具，它为我们提供了截图，查看 log，查看视图层级，查看内存使用等功能，可以说是如今 Android Studio 中内置的 Android Monitor 的前身。

从Android Studio中启动android Device Monitor： Tools -> Android -> Android Device Monitor.
选择你要调试的进程—>点击start mothod profiling—>选择sample base profiling—>…—>stop mothod profiling

开启方法分析后对应用的目标页面进行测试操作，测试完毕后停止方法分析，界面会跳转到 DDMS 的 trace 分析界面，下面会分析。操作最好不要超过5s，因为最好是进行小范围的性能测试。

TraceView界面

下面我的分析是针对DDMS抓取的trace文件。

TraceView 界面比较复杂，其 UI 划分为上下两个面板，即 Timeline Panel（时间线面板）和 Profile Panel（分析面板）。上图中的上半部分为 Timeline Panel（时间线面板），Timeline Panel 又可细分为左右两个 Pane：

• 左边 Pane 显示的是测试数据中所采集的线程信息。由图可知，本次测试数据采集了 main 线程，监视线程和其它网络操作线程的信息。
• 右边 Pane 所示为时间线，时间线上是每个线程测试时间段内所涉及的函数调用信息。这些信息包括函数名、函数执行时间等。由图可知，main 线程对应行的的内容非常丰富，而其他线程在这段时间内干得工作则要少得多。
• 另外，开发者可以在时间线 Pane 中移动时间线纵轴。纵轴上边将显示当前时间点中某线程正在执行的函数信息。

上图中的下半部分为 Profile Panel（分析面板），Profile Panel 是 TraceView 的核心界面，其内容非常丰富。它主要展示了某个线程（先在 Timeline Panel 中选择线程）中各个函数调用的情况，包括 CPU 使用时间、调用次数等信息。而这些信息正是查找 hotspot 的关键依据。所以，对开发者而言，一定要了解 Profile Panel 中各列的含义。下表列出了 Profile Panel 中比较重要的列名及其描述。

关键指标有三个：

• Cpu Time/Call ：该方法平均占用 CPU 的时间
• Real Time/Call ：平均执行时间，包括切换、阻塞的时间，>= Cpu Time
• Calls + Recur Calls/Total ：调用、递归次数

Profile Panel界面下方表格中纵轴就是每个方法，包括了JDK的，Android SDK的，也有native方法的，当然最重要的就是app中你自己写的方法，有些Android系统的方法执行时间很长，那么有很大的可能就是你app中调用这些方法过多导致的。

每个方法前面都有一个数字，是全部方法按照Incl CPU Time 时间的排序序号。点一个方法后可以看到有两部分，一个是Parents，另一个是Children。

• Parent表示调用这个方法的方法，可以叫做父方法
• Children表示这个方法中调用的其他方法，可以叫做子方法

根据 TraceView 定位问题

定位问题时 TraceView 的使用方式：

• 从上半部分查看哪些线程执行时间长？什么时候开始执行？与主线程交错时间？
• 哪些方法的执行需要花费很长时间
  点击 TraceView 中的 Cpu Time/Call，按照占用 CPU 时间从高到低排序
• 哪些方法调用次数非常频繁
  点击 TraceView 中的 Calls + Recur Calls/Total ，按照调用次数从高到底排序，排序后，然后逐个排查是否有项目代码或者依赖库代码，有的话点击查看详情，查看是这个方法还是调用的子方法的问题，进一步定位问题。

我这里写了一个循环打印的例子：

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        doLoop();
    }

    private void doLoop() {
        for (int i = 0; i < 100000; i++) {
            showLog(i);
        }
    }

    private void showLog(int i) {
        Log.v("hx", "i="+i);
    }
}

按照Cpu Time/Call大小排序：

按照Calls + Recur Calls/Total大小排序：

都能很快的定位到出错函数。