记录一次使用 Android Profiler分析CPU耗时操作

  • Post author:
  • Post category:其他



版权声明:本文章原创于 RamboPan ,未经允许,请勿转载。



记录一次使用 Android Profiler 分析内存

最近一个老项目需要更新,就想着把之前搜集的一些小问题一起修复了,然后测试了下,发现了一个情况,就是在查看历史数据模块的时候,进入比进入其他模块时间稍微长一点,想着优化下。

在这里插入图片描述

点击可能有点暗,


gif


上看不出来,我点击的时候水波触发暂停,还是能感觉间隔有点长。

看代码前怀疑是不是读数据库时有点缓慢,在代码中加入日志观察,发现读数据库并不缓慢,在大量代码中如何快速查找可能耗时的部分呢,想到了之前

AS



Profiler

可以查看内存的情况,当时也有一些其他参数,甚至在 8.0 上的系统也支持电量查看,那么此时我们就可以试试这个好用不。



一般会自动出现在常用的工具栏附近,可以看到是一个类似仪表指针的图标,没有的话,可以在上方菜单栏中查找。

点击之后将程序跑起来,下方菜单栏会出现

Profier

对话框,依次是

CPU



Memory



Network



Energy

,显示需要查看的几个选项,这里我们选择

CPU


在这里插入图片描述

在这里插入图片描述

这里会显示线程有关的,但是我们重点不是观察线程,是查看点击之后进行了哪些操作导致时间花费比较高,所以等程序进入主界面一会后,

CPU

慢慢稳定之后,点击

Record

,再点击我们要测试的模块,进入模块之后再点击一次

Record

位置(此时显示为

Stop

),那么就会得出一段分析的区间。

在这里插入图片描述
在这里插入图片描述

可以看到这种时间段,从上到下依次是调用的方法以及层级关系。

  • 橙色部分是

    Android

    系统的方法。
  • 蓝色部分是

    Java

    的方法。
  • 绿色部分是我们的代码。

比如沿着左边的分支可以看到显示

Android

的方法调用,触发了

java.lang.reflect.Method.invoke

,再回到

Android

的代码调用最后走到我们的代码,因为

getLocalDate

中涉及一些数据处理,实现部分也是

Android



Java

的代码,所以最后末端变成橙色和蓝色的时间小块。

在这里插入图片描述

我们重点观察是图中绿色部分,特别是整块的绿色。图中能看到的有我们类的 onCreate 方法,中间一整块部分下方也有我们的方法,只是此处没有截取到。

图中的包名部分因为显示区间太小,所以没有完全显示出来,这里可以滑动滚轮将时间精度放大,也可以把鼠标移上去可以看到显示的,那我们先来找一找这个方法有没有。

在这里插入图片描述

可以看到确实是能找到我们对应的方法,但是检查了下这里面代码,里面时间优化的空间不大,那我们看有没有其他大的耗时部分,我们把界面往下拉一下。

在这里插入图片描述

可以看到这里有几个词语反复出现,感觉真相可能在这,我们放大来看一看。

在这里插入图片描述

移到对应的时间块上可以显示出时间,此时的缩放比例,我标出了一个图中方块的单位是


50ms


,可以发现中间有很多重复的调用,每个都是


50ms


左右或者更长,我看大概算了这几个绿色部分花了


1 .1


秒(流下了心痛的泪水),看来就是真凶没错,那我们按着这些方法来看一下问题出在哪了。

在这里插入图片描述

按着上图的指示,我们来查找这五个方法。首先是

instantiateItem

,再是

applyDataToView



在这里插入图片描述

接下来找剩下三个方法。

在这里插入图片描述

查看三处的代码。

在这里插入图片描述

在这里插入图片描述

可以看到一个共同的特点,都是在实现获得一个时间戳的字符串形式或者其中的部分。

先不说是否耗时,就逻辑上来说:如果需要反复用,在类里面加一个字符串的时间戳变量就行了,在保存

long

类型时间时,同时解出一个

String

类型的时间戳保存下来。

这还不是最气的,打开

DateUtils.dateToString()

这个方法。

在这里插入图片描述

这 …… 既然做成了静态的工具类,直接存一个静态的变量呀 …… 前人挖坑,后人踩坑。🙃


更详细的使用可以参考以下的链接 (需要科学上网)。



版权声明:本文为u014443348原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。