正确使用Android性能分析工具——TraceView

Android性能分析工具之TraceView的使用 通过TraceView,开发人员可以记录应用程序的性能数据,并可视化为方法调用树,从而帮助找出性能问题和优化方向。通过观察生成的方法调用树,你可以看到每个方法的执行时间和调用关系,从而找到性能瓶颈和优化的方向。TraceView是Android平台上的一款性能分析工具,它可以帮助开发人员分析应用程序的性能瓶颈,并找出其中的性能问题。本文将介绍TraceView的基本用法,并提供相应的源代码示例。在性能分析工具中,选择"CPU"选项卡,并点击"Start Profiling"按钮开始记录应用程序的性能数据。 阅读详情

前面唠叨

最近公司app中有些列表在滑动的时候会有卡顿现象,我就开始着手解决这些问题,解决问题之前首先要分析列表滑动的性能瓶颈在什么地方。因为之前不会正确使用TraceView这个工具,主要是看不懂TraceView界面下方数据指标的值代表什么意思…以前我用StopWatch类来分析性能,现在觉得弱爆了…不过有些地方StopWatch工具类还是很简单好用的~

网上可以找了很多博客来介绍这个工具的使用方法,很多都是讲解了一些一些就会的方法,讲一个大概,包括StackOverFlow上我也没有找到很好的讲解TraceView各个数据指标代码什么意思的回答

因为我要解决列表滑动的卡顿问题,就必须要找到导致卡顿现象的原因,我就在StackOverFlow上找着别人零散的回答慢慢琢磨这个工具的使用方法。现在我学会了,至少能看懂每个指标什么意思,最后发现这个工具实在太强大了!!!

TraceView界面

现来看一下整个界面的图,整个界面包括上下两部分,上面是你测试的进程中每个线程的执行情况,每个线程占一行;下面是每个方法执行的各个指标的值

上面一部分是你测试进程的中每个线程运行的时间线,下图中可以可以看到,主要只有一个main线程在执行,因为我滑动了一下列表,main线程(UI线程)正在进行绘制View呢~~

然后我点击了序号为133的一个方法io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView,就会出现两部分数据:

  • Parents
  • Children

Parents表示调用133这个方法的父方法,可以看到序号为130。Children表示方法133调用的其他方法,可以看到有好几个方法。

main

如何使用TraceView

因为这次我主要是分析列表滑动卡顿问题,我就讲讲我是怎么使用这个工具的,并且我是怎么分析的。

使用TraceView主要有两种方式:

  1. 最简单的方式就是直接打开DDMS,选择一个进程,然后按上面的“Start Method Profiling”按钮,等红色小点变成黑色以后就表示TraceView已经开始工作了。然后我就可以滑动一下列表(现在手机上的操作肯定会很卡,因为Android系统在检测Dalvik虚拟机中每个Java方法的调用,这是我猜测的)。操作最好不要超过5s,因为最好是进行小范围的性能测试。然后再按一下刚才按的按钮,等一会就会出现上面这幅图,然后就可以开始分析了。

  2. 第2种方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法,当运行了这段代码的时候,就会有一个trace文件在/sdcard目录中生成,也可以调用startMethodTracing(String traceName) 设置trace文件的文件名,最后你可以使用adb pull /sdcard/test.trace /tmp 命令将trace文件复制到你的电脑中,然后用DDMS工具打开就会出现第一幅图了

第一种方式相对来说是一种简单,但是测试的范围很宽泛,第二中方式相对来说精确一点,不过我个人喜欢使用第一种,因为简单,而且它是检测你的某一个操作。因为第二中更适合检测某一个方法的性能,其实也没有那种好,看使用的场景和喜好了。。。

看懂TraceView中的指标

指标

其实我今年7月份就已经开始使用TraceView工具了,但是当时不懂其中每个指标的含义,就没注意到它强大的地方。看不懂界面下方表格中的指标,这些数据其实一点意义都没有。

网上包括Android官网也没有对TraceView工具的使用有详细的说明文档,这点确实比较蛋疼。

###纵轴
TraceView界面下方表格中纵轴就是每个方法,包括了JDK的,Android SDK的,也有native方法的,当然最重要的就是app中你自己写的方法,有些Android系统的方法执行时间很长,那么有很大的可能就是你app中调用这些方法过多导致的。

每个方法前面都有一个数字,可能是全部方法按照Incl CPU Time 时间的排序序号(后面会讲到)

点一个方法后可以看到有两部分,一个是Parents,另一个是Children。

  • Parent表示调用这个方法的方法,可以叫做父方法

  • Children表示这个方法中调用的其他方法,可以叫做子方法

横轴

incl time

横轴上是很多指标,这些指标表示什么意思真的困扰了我很长一段时间。。。

能够很衡量一个方法性能的指标应该只有时间了吧? 一个方法肯定就是执行时间越短约好咯~~

1. Incl Cpu Time

define inclusive : 全包括的

上图中可以看到0(toplevel) 的Incl Cpu Time 占了100%的时间,这个不是说100%的时间都是它在执行,请看下面代码:

public void top() {
    a();
    b();
    c();
    d();
}

Incl Cpu Time表示方法top执行的总时间,假如说方法top的执行时间为10ms,方法a执行了1ms,方法b执行了2ms,方法c执行了3ms,方法d执行了4ms(这里是为了举个栗子,实际情况中方法a、b、c、d的执行总时间肯定比方法top的执行总时间要小一点)。

而且调用方法top的方法的执行时间是100ms,那么:

  Incl Cpu Time
top 10%
 a10%
 b20%
 c30%
 d40%

从上面图中可以看到:
toplevel的 Incl Cpu Time 是1110.943,而io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView方法的Incl Cpu Time为12.859,说明后者的Incl Cpu Time % 约为1.2%

这个指标表示 这个方法以及这个方法的子方法(比如top方法中的a、b、c、d方法)一共执行的时间

2. Excl Cpu Time

理解了Incl Cpu Time以后就可以很好理解Excl Cpu Time了,还是上面top方法的栗子:

方法top 的 Incl Cpu Time 减去 方法a、b、c、d的Incl Cpu Time 的时间就是方法top的Excl Cpu Time 了

3. Incl Real Time

这个感觉和Incl Cpu Time 差不多,第7条会讲到。

4. Excl Real Time

同上

5. Calls + Recur Calls / Total

这个指标非常重要!

它表示这个方法执行的次数,这个指标中有两个值,一个Call表示这个方法调用的次数,Recur Call表示递归调用次数,看下图:

Recur

我选中了一个方法,可以看到这个方法的Calls + Recur Calls 值是14 + 0,表示这个方法调用了14次,但是没有递归调用

从Children这一块来看,很多方法调用都是13的倍数,说明父方法中有一个判断,但是这不是重点,有些Child方法调用Calls为26,这说明了这些方法被调用了两遍,是不是可能存在重复调用的情况?这些都是可能可以优化性能的地方。

6. Cpu Time / Call

重点来了!!!!!!!!!!

cpu time

这个指标应该说是最重要的,从上图可以看到,133这个方法的调用次数为20次,而它的Incl Cpu Time为12.859ms,那么133方法每一次执行的时间是0.643ms(133这个方法是SimpleAdapter的getItemView方法)

对于一个adapter的getView方法来说0.643ms是非常快的(因为这个adapter中只有一个TextView,我为了测试用的)

如果getView方法执行时间很长,那么必然导致列表滑动的时候产生卡顿现象,可以在getView方法的Children方法列表中找到耗时最长的方法,分析出现问题的原因:

  • 是因为有过多的计算?
  • 还是因为有读取SD卡的操作?
  • 还是因为adapter中View太复杂了?
  • 还是因为需要有很多判断,设置View的显示还是隐藏
  • 还是因为其他原因…
7. Real Time / Call

Real Time 和 Cpu Time 我现在还不太明白它们的区别,我的理解应该是:

  • Cpu Time 应该是某个方法占用CPU的时间
  • Real Time 应该是这个方法的实际运行时间

为什么它们会有区别呢?可能是因为CPU的上下文切换、阻塞、GC等原因方法的实际执行时间要比Cpu Time 要稍微长一点。

总结

TraceView是一个非常强大的性能分析工具,因为Android 官网对这个工具的使用介绍文档很少,而且一些中文博客中写的也都是抄来抄去,没有讲到底怎么使用。

最近我在做这方面的性能分析,就慢慢琢磨了这么工具的使用,发现非常强大,写下来总结一下。

Android的性能分析工具还有很多,比如:

  • Eclipse Memory Analyzer Tool 来分析Android app的内存使用
  • Dump UI Hierarchy for UI Atomator,分析UI层级
  • systrace
  • 其他

下图这一条工具栏中有很多性能分析工具~~~

TOOLS

原文链接:http://bxbxbai.github.io/2014/10/25/use-trace-view/

com.stub.StubApp.apk 立即下载

相关推荐

Sagittarius:Sagittarius 在线游戏服务的开源

Sagittarius 是一款使用构建的强大且免费的在线游戏服务。 这意味着您可以立即获得 Google 产品的所有可扩展性和可靠性。 更重要的是,Sagittarius 旨在部署到您自己的 App Engine 帐户,让您可以完全控制游戏的后端。 访问了解更多信息!

SSM之Spring学习记录

IoC 中文名称:控制反转 英文名称:(Inversion of Control) IoC 完成的事情:原先由程序员主动通过 new 实例化对象事情,转交给 Spring 负责. 控制反转中控制指的是:控制类的对象. 控制反转中反转指的是转交给 Spring 负责. IoC 最大的作用:解耦. 程序员不需要管理对象.解除了对象管理和程序员之间的耦合. 环境搭建 导入jar包,四个核心包一个日志包(commons-logging) 在 src 下新建 applicationContext.xml .

Sagittarius_FV的博客 2066

com.stub.StubApp.apk.1.1

com.stub.StubApp.apk.1.1

WebSphere Application Server V6 备忘录

1. WebSphere with Optimizeit it is for WebSphere 4.0,  while  it’s almost same as websphere6  Using Optimizeit with WebSphere 4.0 Advanced Edition

切尔斯基的工具 5945

【算法】—前缀和与差分详解

前缀和指一个数组的某下标之前的所有数组元素的和(即数列的前n项求和),前缀和是一种重要的预处理,能够降低算法的时间复杂度,可以快速地求出某一段的和,对于处理区间之间的问题是往往十分高效相比较其他算法而言,前缀和更像是一种解题的技巧,一种优化方式输入一个长度为 n 的整数序列。接下来再输入 m 个询问,每个询问输入一对 l,r 对于每个询问,输出原序列中从第 l 个数到第 r 个数的和5 32 1 3 6 41 21 32 4123453610。

DAY I 的成长之路 6022

深入解析YT8521S千兆以太网PHY芯片的设计与调试要点

本文深入解析了YT8521S千兆以太网PHY芯片的设计与调试要点。重点剖析了硬件设计中的电源方案、RGMII接口电平配置(尤其是1.8V电平方案)以及PCB布局布线等关键细节,并提供了从硬件检查、驱动配置到性能测试的完整调试流程,帮助工程师规避常见陷阱,实现稳定可靠的千兆网络连接。

weixin_29190573的博客 687

[转载]正确使用Android性能分析工具——TraceView

正确使用Android性能分析工具——TraceView 本文转载于 点击打开链接 前面唠叨 最近公司app中有些列表在滑动的时候会有卡顿现象,我就开始着手解决这些问题,解决问题之前首先要分析列表滑动的性能瓶颈在什么地方。因为之前不会正确使用TraceView这个工具,主要是看不懂TraceView界面下方数据指标的值代表什么意思…以前我用StopWatch类来分析性能,

mmrx的博客 609

ADS 使用教程(一)Workspace, Library and Cell

简要介绍ADS的基本内容

Dirge19的博客 6612

正确使用 Android 性能分析工具——TraceView

TraceView界面 现来看一下整个界面的图,整个界面包括上下两部分,上面是你测试的进程中每个线程的执行情况,每个线程占一行;下面是每个方法执行的各个指标的值 上面一部分是你测试进程的中每个线程运行的时间线,下图中可以可以看到,主要只有一个main线程在执行,因为我滑动了一下列表,main线程(UI线程)正在进行绘制View呢~ 然后我点击了序号为133的一个方法io.bxbx

u010897392的专栏 1746

避坑指南:HslCommunication连接西门子PLC时常见的5个错误及解决方法(S7-1200/S1500适用)

本文详细解析了使用HslCommunication连接西门子S7-1200/S1500 PLC时常见的5个错误及解决方法,包括基础连接配置、数据块读写异常、连接闪断、防火墙与权限问题以及高级调试技巧。通过实战案例和代码示例,帮助开发者快速定位和解决连接问题,提升工业自动化项目的开发效率。

weixin_30752699的博客 396

Harness设计——Anthropic实战:规划器、生成器、评估器三角色协作详解

本文探讨了如何通过多智能体架构突破AI编码的瓶颈问题。文章首先分析了当前AI编码面临的两大核心挑战:上下文窗口限制导致的连贯性丧失,以及自我评估机制缺失引发的质量判断偏差。针对这些问题,作者提出了基于生成对抗网络(GAN)灵感的解决方案,设计了三智能体系统:规划器负责需求分析,生成器执行编码任务,评估器进行质量审查。 实验表明,在前端设计任务中,通过制定可量化的评分标准(设计质量、原创性、工艺、功能性)并建立生成-评估反馈循环,能显著提升输出质量。这种架构随后被扩展到全栈开发领域,采用类似敏捷开发的&quo

oe1019的专栏 867
上一篇: Android学习系列(4)--App自适应draw9patch不失真背景
下一篇: Android动画之translate(位移动画)
hookfeng
博客等级 码龄12年 4粉丝 5原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值