在使用app过程，尤其是在浏览器内，难免会出现浏览网页的时候出现卡顿的过程，那这类问题怎么分析、定位、解决问题？这时候就需要traceview功能了；
TraceView 是什么？
TraceView 是 Android SDK 中内置的一个工具，它可以加载 trace 文件，用图形的形式展示代码的执行时间、次数及调用栈，便于我们分析。
trace 文件是 log 信息文件的一种，可以通过代码，Android Studio，或者 DDMS 生成。
使用 Android SDK 提供的工具可以生成很多 log 文件，便于我们分析当前应用的内存、布局等状况；
手机卡顿很多时候都是由于某个操作过于耗时，在茫茫代码中查找元凶未免太过痛苦，这时候就该体现 TraceView 的价值了。
生成 trace 文件
生成 trace 文件有三种方法：
使用代码
使用 Android Studio
使用 DDMS
1.使用代码生成 trace 文件
Debug.startMethodTracing("shixintrace");//开始 trace，保存文件到 "/sdcard/shixintrace.trace"// ...Debug.stopMethodTracing();//结束
代码很简单，当你调用开始代码的时候，系统会生产 trace 文件，并且产生追踪数据，当你调用结束代码时，会将追踪数据写入到 trace 文件中。
下一步使用 adb 命令将 trace 文件导出到电脑：
adb pull /sdcard/shixintrace.trace /tmp
使用代码生成 trace 方式的好处是容易控制追踪的开始和结束。
2.使用 Android Studio 生成 trace 文件
Android Studio 内置的 Android Monitor 可以很方便的生成 trace 文件到电脑。
在 CPU 监控的那栏会有一个闹钟似的的按钮，未启动应用时是灰色：
启动应用后，这个按钮会变亮，点击后开始追踪，相当于代码调用 startMethodTracing：
当要结束追踪时再次点击这个按钮，就会生成 trace 文件了。
生成 trace 后 Android Studio 自动加载的 traceview 图形如下：
从这个图可以大概了解一些方法的执行时间、次数以及调用关系，也可以搜索过滤特定的内容。
左上角可以切换不同的线程，这其实也是直接用 Android Studio 查看 trace 文件的缺点：无法直观地对比不同线程的执行时间。
鼠标悬浮到黄色的矩形上，会显示对应方法的开始、结束时间，以及自己占用和调用其他方法占用的时间比例：
3.使用 DDMS 生成 trace 文件
DDMS 即 Dalvik Debug Monitor Server ，是 Android 调试监控工具，它为我们提供了截图，查看 log，查看视图层级，查看内存使用等功能，可以说是如今 Android Studio 中内置的 Android Monitor 的前身。
双击 shift 弹出全局搜索，搜索 “Android Device Monitor”：
或者直接在 设置里设置 Android Device Monitor 的快捷键：
打开 Android Device Monitor，在 DDMS 中打开 trace 文件，DDMS 会启动 TraceView 加载 trace 文件：
或者是在DDMS界面点击右上角带红点的按钮，相当于调用start命令，点击后会有两种模式选择，默认选择第一种，然后进行操作，再次点击后就相当于取消，然后ddms就会打开这个trace文件；
上图介绍了 TraceView 的大致内容：
上半部分显示了 不同线程的执行时间
其中不同的颜色表示不同的方法
同一个颜色越长，说明执行时间越久，如图中的主线程 main
空白表示这个时间段内没有执行内容
下半部分展示了不同方法的执行时间信息，关键指标有三个：
Cpu Time/Call ：该方法平均占用 CPU 的时间
Real Time/Call ：平均执行时间，包括切换、阻塞的时间，>= Cpu Time
Calls + Recur Calls/Total ：调用、递归次数
点击下面的任意一个方法，可以看到它的详细信息：
Parents：选中方法的调用处
Children：选中方法调用的方法
根据 TraceView 显示内容定位问题
定位问题时 TraceView 的使用方式：
从上半部分查看哪些线程执行时间长？什么时候开始执行？与主线程交错时间？
哪些方法的执行需要花费很长时间
点击 TraceView 中的 Cpu Time/Call，按照占用 CPU 时间从高到低排序
哪些方法调用次数非常频繁
点击 TraceView 中的 Calls + Recur Calls/Total ，按照调用次数从高到底排序
排序后，然后逐个排查是否有项目代码或者依赖库代码，有的话点击查看详情，查看是这个方法还是调用的子方法的问题，进一步定位问题。
我们在分析耗时的时候一般有两种情况：
- 1，调用次数不多。但是，本身就非常耗时。
- 2，本身不是很耗时。但是，调用非常频繁。
1，第一种情况，我们可以使用 Cpu Time 来查看它的耗时情况。
2，第二种情况，我们可以使用 Calls+RecurCalls/Total 来查看它的调用情况。
各个参数的意思：
Inl Cpu Time%：方法在运行期间被调用的时间占总时间的百分比。
Incl Cpu Time：方法执行的总时间（包括调用子函数所消耗的时间）：调用该方法每次所需要消耗的时间*执行次数。
Excl Cpu Time%：方法自身所消耗的时间（不包括调用其他方法所消耗的时间）占总时间的百分比。
Excl Cpu Time：方法自身所消耗的时间。
Incl Real Time%：方法真正执行的时间占总时间的百分比。
Incl Real Time：方法真正被执行的时间。
Excl Real Time%：方法真正被执行的时间占总时间的百分比
Excl Real Time：方法真正被执行的所消耗的时间
Calls+RecurCalls/Total：方法被调用的次数+重复调用的次数
Cpu Time/Call：方法每次被执行的时间
Real Time/Call：方法真实被执行的时间