启动优化工具systrace

1、

2、

3、

4、

 

5、

phython脚本：

参数：-b：buffer，要收集多少。比如traceview默认大小是8M，sytemtrace也可以限制大小

-t：是时间的一个概念

-a：要监测的包名

-o：生成的文件名

6、

在程序中生成的文件

7、

双击查看该文件

8、

Kemel:说明CPU是八核的

而且有的cpu不是一直都执行，所以说它不是一直都是八核的，这种情况也很普遍，有的手机厂商默认八核都给你，有的手机厂商默认情况下只给四核。下面四个核大量运行的时候，前面四个核是在闲着的

9、

线程名称

10、

ApponCreate()总共耗时515毫秒

11、

也可以在搜索框进行搜索，0 of 1，表明只有一个tag

12、

下面是详细信息

title是Apponcreate

Wall time是多少，CPU time是多少。针对每段代码，要关注两个值。一个是Wall Duration，一个是CPU Duration，两者之差可能会比较大。如下图，这段代码虽然执行了515毫秒，但是CPU真正执行这段代码的时间是175毫秒，这就是说其它情况下，cpu都是处于休息状态。

13、

点击一下，并且点击一下M键，点击箭头，然后再点击M键，会告诉你在这个方法上花了多长时间

可以看到很多时间片，所以cpu其实并不满的

14、

systrace开销小，你埋在哪个点，它就统计哪个点。traceview你埋在主线程，其它线程它也会一起统计出来。

systrace可以很直观地看出cpu的利用率。如果cpu的利用率比较低，则想办法提高cpu的利用率

 

15、

walltime并不是优化的方向，cputime才是，是cpu真正花在你身上的时间是多少。如果有些任务不需要cpu的参与，那么可以使用其它的办法，比如多开一些线程之类的操作，因为不消化cpu

为什么会出现cputime和walltime不一样的情况呢？比如说，优先调用了A方法，然后需要拿一把锁，但是此时此刻这把锁被别人持有着，也就是说导致代码在A这个地方停下来了。但实际上A函数可能非常非常不耗时，只需要拿一下锁做一下轻量级的事情，然后就退出。因为拿不到锁，所以一直在等待，所以导致walltime的时间很长，但是对cpu没有消耗。这就导致了cpu time和wall time是不一样的。

16、

17、