android trace —— 简介，适合新人

本文主要是对 trace 进行简单介绍，介绍其简单使用方法；如何抓trace；如何去看 trace等

1 trace简介

trace 是 Android4.1 中新增的性能数据采样和分析工具。它可帮助开发者收集 Android 关键子系统（如 SurfaceFlinger/SystemServer/Kernel/Input/Display 等 Framework 部分关键模块、服务，View系统等）的运行信息，从而帮助开发者更直观的分析系统瓶颈，改进性能。

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

1.1 怎么抓trace

目前google推荐的方式是 抓 perfetto 形式的trace，不推荐systrace了；

最简单方式就是

1 打开需要抓trace的设备

2 进入 开发者模式

3 进入 系统跟踪 选项

4 打开 录制跟踪（默认是关闭的），这时就开始抓trace了

下面是结束抓取trace的步骤

5 关闭 录制跟踪 ，这时设备就开始保存刚刚抓的trace了，保存路径可以点击 清除系统跟踪 按钮，会提示路径信息的；

1.2 怎么看trace

1 使用谷歌浏览器

2 输入网址： Perfetto UI

3 把trace使用鼠标拖拽到第2步加载出来的网页中就可以了

1.3 trace适用的场景

1 卡顿

2 丢帧

3 想要优化性能

2 抓到的trace上信息简介

本文主要是讲解如何查看 trace 中的线程状态 , 如何对线程的唤醒信息进行分析, 如何解读信息区的数据, 以及介绍了常用的快捷键. 通过本篇文章的学习, 可以掌握进程和线程相关的一些信息, 也知道如何查看复杂的 trace 中包含的关键信息

2.1 线程状态查看

trace 会用不同的颜色来标识不同的线程状态, 在每个方法上面都会有对应的线程状态来标识目前线程所处的状态，通过查看线程状态我们可以知道目前的瓶颈是什么, 是 cpu 执行慢还是因为 Binder 调用, 又或是进行 io 操作, 又或是拿不到 cpu 时间片

线程状态主要有下面几个

2.1.1 绿色 : 运行中（Running）

只有在该状态的线程才可能在 cpu 上运行。而同一时刻可能有多个线程处于可执行状态，这些线程的 task_struct 结构被放入对应 cpu 的可执行队列中（一个线程最多只能出现在一个 cpu 的可执行队列中）。调度器的任务就是从各个 cpu 的可执行队列中分别选择一个线程在该cpu 上运行

作用：我们经常会查看 Running 状态的线程，查看其运行的时间，与竞品做对比，分析快或者慢的原因：

1. 是否频率不够？
2. 是否跑在了小核上？
3. 是否频繁在 Running 和 Runnable 之间切换？为什么？
4. 是否频繁在 Running 和 Sleep 之间切换？为什么？
5. 是否跑在了不该跑的核上面？比如不重要的线程占用了超大核

2.1.2 蓝色 : 可运行（Runnable）

线程可以运行但当前没有安排，在等待 cpu 调度

作用：Runnable 状态的线程状态持续时间越长，则表示 cpu 的调度越忙，没有及时处理到这个任务：

1. 是否后台有太多的任务在跑？
2. 没有及时处理是因为频率太低？
3. 没有及时处理是因为被限制到某个 cpuset 里面，但是 cpu 很满？
4. 此时 Running 的任务是什么？为什么？

2.1.3 白色 : 休眠中（Sleep）

线程没有工作要做，可能是因为线程在互斥锁上被阻塞。

作用 ： 这里一般是在等事件驱动

2.1.4 橘色 : 不可中断的睡眠态 （Uninterruptible Sleep - IO Block）

线程在I / O上被阻塞或等待磁盘操作完成，一般底线都会标识出此时的 callsite ：wait_on_page_locked_killable

作用：这个一般是标示 io 操作慢，如果有大量的橘色不可中断的睡眠态出现，那么一般是由于进入了低内存状态，申请内存的时候触发 pageFault, linux 系统的 page cache 链表中有时会出现一些还没准备好的 page(即还没把磁盘中的内容完全地读出来) , 而正好此时用户在访问这个 page 时就会出现 wait_on_page_locked_killable 阻塞了. 只有系统当 io 操作很繁忙时, 每笔的 io 操作都需要等待排队时, 极其容易出现且阻塞的时间往往会比较长.

2.1.5 紫色 : 不可中断的睡眠态（Uninterruptible Sleep）

线程在另一个内核操作（通常是内存管理）上被阻塞。

作用：一般是陷入了内核态，有些情况下是正常的，有些情况下是不正常的，需要按照具体的情况去分析

2.2 线程唤醒信息分析

trace 会标识出一个非常有用的信息，可以帮助我们进行线程调用等待相关的分析。

一个线程被唤醒的信息往往比较重要，知道他被谁唤醒，那么我们也就知道了他们之间的调用等待关系，如果一个线程出现一段比较长的 sleep 情况，然后被唤醒，那么我们就可以去看是谁唤醒了这个线程，对应的就可以查看唤醒者的信息，看看为什么唤醒者这么晚才唤醒。

一个常见的情况是：应用主线程程使用 Binder 与 SystemServer 的 AMS 进行通信，但是恰好 AMS 的这个函数正在等待锁释放（或者这个函数本身执行时间很长），那么应用主线程就需要等待比较长的时间，那么就会出现性能问题，比如响应慢或者卡顿，这就是为什么后台有大量的进程在运行，或者跑完 Monkey 之后，整机性能会下降的一个主要原因

另外一个场景的情况是：应用主线程在等待此应用的其他线程执行的结果，这时候线程唤醒信息就可以用来分析主线程到底被哪个线程 Block 住了

2.3 快捷键使用

快捷键的使用可以加快查看 trace 的速度,下面是一些常用的快捷键

W : 放大 Systrace , 放大可以更好地看清局部细节

S : 缩小 Systrace, 缩小以查看整体

A : 左移

D : 右移

M : 高亮选中当前鼠标点击的段(这个比较常用,可以快速标识出这个方法的左右边界和执行时间,方便上下查看)