导言
上一篇描述了通过Systrace分析绘制的问题，里面也有提到过，某一帧绘制过久，那么这可能是代码等地方有问题，具体分析代码问题，这时候就轮到TraceView发挥作用了
基础
TraceView有两种使用模式：
1.可以在DDMS里面手动开启，然后再手动停止，然后生成的trace默认为这段时间内的记录，常用于在不确定具体卡顿代码的情况下
2.可以在代码中指定开始和结束
Debug.startMethodTracing("test");
...
Debug.stopMethodTracing();
常用于分析指定代码或者具体操作
面板分析
看一下重点指标就可以了
Cpu Time：实际执行的时间（不包括线程被挂起的等待时间）
Real Time：执行的总时长（Cpu Time+等待的时间）
Calls+RecurCalls：函数执行的总次数（包括递归执行）
简单的分析方法就是考虑一个函数的执行次数和单次执行时间，执行次数过多的话要考虑是不是有过度调用或者递归的问题，执行时间过长的话要考虑进行优化操作
调用链分析
可以通过选择具体的某个函数来看到该函数下面调用的其余函数的具体耗时，从而链式的向下分析
从图中可以看出，当前函数内部的三个函数基本上瓜分了执行时间，那么后续就可以对这三个函数继续进行调用链分析，分析的目的是在最后能够对执行时间进行优化。
举例说明
这里通过代码中指定的方式来观察一个网络请求的开始到结束
我们这里就简单观察一下数据解析，因为返回数据都是为JSON串，统一都需要转换为对象处理，这时候转换的速度也就是我们关心的指标，这里对比一下Gson和FastJson的情况，对象统一不采用注解，仅仅是提供一致的字段名及对应的get/set方法
从结果上面很直观的看出来FastJson的解析效率高一些，从追求性能的方向上面考虑可能使用FastJson会相对好一些。
同时也要注意到Json解析是一个相对耗时的操作，应当尽可能的放入到工作线程中处理而不是阻塞主线程，毕竟480ms已经相当于30帧左右的时间了
总结
TraceView常用于分析方法的具体执行时间，可以作为一种常用的调优手段。
当然常规的使用模式应该是先通过Systrace来发现UI卡顿问题，然后再使用TraceView进行细化分析，这样配合会更加的合适
文章系列：
基本的优化总结（一）
基本的优化总结（二）
基本的优化总结（三）
基本的优化总结（四）
基本的优化总结（五）
基本的优化总结（六）
