android性能分析之Systrace
启动
-Systrace
Systrace 是 Android4.1 中新增的性能数据采样和分析工具。它可帮助开发者收集 Android 关键子系统（如 SurfaceFlinger/SystemServer/Kernel/Input/Display 等 Framework 部分关键模块、服务，View系统等）的运行信息，从而帮助开发者更直观的分析系统瓶颈，改进性能
Systrace的功能包括跟踪系统的I/O操作、内核工作队列、CPU负载以及Android各个子系统的运行状况（如surfaceflinger、WindowManagerService等Framework部分关键模块、服务）等,。
在Android平台中，它主要由3部分组成：
- 内核部分：Systrace利用了Linux Kernel中的ftrace功能。必须开启kernel中和ftrace相关的模块。
- 数据采集部分：Android定义了一个Trace类。应用程序可利用该类把统计信息输出给ftrace。同时，Android还有一个atrace程序，它可以从ftrace中读取统计信息然后交给数据分析工具来处理。
- 数据分析工具：Android 提供一个 systrace.py（ python 脚本文件，位于 Android SDK目录/platform-tools/systrace 中，其内部将调用 atrace 程序）用来配置数据采集的方式（如采集数据的标签、输出文件名等）和收集 ftrace 统计数据并生成一个结果网页文件供用户查看。 从本质上说，Systrace 是对 Linux Kernel中 ftrace 的封装。应用进程需要利用 Android 提供的 Trace 类来使用 Systrace.。
关于 Systrace 的官方介绍和使用可以看这里
了解 Systrace
Systrace 概览
常用命令
$ANDROID_HOME/platform-tools/systrace/catapult/systrace/bin/systrace -a com.miui.player -b 81920 -o ~/trace.html input gfx view wm am res dalvik ss aidl sched freq idle disk memreclaim binder_driver binder_lock
alias配置
alias strace-start='python $TRACE_TOOLS/systrace.py'
alias strace-get='strace-start -t 8 input gfx view wm am res dalvik ss aidl sched freq idle disk memreclaim binder_driver binder_lock -o ~/tmp/systrace_$(date +%Y%m%d%H%M%S).html'
可以使用atrace --list命令查看是strace的参数
添加代码的跟踪方式native和java
native层用法
#define ATRACE_TAG ATRACE_TAG_ALWAYS
#include// for c++
#include// for c
ATRACE_CALL();
ATRACE_BEGIN();
ATRACE_END();
定义ATRACE_TAG：如使用了ATRACE_TAG_GRAPHICS，表示它和Graphics相关。
ATRACE_INIT：用于统计某个变量使用的情况。ATRACE_INIT(“变量TAG”， 变量名)
ATRACE_CALL：用于统计函数的调用情况ATRACE_CALL()
app层
Trace.beginSection(“Fragement_onCreateView”);
// … 其他代码
// …
// … 结束处
Trace.endSection()
然后通过指令：python systrace.py --app=sectionName 指定APK，或者通过DDMS选择指定APK，抓取systrace分析
Java framework层
import android.os.Trace;
Trace.traceBegin(Trace.TRACE_TAG_VIEW, “Activity:setContentView”); //choose one tag from Trace.java
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
Kernel
#define ATRACE_END() trace_printk(“tracing_mark_write: E\n”)
#define ATRACE_BEGIN(name) trace_printk(“tracing_mark_write: B|%d|%s\n”, current->tgid, name)
#define ATRACE_FUNC() ATRACE_BEGIN(func)
#define ATRACE_INT(name, value) trace_printk(“tracing_mark_write: C|%d|%s|%d\n”, current->tgid, name, (int)(value))
抓到的systrace需要进行加工才能在html正常展示
sed -i 's/^\([^\[]*\[[0-9]\{3\}\] [^\s]\{4\} \s*[0-9]\+\.[0-9]\+:\) \([^:]*:\) \(tracing_mark_write: .*\)/\1 \3/g'.html
打开方式：
进入Android/Sdk/platform-tools/systrace目录下
python systrace.py [options] [category1] [category2] … [categoryN]
[options]”是一些命令参数；“[category]”等是你感兴趣的系统模块，比如view代表View系统（包含绘制流程），am代表ActivityManager（包含Activity的创建过程等
如：python systrace.py --time=10 -o mynewtrace.html sched gfx view wm
要在 Pixel/Pixel XL 上调试抖动问题，请从以下命令开始：
./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000
如果报错apt-get install python-six，请执行sudo apt-get install python-six
options:
| options | 描述 |
|---|---|
| -o < FILE > | 输出的目标文件 |
| -t N, –time=N | 执行时间，默认5s |
| -b N, –buf-size=N | buffer大小（单位kB),用于限制trace总大小，默认无上限 |
| -k < KFUNCS >，–ktrace=< KFUNCS > | 追踪kernel函数，用逗号分隔 |
| -a < APP_NAME >,–app=< APP_NAME > | 追踪应用包名，用逗号分隔 |
| –from-file=< FROM_FILE > | 从文件中创建互动的systrace |
| -e < DEVICE_SERIAL >,–serial=< DEVICE_SERIAL > | 指定设备 |
| -l, –list-categories | 列举可用的tags |
category常用取值
sched：CPU调度的信息，非常重要；你能看到CPU在每个时间段在运行什么线程；线程调度情况，比如锁信息。
gfx：Graphic系统的相关信息，包括SurfaceFlinger，VSYNC消息，Texture，RenderThread等；分析卡顿非常依赖这个。
view：View绘制系统的相关信息，比如onMeasure，onLayout等；对分析卡顿比较有帮助。
am：ActivityManager调用的相关信息；用来分析Activity的启动过程比较有效。
dalvik： 虚拟机相关信息，比如GC停顿等。
binder_driver：Binder驱动的相关信息，如果你怀疑是Binder IPC的问题，不妨打开这个。
core_services：SystemServer中系统核心Service的相关信息，分析特定问题用。
input： Input
webview ： WebView
wm ： Window Manager
audio： Audio
video ： Video
camera ： Camera
hal ： Hardware Modules
res ： Resource Loading
rs ： RenderScript
freq ： CPU Frequency
membus ： Memory Bus Utilization
idle ： CPU Idle
disk ： Disk input and output
load ： CPU Load
sync ： Synchronization Manager
我们一般会把这个命令配置成Alias，配置如下：
alias st-start=‘python /sdk/platform-tools/systrace/systrace.py’
alias st-start-gfx-trace = ‘st-start -t 8 gfx input view sched freq wm am hwui workq res dalvik sync disk load perf hal rs idle mmc’
这样在使用的时候，可以直接敲 st-start 即可，当然为了区分和保持各个文件，还需要加上 -o xxx.html .上面的命令和参数不必一次就理解，只需要记住如何简单使用即可，在分析的过程中，这些东西都会慢慢熟悉的。
一般来说比较常用的是
-o : 指示输出文件的路径和名字
-t : 抓取时间
-b : 指定 buffer 大小
-a : 指定 app 包名
快捷键使用
快捷键的使用可以加快查看 Systrace 的速度,下面是一些常用的快捷键
- W : 放大 Systrace , 放大可以更好地看清局部细节
- S : 缩小 Systrace, 缩小以查看整体
- A : 左移
- D : 右移
- M : 高亮选中当前鼠标点击的段(这个比较常用,可以快速标识出这个方法的左右边界和执行时间,方便上下查看)
鼠标模式快捷切换 : 主要是针对鼠标的工作模式进行切换 , 默认是 1 ,也就是选择模式,查看 Systrace 的时候,需要经常在各个模式之间切换 , 所以点击切换模式效率比较低,直接用快捷键切换效率要高很多
- 数字键1 : 切换到 Selection 模式 , 这个模式下鼠标可以点击某一个段查看其详细信息, 一般打开 Systrace 默认就是这个模式 , 也是最常用的一个模式 , 配合 M 和 ASDW 可以做基本的操作
- 数字键2 : 切换到 Pan 模式 , 这个模式下长按鼠标可以左右拖动, 有时候会用到
- 数字键3 : 切换到 Zoom 模式 , 这个模式下长按鼠标可以放大和缩小, 有时候会用到
- 数字键4 : 切换到 Timing 模式 , 这个模式下主要是用来衡量时间的,比如选择一个起点, 选择一个终点, 查看起点和终点这中间的操作所花费的时间.
线程状态查看
Systrace 会用不同的颜色来标识不同的线程状态, 在每个方法上面都会有对应的线程状态来标识目前线程所处的状态.
通过查看线程状态我们可以知道目前的瓶颈是什么, 是 CPU 执行慢还是因为 Binder 调用, 又或是进行 IO 操作, 又或是拿不到 CPU 时间片
线程状态主要有下面几个
- 绿色 : 运行中
只有在该状态的进程才可能在CPU上运行。而同一时刻可能有多个进程处于可执行状态，这些进程的task_struct结构（进程控制块）被放入对应CPU的可执行队列中（一个进程最多只能出现在一个CPU的可执行队列中）。进程调度器的任务就是从各个CPU的可执行队列中分别选择一个进程在该CPU上运行。
作用：我们经常会查看 Running 状态的线程，查看其运行的时间，与竞品做对比，分析快或者慢的原因：
- 是否频率不够？
- 是否跑在了小核上？
- 是否频繁在 Running 和 Runnable 之间切换？为什么？
- 是否频繁在 Running 和 Sleep 之间切换？为什么？
- 是否跑在了不该跑的核上面？比如不重要的线程占用了超大核
- 蓝色 : 可运行
线程可以运行但当前没有安排，在等待 cpu 调度
作用：Runnable 状态的线程状态持续时间越长，则表示 cpu 的调度越忙，没有及时处理到这个任务：
- 是否后台有太多的任务在跑？
- 没有及时处理是因为频率太低？
- 没有及时处理是因为被限制到某个 cpuset 里面，但是 cpu 很满？
- 此时 Running 的任务是什么？为什么？
- 白色 : 休眠中
线程没有工作要做，可能是因为线程在互斥锁上被阻塞。
作用 ： 这里一般是在等事件驱动
- 橘色 : 不可中断的睡眠态 IO Block
线程在I / O上被阻塞或等待磁盘操作完成，一般底线都会标识出此时的 callsite ：wait_on_page_locked_killable
作用：这个一般是标示 IO 操作慢，如果有大量的橘色不可中断的睡眠态出现，那么一般是由于进入了低内存状态，申请内存的时候触发 pageFault, linux 系统的 page cache 链表中有时会出现一些还没准备好的 page(即还没把磁盘中的内容完全地读出来) , 而正好此时用户在访问这个 page 时就会出现 wait_on_page_locked_killable 阻塞了. 只有系统当 io 操作很繁忙时, 每笔的 io 操作都需要等待排队时, 极其容易出现且阻塞的时间往往会比较长.
- 紫色 : 不可中断的睡眠态
线程在另一个内核操作（通常是内存管理）上被阻塞。
作用：一般是陷入了内核态，有些情况下是正常的，有些情况下是不正常的，需要按照具体的情况取分析
进程唤醒信息分析
Systrace 会标识出一个非常有用的信息，可以帮助我们进行跨进程调用相关的分析。
一个进程被唤醒的信息往往比较重要，知道他被谁唤醒，那么我们也就知道了他们之间的调用等待关系，如果出现一段比较长的 sleep 情况，然后被唤醒，那么我们就可以去看是谁唤醒了这个线程，对应的就可以查看唤醒者的信息，看看为什么唤醒者这么晚才唤醒。
一个常见的情况是：应用进程使用 Binder 与 SystemServer 的 AMS 线程进行通信，但是恰好 AMS 的这个函数正在等待锁释放（或者这个函数本身执行时间很长），那么应用进程就需要等待比较长的时间，如果恰好是应用进程的主线程在进行等待，那么就会出现性能问题，比如响应慢或者卡顿，这就是为什么后台有大量的进程在运行，或者跑完 Monkey 之后，整机性能会下降的一个主要原因。
Systrace 可以标示出这个的一个原因是，一个任务在进入 Running 状态之前，会先进入 Runnable 状态进行等待，而 Systrace 会把这个状态也标示在 Systrace 上（非常短，需要放大进行看）
拉到最上面查看对应的 cpu 上的 taks 信息，会标识这个 task 在被唤醒之前的状态
顺便贴一下 Linux 常见的进程状态
- D 无法中断的休眠状态（通常 IO 的进程）；
- R 正在可运行队列中等待被调度的；
- S 处于休眠状态；
- T 停止或被追踪；
- W 进入内存交换 （从内核2.6开始无效）；
- X 死掉的进程 （基本很少見）；
- Z 僵尸进程；
- < 优先级高的进程
- N 优先级较低的进程
- L 有些页被锁进内存；
- s 进程的领导者（在它之下有子进程）；
- l 多进程的（使用 CLONE_THREAD, 类似 NPTL pthreads）；
- 01 位于后台的进程组；
信息区数据解析
进程状态信息解析
函数 Slice 信息解析
Counter Sample 信息解析
Async Slice 信息解析
CPU Slice 信息解析
User Expectation 信息解析
位于整个 Systrace 最上面的部分,标识了 Rendering Response 和 Input Response
Binder 和锁竞争
很多卡顿问题和响应速度的问题，是因为跨进程 binder 通信的时候，锁竞争导致 binder 通信事件变长，影响了调用端。最常见的就是应用渲染线程 dequeueBuffer 的时候 SurfaceFlinger 主线程阻塞导致 dequeueBuffer 耗时，从而导致应用渲染出现卡顿
Binder 调用图例
Binder 主要是用来跨进程进行通信，可以看下面这张图，简单显示了在 Systrace 中 ，Binder 通信是如何显示的
图中主要是 SystemServer 进程和 高通的 perf 进程通信，Systrace 中右上角 ViewOption 里面勾选 Flow Events 就可以看到 Binder 的信息
点击 Binder 可以查看其详细信息，其中有的信息在分析问题的时候可以用到
对于 Binder，这里主要介绍如何在 Systrace 中查看 Binder 锁信息和锁等待这两个部分，很多卡顿和响应问题的分析，都离不开这两部分信息的解读
Systrace 显示的锁的信息
monitor contention with owner Binder:1605_B (4667) at void com.android.server.wm.ActivityTaskManagerService.activityPaused(android.os.IBinder)(ActivityTaskManagerService.java:1733) waiters=2 blocking from android.app.ActivityManager$StackInfo com.android.server.wm.ActivityTaskManagerService.getFocusedStackInfo()(ActivityTaskManagerService.java:2064)
上面的话分两段来看，以 blocking 为分界线
第一段信息解读
monitor contention with owner Binder:1605_B (4667) at void com.android.server.wm.ActivityTaskManagerService.activityPaused(android.os.IBinder)(ActivityTaskManagerService.java:1733) waiters=2
- Monitor 指的是当前锁对象的池，在 Java 中，每个对象都有两个池，锁(monitor)池和等待池：
- 锁池（同步队列 SynchronizedQueue ）：假设线程 A 已经拥有了某个对象(注意:不是类 )的锁，而其它的线程想要调用这个对象的某个 synchronized 方法(或者 synchronized 块)，由于这些线程在进入对象的 synchronized 方法之前必须先获得该对象的锁的拥有权，但是该对象的锁目前正被线程 A 拥有，所以这些线程就进入了该对象的锁池中。
这里用了争夺(contention)这个词，意思是这里由于在和目前对象的锁正被其他对象（Owner）所持有，所以没法得到该对象的锁的拥有权，所以进入该对象的锁池- Owner : 指的是当前拥有这个对象的锁的对象。这里是 Binder:1605_B，4667 是其线程 ID。
- waiters 值得是锁池里面正在等待锁的操作的个数；这里 waiters=2 表示目前锁池里面已经有一个操作在等待这个对象的锁释放了，加上这个的话就是 3 个了
- at 后面跟的是拥有这个对象的锁的对象正在做什么。这里是在执行 void com.android.server.wm.ActivityTaskManagerService.activityPaused 这个方法，其代码位置是 ：ActivityTaskManagerService.java:1733 其对应的代码如下：
com/android/server/wm/ActivityTaskManagerService.java
@Override
public final void activityPaused(IBinder token) {
final long origId = Binder.clearCallingIdentity();
synchronized (mGlobalLock) { // 1733 是这一行
ActivityStack stack = ActivityRecord.getStackLocked(token);
if (stack != null) {
stack.activityPausedLocked(token, false);
}
}
Binder.restoreCallingIdentity(origId);
}
可以看到这里 synchronized (mGlobalLock) ，获取了 mGlobalLock 锁的拥有权，
在他释放这个对象的锁之前，任何其他的调用 synchronized (mGlobalLock) 的地方都得在锁池中等待
第二段信息解读
blocking from android.app.ActivityManager$StackInfo com.android.server.wm.ActivityTaskManagerService.getFocusedStackInfo()(ActivityTaskManagerService.java:2064)
标识了当前被阻塞等锁的方法 ， 这里是 ActivityManager 的 getFocusedStackInfo 被阻塞，其对应的代码
com/android/server/wm/ActivityTaskManagerService.java
@Override
public ActivityManager.StackInfo getFocusedStackInfo() throws RemoteException {
enforceCallerIsRecentsOrHasPermission(MANAGE_ACTIVITY_STACKS, "getStackInfo()");
long ident = Binder.clearCallingIdentity();
try {
synchronized (mGlobalLock) { // 2064 是这一行
ActivityStack focusedStack = getTopDisplayFocusedStack();
if (focusedStack != null) {
return mRootActivityContainer.getStackInfo(focusedStack.mStackId);
}
return null;
}
} finally {
Binder.restoreCallingIdentity(ident);
}
}
结论
ActivityTaskManagerService 的 getFocusedStackInfo 方法在执行过程中被阻塞，原因是因为执行同步方法块的时候，没有拿到同步对象的锁的拥有权；需要等待拥有同步对象的锁拥有权的另外一个方法 ActivityTaskManagerService.activityPaused 执行完成后，才能拿到同步对象的锁的拥有权，然后继续执行
等锁分析
Binder 信息里面显示 waiters=2，意味着前面还有两个操作在等锁释放，也就是说总共有三个操作都在等待 Binder:1605_B (4667) 释放锁，我们来看一下 Binder:1605_B 的执行情况
从上图可以看到，Binder:1605_B 正在执行 activityPaused，中间也有一些其他的 Binder 操作，最终 activityPaused 执行完成后，释放锁
下面我们就把这个逻辑里面的执行顺序理顺，包括两个 waiters
锁等待
上图中可以看到 mGlobalLock 这个对象锁的争夺情况
- Binder_1605_B 首先开始执行 activityPaused，这个方法中是要获取 mGlobalLock 对象锁的，由于此时 mGlobalLock 没有竞争，所以 activityPaused 获取对象锁之后开始执行
- android.display 线程开始执行 checkVisibility 方法，这个方法也是要获取 mGlobalLock 对象锁的，但是此时 Binder_1605_B 的 activityPaused 持有 mGlobalLock 对象锁 ，所以这里 android.display 的 checkVisibility 开始等待，进入 sleep 状态
- android.anim 线程开始执行 relayoutWindow 方法，这个方法也是要获取 mGlobalLock 对象锁的，但是此时 Binder_1605_B 的 activityPaused 持有 mGlobalLock 对象锁 ，所以这里 android.display 的 checkVisibility 开始等待，进入 sleep 状态
- android.bg 线程开始执行 getFocusedStackInfo 方法，这个方法也是要获取 mGlobalLock 对象锁的，但是此时 Binder_1605_B 的 activityPaused 持有 mGlobalLock 对象锁 ，所以这里 android.display 的 checkVisibility 开始等待，进入 sleep 状态
经过上面四步，就形成了 Binder_1605_B 线程在运行，其他三个争夺 mGlobalLock 对象锁失败的线程分别进入 sleep 状态，等待 Binder_1605_B 执行结束后释放 mGlobalLock 对象锁
锁释放
上图可以看到 mGlobalLock 锁的释放和后续的流程
- Binder_1605_B 线程的 activityPaused 执行结束，mGlobalLock 对象锁释放
- 第一个进入等待的 android.display 线程开始执行 checkVisibility 方法 ，这里从 android.display 线程的唤醒信息可以看到，是被 Binder_1605_B(4667) 唤醒的
- android.display 线程的 checkVisibility 执行结束，mGlobalLock 对象锁释放
- 第二个进入等待的 android.anim 线程开始执行 relayoutWindow 方法 ，这里从 android.anim 线程的唤醒信息可以看到，是被 android.display(1683) 唤醒的
- android.anim 线程的 relayoutWindow 执行结束，mGlobalLock 对象锁释放
- 第三个进入等待的 android.bg 线程开始执行 getFocusedStackInfo 方法 ，这里从 android.bg 线程的唤醒信息可以看到，是被 android.anim(1684) 唤醒的