当前位置:   article > 正文

Systrace_traceview 与systrace有什么区别

traceview 与systrace有什么区别

因为最近用的比较多,专

一、 Systrace

Systrace 是Android4.1中新增的性能数据采样和分析工具,它可帮助开发者收集Android关键子系统

如SurfaceFlinger、WindowManagerService等Framework部分关键模块、服务、View系统等

Google IO 2017上更是对其各种强推。Systrace其实和TraceView很像,都是统计一些方法(或者是一个执行阶段)的耗时,然后在一个有时间轴的图表上展示出来。不同的是,TraceView是收集所有方法的耗时信息和嵌套关系,这使得TraceView本身的性能消耗很大,反而影响了实际的运行环境。Systrace则采用了不同的思路,通过有限的Label先粗略统计出一个阶段的耗时,定位到问题以后,在慢慢细化和进一步测算分析。

监视和跟踪Android系统的行为:

1.CPU周期都用在哪里

2.每个线程、进程在指定时间内都在干嘛。

3.功能包括跟踪系统的I/O操作、内核工作队列、CPU负载以及Android各个子系统的运行状况等

4. 会突出观测到的问题,从垃圾回收到渲染内容都可能是问题对象,甚至提供给你建议的解决方案。

它主要由3部分组成:

  • 内核部分:Systrace利用了Linux Kernel中的ftrace功能,所以,如果要使用Systrace的话,必须开启kernel中和ftrace相关的模块。
  • 数据采集部分:Android定义了一个Trace类,应用程序可利用该类把统计信息输出给ftrace。同时,Android还有一个atrace程序,它可以从ftrace中读取统计信息然后交给数据分析工具来处理。
  • 数据分析工具:Android提供一个systrace.py(python脚本文件,位于Android SDK目录/tools/systrace中,其内部将调用atrace程序)用来配置数据采集的方式(如采集数据的标签、输出文件名等)和收集ftrace统计数据并生成一个结果网页文件供用户查看。从本质上说,Systrace是对Linux Kernel中ftrace的封装。应用进程需要利用Android提供的Trace类来使用Systrace。

常用标签

不论是DDMS还是命令行,都可以在启动trace前指定采集哪些系统预置的标签。下面把一些常用的标签类别列举如下:

  • Graphics: Graphic系统的相关信息,包括SerfaceFlinger,VSYNC消息,Texture,RenderThread等;分析卡顿非常有效。
  • Input:
  • View System: View绘制系统的相关信息,比如onMeasure,onLayout等;对分析卡顿比较有帮助。
  • Window Manager:
  • Activity Manager: ActivityManager调用的相关信息;用来分析Activity的启动过程比较有效。
  • Application:
  • Resource Loading:
  • Dalvik VM: 虚拟机相关信息,比如GC停顿等。
  • CPU Scheduling: CPU调度的信息;你能看到CPU在每个时间段在运行什么线程;线程调度情况,比如锁信息。

 

二、使用和分析

2.1 Device Monitor by selecting Tools > Android > Monitor.

这里写图片描述

每次抓取前,最好清理一下

2.2 绿色、黄色、红色来区分当前界面的性能等级分别是优、良、差。当遇到红色的时候肯定当前的性能需要优化。

抓取的Trace报告提供了Android系统进程在特定时间段内的整体情况。 例如在显示Activity或动画时卡顿,Systrace会提供关于如何解决这些问题的建议。
但是,systrace不会在应用程序进程中收集有关代码执行的信息

在运行Android 5.0(API级别21)或更高版本的设备上, UI 渲染的工作主要由UI ThreadRenderThread两个线程完成。

在之前的版本中,创建渲染框架的所有工作都是在UI Thread上完成的。

找到分析进程对应的ui线程,线程的纵向信息记录的是调用关系,横向信息记录的是调用顺序

obtainView ---> inflate--- Te

 

三、添加 tag 分析

从Android 4.3( 18)开始,使用Trace类,可以在代码中添加更加详细的标记。使用Trace.beginSection(String)开始一段追踪,使用Trace.endSection()结束最近的一次追踪。

 app层 自定义 TAG

  1. import Android.os.Trace;
  2. Trace.beginSection(String sectionName)�
  3. ... ...
  4. Trace.EndSection()

 Framework 层自定义 TAG

  1. import Android.os.Trace;
  2. Trace.traceBegin(long traceTag, String methodName)
  3. ... ...
  4. Trace.traceEnd(long traceTag)

. Native 层自定义 TAG

  1. #include<utils/Trace.h>
  2. ATRACE_BEGIN("TEST");
  3. ... ...
  4. ATRACE_END();

 

Systrace无法帮你定位到代码里面的具体到某一行代码,但是我们可以通过Alerts和Frames来能基本上优化了不足的地方,然后我们可以根据TraceView来分析具体函数花了多长时间来进一步优化代码提高性能。

 

Alerts和Frames两栏

这个警告指出了,有一个View#draw()方法执行了比较长的时间。我们可以在下面看到问题的描述、链接,甚至是相关的视频。

下面我们看Frames这一行,可以看到这里展示了被绘制出来的每一帧,并且用绿、黄、红三颜色来区分它们在绘制时的性能。我们选一个红色帧来瞅瞅:

在最下方,我们看到了与这一帧所相关的一些警告。

在这三个警告中,有一个是我们上面所提到的(View#draw())。接下来我们在这一帧处放大并在下方展开“Inflation during ListView recycling”这条警告:

我们可以看到警告部分的总耗时32毫秒,远高于了我们对保障60fps所需的16.6毫秒绘制时间。同时还有更多的ListView每个条目的绘制时间,大约是6毫秒每个条目,总共五个。而Description描述项中的内容会帮助我们理解问题,甚至提供问题的解决方案。回到我们上一张图片,我们可以在“inflate”这一个块区处放大,并且观察到底是哪些View在被填充过程中耗时比较严重。

 

下面是另外一个渲染过慢的实例:

在选择了某一帧之后,我们可以按“m”键来高亮这一帧,并且在上方看到了这一部分的耗时,如图,我们看到了这一阵的绘制总共耗时大约19毫秒。而当我们展开这一帧唯一的一个警告时,我们发现了“Scheduling delay”这条错误。

Scheduling delay(调度延迟)的意思就是一个线程在处理一块运算的时候,在很长一段时间都没有被分配到CPU上面做运算,从而导致这个线程在很长一段时间都没有完成工作。我们选择这一帧中最长的一块,从而得到更加详细的信息:

 

在红框区域内,我们看到了“Wall duration”,他代表着这一区块的开始到结束的耗时。之所以叫作“Wall duration”,是因为他就像是墙上的一个时钟,从线程的一开始就为你计时。

而CPU Duration一项中显示了实际CPU在处理这一区块所消耗的时间。

很显然,两个时间的差距还是非常大的。整个区块耗时18毫秒,而在这之中CPU只消耗了4毫秒的时间去运算。这就有点奇怪了,所以我们应该看一下在这整个过程之中,CPU去干吗了。

可以看到,所有四个线程都非常的繁忙。

选择其中的一个线程会告诉我们是哪个程序在占用他,在这里是一个包名为com.udinic.keepbusyapp的程序。在这里,由于另外一个程序占用CPU,导致了我们的程序未能获得足够的CPU资源。

但是这种情况其实是暂时的,因为被其他后台应用占用CPU的情况并不多见,但仍有其他应用的线程或是主线程占用CPU。而Systrace也只能为我们提供一个概览,他的深度是有限的。所以要找到我们app中到底是什么让我们的CPU繁忙,我们还要借助另一个工具——Traceview。

 

 

 

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/IT小白/article/detail/725348
推荐阅读
相关标签
  

闽ICP备14008679号