Andorid性能优化之traceview的使用（不懂揍我）

1、traceview的使用方式有2种方式

这2种方式能够根据场景，去选择哪种方式。最终效果是同样的

• 经过手动埋点
• Profile

1.一、经过手动埋点。

步骤1: 好比咱们知道在点击一个按钮的时候，会有卡顿，那么就能够用

//能够用如下代码测试你的代码。
//开始埋点，“app”是最后生成的性能分析文件
Debug.startMethodTracing("App");

//埋点结束，期间start 到 stop 之间的代码，就是你要测试的代码范围
Debug.stopMethodTracing();
复制代码

步骤2: 运行完测试代码后，咱们点开studio右下角的Device Explorer，在下图的“第一步”，打开以后咱们要找到咱们生成的trace文件，路径在sdcard/Android/data/项目包名/files,如图：

步骤3： 直接左键双击能够打开咱们的文件如图：

部分1：是时间选择范围，整段就是咱们刚刚用代码埋点指定的。上面的时间标志是时间戳。
部分2：表示当前埋点的代码有5个线程。能够点击任何一个线程查看
部分3：这里有4个按钮

• Call Chart
• Flame Chart
• Top Down
• Bottom Up

接下来咱们具体看看这四个按钮

1.1.一、Top Down

点开咱们的Top Down，以下：

红色框1： 表示main里的一些状况。

• Total：表示main函数全部执行须要的时间
• Self: 表示main函数里，除了调用别的函数方法外，本身方法内代码的执行时间
• Children: 表示mian函数里，调用别的函数所执行的时间
  
  

红色框2： 里面有2个选项，能够切换成Wall Clock Time或者Thread Time

• Wall Clock Time：指这个线程真正的执行时间，好比消耗了100ms就是消耗了100ms
• Thread Time：CPU的执行时间，比Wall Clock Time少。

为何这两个时间会不同？举个不恰当的比喻，好比运行一个方法，由于锁的缘由，线程等待。这个时候等待时间也算在了Wall Clock Time里。 可是Thread Time是CPU的执行时间，线程闲置的时候并无消耗CPU，固然这个等待时间也就不算在Thread Time里了。

红色框3： 表示方法的依次调用。及每一个子方法调用所消耗的时间。这里也能够当作是Call Chart表的“代码化”。

1.1.二、Call Chart

点开Call Chart以下：

这里注意要注意几点：

• 这里的图标表示，好比2个方法A和B。方法A调用方法B，那么方法A就在方法B的上方。
• 橙色：表示系统API方法调用
• 绿色：表示自身方法调用
• 蓝色：表示第三方调用

1.1.三、Flame Chart

点开Flame Chart后，以下:

这里的意思是会把类似或相同的方法统计在一块儿，好比A方法调用B方法调用C方法：A->B->C,那么他会将全部按此顺序的方法收集在一块儿，或者将A->B->D也会收集在上，横轴表示的是相对时间。

1.1.四、Bottom Up

点开Bottom Up以下

这里点开initX5web() -> 显示了main();也就是说谁调用了我。main()方法里调用initX5web();

1.二、经过Andorid studio 的Profile

点击Profile运行项目

运行后以下图：

鼠标移动到CPU那里后，左键双击CPU后，如图:

能够看到，这里和咱们上面用代码埋点界面几乎相同了，这里有个按钮，Record,点击后，文案会变成stop;咱们就能够在APP里操做，来到咱们以为卡顿或者有问题的功能里。点击stop就造成了咱们trace同样的文件里。里面的操做都是同样的

2、咱们来举个小例子，来解决一项卡顿

拿之前作的一个项目举例，为了避免被骚扰，这里我隐藏了手机号。看看下面的gif,这里我在输入密码后，点击登陆，在网络请求结束后，dialog已经消失了，尚未跳转到咱们的首页，如图，此时有明显的卡顿

在咱们logcat里过滤关键字：Displayed 能够看到咱们程序中每一个Activity的启动时间，此时个人启动时间是996，接近1s（fuck,这样都有996，擦）：

这个时候咱们用第二种方式去尝试解决这个卡顿，根据咱们的Top Down分析，根绝Total的耗时时间，咱们一直往下点，首先来到以下（假设咱们还不知道是跳转Activity卡顿）：

这时候到了2个方法，dispatchMessage()和next();
咱们先将dispatchMessage点到底，看到了setContentView()里的loadDrawable()。能够看到这个是元凶

将next()点到底，如图，在nativePollOnce(),后子方法里，没有耗时项，根据方法名也能猜想到，这是系统方法。

由上面的分析，最终问题定在了setContentView()里的loadDrawable()。也就是说明咱们MainActivity的layout里，不论是src仍是background,有一个很是耗时的bitmap。这里我照下来以后，确实发现了根布局的background里背景大图，我这里直接取消这张图后，运行程序，以下，能够发现再也不卡顿了，并且跳转速度大大提高了：

打印下时间，启动时间由原来的996，变成了447：

这里我只是举了个小例子，但愿对学习性能优化的朋友有帮助。若是以为有用，就赞一个吧！！