1.traceview使用
Debug.startMethodTracing("myapp")//startMethodTracing有好几个重载方法
Debug.stopMethodTracing()
运行之后可以在目录下生成文件：内部存储/android/data/cpm.example.myapplication/files/myapp.trace
使用android studio profiler打开trace文件，Android官网有详细的profiler文件使用介绍：https://developer.android.com/studio/profile/cpu-profiler
接下来一起来分析Trace文件：
Wall Clock time是线程真正执行的时间，比如我们测试一个方法执行了100ms，从Wall Clock time上看就是100ms
Thread time上所看到的时间是指CPU执行的时间，时间只会比100ms少，使用Thread Time可以让您更好地了解线程的实际 CPU 使用率中有多少是给定方法或函数消耗的。还可以在方法上右键点击jump to source。实际优化过程中重点关注的就是Thread time，例如发生了死锁，整个wall clock time的时间是很长的，但是Thread time时间反应出来的才是真实在方法上所消耗的时间。
Threads(12)表示的是线程的总数，trace可以查看十二个线程，main是我们的主线程，我们可以点任意一个线程查看做了什么。
Call Chart最上面表示总时间，垂直向下依次为被调用方法的时间。其中，对于系统Api显示的是黄色，被应用调用的方法是绿色的，第三方api(java sdk也属于第三方)的颜色就是蓝色
Flame Chart火焰图主要的作用是收集调用方法的时间，比如多次调用LayoutInflate.inflate，Flame Chart会把他们都收集到一起。
Top Down就是函数的调用列表，可以依次从上往下查看调用列表。Total显示的是总调用时间，self显示的是自身执行的时间，children显示的是子方法被调用的时间。
Bottom Up和Top Down是相反的，可以依次从下往上查看调用方。
traceview有以下几点需要注意：
1.运行时开销严重，整体变慢。因为trace会收集程序运行时所有方法的耗时情况，因此会拖累整体速度。
2.有了cpu profiler为什么还要用traceview？因为traceview可以埋点，cpu profiler不能埋点，我们可以结合二者的优势使用。traceview埋点，cpu profiler分析
2. Systrace
查看官方教程
要运行 systrace，请完成以下步骤：
- 从 Android Studio 下载并安装最新的 Android SDK Tools。
- 安装 Python (v2.7)并将其添加到工作站的执行路径中。
- 使用 USB 调试连接将搭载 Android 4.3（API 级别 18）或更高版本的设备连接到开发系统。然后在Acticvity中使用Trace，但是因为只支持API 18以上，所以推荐我们使用TraceCompat，向下兼容。
TraceCompat.beginSection("start");
TraceCompat.endSection();
4.systrace 命令在 Android SDK Tools 工具包中提供，位于android-sdk/platform-tools/systrace/，参照文档使用命令：
python systrace.py -t 10 [other-options] [categories]
例如，以下命令会调用 systrace 来记录设备活动并生成一个名为 mynewtrace.html 的 HTML 报告。此类别列表是大多数设备的合理默认列表。
$ python systrace.py -o mynewtrace.html sched freq idle am wm gfx view binder_driver hal dalvik camera input res
5.在android-sdk/platform-tools/systrace/下生成mynewtrace.html文件，打开如下所示：
可以使用快捷键快速阅读该文件，常用快捷键说明如下所示：
W: 放大横轴，用于查看耗时方法细节；
S: 缩小横轴，用于查看整体情况；
A: 将面板左移；
D: 将面板右移；
M: 高亮某一段耗时内容。
从图中看出CPU核心数、进程信息、Surfaceflinger等信息。我们可以从进程中的frames去分析是否有卡顿存在，
每一个F代表着一帧，红色的F表示丢帧，android的display的时间大约是16.6ms，因此超过此时间的在我们看来都是卡顿现象也就是丢帧。按下M选择红色F如下高亮部分所示，可以看出绘制时间为201.192ms，这是远远超出16.6ms绘制时间的。
通过分析选中部分调用方法的细节以及结合Frames下的Description去分析掉帧的方法。
想要深入了解systrace的还可以查看这篇文章
总结
Trace和Profiler相比，Trace可以进行埋点，精确的计算app启动所消耗的时间，Profiler虽然是最新的工具，但是无法做到所有界面都精确计时。可以使用Trace进行埋点生成文件，再使用Profiler对Trace文件进行卡顿分析。
分析卡顿的一般步骤如下所示：
1.在app内找到卡顿的场景，并抓取卡顿发生时的文件；
2.找到发生问题的应用进程的主线程，找到发生问题的问题帧；
3.通过profiler或者systrace中frames红色高亮部分去判断具体耗时情况。
