1. TraceView
2.Systrace UI性能分析
3.TraceView,Systrace UI分析实例
(1)TraceView
- TraceView 是 AndroidSDK 自带的工具,用来分析函数调用过程,可以对 Android 的应用 程序以及 Framework 层的代码进行性能分析。它是一个图形化的工具,最终会产生一个图 表,用于对性能分析进行说明,可以分析到应用具体每一个方法的执行时间,使用可以非常 直观简单,分析性能问题很方便。
使用方法
在使用 TraceVeiw 分析问题之前需要得到一个*.trace 的文件,然后通过 TraceView 来分 析 trace 文件的信息,trace 文件的获取有两种方式:
-
在DDMS中使用
(1)连接设备。
(2)打开应用
(3)打开 DDMS(若在 Android Studio 中则先打开 Android Device Monitor)。( 可以在\androidSDK\tools\monitor.bat打开)
(4)单击 Strart Method Profiling 按钮
(6)启动后有两个选项 我们先选择第一个(7) 在应用中操作需要监控的点,比如进入一个 Activity 或者滑动一个列表,完 成后单击 Stop Method Profiling 按钮,如图所示。
(7)结束后会生成.trace文件,并展示traceView试图
- TraceView视图说明
TraceView视图分为两部分,上半部分为时间面板,下半部分为分析面板
X 轴表示时间消耗,单位为毫秒(ms), Y 轴表示各个线程,每个线程中的不同方法使 用了不同的颜色来表示,颜色占用面积越宽,表示该方法占用 CPU 时间越长。
时间片面板可以放大/缩小,也可以指定区域放到最大,方便查看具体的过程,一般 优先选择放大耗时严重的区域。
- TraceView视图说明
- 分析面板如下图所示
列名 | 意义 |
---|---|
Name | 所有的调用项,展开可以看到有的有Parent和Child子项,被指调用和调用 |
Incl Cpu Time % | 某函数占用的CPU时间占总时间百分比,包含内部调用其他函数调用CPU时间 |
Incl Cpu Time | 某函数占用的CPU时间,包含内部调用其他函数调用CPU时间 |
Excl Cpu Time % | 某函数占用的CPU时间占用总时间百分比,但不包含内部调用其他函数占用的CPU时间 |
Excl Cpu Time | 某函数占用的CPU时间,但不包含内部调用其他函数占用的CPU时间 |
Incl Real Time % | 某函数运行的真实时间百分比 ,包含调用其他函数所用的时间 |
Incl Real Time | 某函数运行的真实时间百分比,以毫秒为单位 ,包含调用其他函数所用的时间 |
Incl Real Time % | 某函数运行的真实时间 ,不含调用其他函数所用的时间 |
Incl Real Time | 某函数运行的真实时间,以毫秒为单位 ,不含调用其他函数所用的时间 |
Call+Recur Calls/Total | 某函数被调用次数 |
CPU Time/Call | 某函数调用CPU时间与调用次数的比 ,相当于该函数平均执行时间 |
Real Time/Call | 同CPU Time/Call,只不过统计单位换成了真实时间 |
使用 TraceView 查看耗时,主要关注 Calls+Recur Calls/Total 和 Cpu Time/Call 这两个值, 也就是关注调用次数多和耗时久的方法,然后优化这些方法的逻辑和调用次数,减少耗时。
注意 RealTime 与 cputime 区别为:因为 RealTime 包括了 CPU 的上下文切换、阻 塞、GC 等,所以 RealTime 方法的实际执行时间要比 CPU Time 稍微长一点。
(2)Systrace UI性能分析
- 在应用程序开发过程中,UI(用户界面)的流畅度是体验的核心,特别是在动画、跳转 或者列表的滑动过程中,出现卡顿和无响应是非常影响用户体验的,要解决这些问题,首先 要找到问题的原因,前面介绍的 TraceView 是分析性能的一款利器,下面再介绍一个分析应 用程序 UI 性能的工具:Systrace。
- Systrace 是 Android 4.1 及以上版本提供的性能数据采样和分析工具。它可以帮助开发者 收集 Android 关键子系统(如 surfaceflinger、WindowManagerService 等 Framework 部分关键 模块、服务,View 系统等)的运行信息,从而帮助开发者更直观地分析系统瓶颈,改进性 能。Systrace 的功能包括跟踪系统的 I/O 操作、内核工作队列、CPU 负载等,在 UI 显示性能 分析上提供很好的数据,特别是在动画播放不流畅、渲染卡等问题上。Systrace 工具可以跟 踪、收集、检查定时信息,可以很直观地查看 CPU 周期消耗的具体时间,显示每个线程和 进程的跟踪信息,使用不同颜色来突出问题的严重性,并提供如何解决这些问题的建议。
- 注意 由于 Systrace 是以系统的角度返回一些信息,并不能定位到具体耗时的方 法,要进一步获取 CPU 满负荷运行的原因,就需要使用工具 Traceview .
- Systrace使用方法
(1)在DDMS中使用
1. 打开Android Device Monitor,连接手机并准备需要抓取的界面
2. 单机Systrace按钮进入抓取前的设置,选择需要跟踪的内容:
- 到了设定的时间后,生成了Trace.html文件,我设置的是5s,在上面指定路径有一个文件我们直接Chrome打开。
(2)使用命令行
使用命令行方式更灵活,速度更快,并且配置好后再使用能快速得到结果,在 Android 4.3 及更高版本的设备上使用 Systrace 时,可以省略设置跟踪类别标签来获取默认值,或者 可以手动列入指定标签。路径和命令如下:
cd D:\androidSDK\platform-tools\systrace
python systrace.py --time=10 -0 mysystrace.html sched gfx view wm
其中参数设置对应的功能如下:
参数名 | 意义 |
---|---|
-h,–help | 帮助信息 |
-o < FILE> | 保存的文件名 |
-t N,–time=N | 多少秒内的数据,默认为5s,以当前的时间点往后倒N秒时间 |
-b N,–buf-size=N | 单位为千字节,限制数据大小 |
-k< KFUNCS> --ktrace=< KFUNCS> | 追踪特殊方法 |
-l,–list-categories | 设备需要追踪的标签 |
-a < APP_NAME> ,-app=< APP_NAME> | 包名 |
–from-file=< FROM_FILE> | 创建报告的来源trace文件 |
-e< DEVICE_SERIAL> , --serial=< DEVICE_SERIAL> | 设备号 |
(2)应用中获取,Systrace不会追踪应用的所有工作,所以在有需求的情况下,需要添加追踪的代码部分。可以通过trace类来实现这个功能。它能够让你在任何时候跟踪应用的一举一动。在获取Trace的过程中,即Trace.beginSection()与Trace.endSection()之间的代码工作会一直被追踪。
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
Trace.beginSection("MainActivityTrace")//开始
btn.setOnClickListener {
Toast.makeText(this, "Trace", Toast.LENGTH_SHORT).show()
Trace.endSection()//结束
}
}
可以定义多个Trace模块,但是beginSection和endSection需要成对出现,如果只有开始没有结束会严重影响应用的性能。
- 分析Systrace报告
签名获取的trace.html文件。有一些常用的快捷键
快捷键 | 功能 |
---|---|
W | 放大 |
S | 缩小 |
A | 左移 |
D | 右移 |
其中和UI绘制关系最密切的是Alerts和Frame
(1)Alerts
从上图可以看到,Alerts一栏标记了性能有问题的点,单机该点可以查看详细信息,在右边侧边栏有一个Alerts框,单机可以查看每个类型Alerts的数量,单机某一个Alert可以看到问题的详细描述。
(2)Frame
每个应用都有一行专门显示 frame,每一帧就显示为一个绿色的圆圈。当显示为黄色或 者红色时,它的渲染时间超过了 16.6ms(即达不到 60fps 的水准)。使用 W 键放大,看看这 一帧的渲染过程中系统到底做了什么,同时它会将任何它认为性能有问题的东西都高亮警告, 并提示要怎么优化。如图所示,在 Frame 栏有一个 F 帧红色告警,从下面 的问题详细描述可以看出,警告的主要原因测量布局花了很长的时间,绘图draw花了很长的时间,Scheduling delay(调度延迟)的意思就是一个线程在处理一块运算的时候,在很长一段时间都没有被分配到CPU上面做运算,从而导致这个线程在很长一段时间都没有完成工作。我们发现这帧只运行了1.6ms,而有100多ms是在休眠,这意味着这一帧的渲染过程非常慢。在 Systrace 中也会提供一些对应链接,提供更多解释。
- 如果想知道 UI 线程怎么会花费这么多时间的话,就需要使用 TraceView, 来分析具体是哪些函数在消耗时间。 接下来会分析TraceView。