前因：视频卡顿问题，为了排除是cpu占用性能问题还是音视频编解码问题，接触到了Perfetto，感觉很好玩，学习一下。突然感觉公司挺好的，给新人很多成长空间，一边解bug，一边碰新技术，一边学习，有什么问题大家都挺乐意教我~
概述
Perfetto - 系统分析、应用程序跟踪和跟踪分析
Perfetto 是一个用于性能检测和跟踪分析的生产级开源堆栈。它提供用于记录系统级和应用程序级跟踪的服务和库、本机 + java 堆分析、使用 SQL 分析跟踪的库以及用于可视化和探索多 GB 跟踪的基于 Web 的 UI。
记录痕迹
Perfetto 的核心是引入了一种新颖的用户空间到用户空间跟踪协议，该协议基于共享内存缓冲区上的直接 protobuf 序列化。跟踪协议既在内部用于内置数据源，又通过跟踪 SDK 和跟踪事件库公开给 C++ 应用程序。
这个新的跟踪协议允许通过可扩展的基于 protobuf 的功能广告和数据源配置机制动态配置跟踪的各个方面（请参阅跟踪配置文档）。不同的数据源可以多路复用到用户定义的缓冲区的不同子集上，从而还允许将任意长的跟踪流式传输到文件系统中。
Android 和 Linux 上的系统范围跟踪
在 Linux 和 Android 上，Perfetto 捆绑了许多数据源，这些数据源能够从不同的系统界面收集详细的性能数据。有关完整集和详细信息，请参阅文档的数据源部分。一些例子：
- 内核跟踪：Perfetto 与 Linux 的 ftrace 集成，并允许将内核事件（例如调度事件、系统调用）记录到跟踪中。
- /proc 和 /sys 轮询器，允许对进程范围或系统范围的 cpu 和内存计数器随时间的状态进行采样。
- 与 Android HAL 模块集成，用于记录电池和能源使用计数器。
- 本机堆分析：一种低开销堆分析器，用于挂钩 malloc/free/new/delete 并将内存与调用堆栈相关联，基于进程外展开、可配置采样，可附加到已运行的进程。
- 使用与 Android 运行时紧密集成的进程外分析器捕获 Java 堆转储，该分析器允许获取托管堆保留图的完整快照（类型、字段名称、保留大小和对其他对象的引用），但无需转储完整的堆内容（字符串和位图），从而减少序列化时间和输出文件大小。
在 Android 上，Perfetto 是下一代系统跟踪系统，取代了基于 chromium 的 systrace。基于 ATrace 的仪器仍然得到完全支持。有关更多详细信息，请参阅 Android 开发人员文档。
跟踪 SDK 和用户空间检测
Perfetto Tracing SDK 使 C++ 开发人员能够使用特定于应用程序的跟踪点来丰富跟踪。您可以灵活地定义自己的强类型事件和创建自定义数据源，也可以选择使用更易于使用的跟踪事件库，该库允许使用 TRACE_EVENT 形式的注释轻松创建有时间限制的切片、计数器和时间标记RACE_EVENT("category", "event_name", "x", "str", "y", 42)（“类别”、“事件名称”、“x”、“str”、“y”、42）。
该SDK专为跟踪多进程系统和多线程进程而设计。它基于 ProtoZero，这是一个用于在线程本地共享内存缓冲区上直接写入 protobuf 事件的库。
相同的代码可以在完全进程模式下工作，在专用线程上托管 Perfetto 跟踪服务的实例，也可以在系统模式下工作，通过 UNIX 套接字连接到 Linux/Android 跟踪守护程序，从而允许结合应用程序具有系统范围跟踪事件的特定检测点。
该 SDK 基于可移植的 C++17 代码，并使用主要的 C++ 清理程序（ASan、TSan、MSan、LSan）进行了测试。它不依赖于运行时代码修改或编译器插件。
Chromium追踪
Perfetto 的设计初衷是为了取代 chrome://tracing 基础设施的内部结构。 Chromium 中的跟踪及其内部结构基于所有主要平台（Android、CrOS、Linux、MacOS、Windows）上的 Perfetto 代码库。应用相同的基于服务的系统范围跟踪架构，但在内部使用 Chromium Mojo IPC 系统而不是 Perfetto 自己的 UNIX 套接字。
默认情况下，跟踪在 Chromium 中以进程内模式工作，仅记录 Chromium 进程发出的数据。在 Android 上（以及在 Linux 上，如果禁用 Chromium 沙箱）跟踪可以在进程内+系统混合模式下工作，将 chrome 特定的跟踪事件与 Perfetto 系统事件相结合。
Trace分析
除了跟踪记录功能之外，Perfetto 代码库还包括一个用于导入、解析和查询新旧跟踪格式的专用项目：Trace Processor。
Trace Processor 是一个可移植的 C++17 库，提供面向列的表存储，专为高效地将数小时的跟踪数据保存到内存中而设计，并公开基于流行的 SQLite 查询引擎的 SQL 查询接口。跟踪数据模型成为一组 SQL 表，可以通过极其强大且灵活的方式查询和连接这些表来分析跟踪数据。
除此之外，跟踪处理器还包括一个基于跟踪的指标子系统，该子系统由预烘焙和可扩展的查询组成，可以以 JSON 或 protobuf 消息的形式输出有关跟踪的强类型摘要（例如，不同频率下的 CPU 使用情况）状态，按进程和线程细分）。
基于跟踪的指标允许在性能测试场景或批量分析或大型跟踪语料库中轻松集成跟踪。
跟踪处理器还专为低延迟查询和构建跟踪可视化工具而设计。如今，Perfetto UI 将 Trace Processor 用作 Web Assembly 模块，Android Studio 和 Android GPU Inspector 将其用作本机 C++ 库。
Trace可视化
Perfetto 还提供了一个全新的跟踪可视化工具，用于打开和查询长达数小时的跟踪，可从 ui.perfetto.dev 获取。新的可视化工具利用现代网络平台技术。其基于WebWorkers的多线程设计使UI始终保持响应； Trace Processor 和 SQLite 的分析能力通过 WebAssembly 在浏览器中完全可用。
Perfetto UI 打开一次后即可完全离线工作。使用 UI 打开的跟踪由浏览器在本地处理，不需要任何服务器端交互。
数据源
内存计数器和事件
Perfetto 允许在 Android 和 Linux 上收集大量内存事件和计数器。这些事件来自内核接口，包括 ftrace 和 /proc 接口，并且有两种类型：轮询计数器和内核在 ftrace 缓冲区中推送的事件。
每个进程轮询计数器
进程统计数据源允许按用户定义的时间间隔轮询/proc/<pid>/status 和/proc/<pid>/oom_score_adj
UI
SQL
select c.ts, c.value, t.name as counter_name, p.name as proc_name, p.pid
from counter as c left join process_counter_track as t on c.track_id = t.id
left join process as p using (upid)
where t.name like 'mem.%'
| ts | counter_name | value_kb | proc_name | pid |
|---|---|---|---|---|
| 261187015027350 | mem.virt | 1326464 | com.android.vending | 28815 |
| 261187015027350 | mem.rss | 85592 | com.android.vending | 28815 |
| 261187015027350 | mem.rss.anon | 36948 | com.android.vending | 28815 |
| 261187015027350 | mem.rss.file | 46560 | com.android.vending | 28815 |
| 261187015027350 | mem.swap | 6908 | com.android.vending | 28815 |
| 261187015027350 | mem.rss.watermark | 102856 | com.android.vending | 28815 |
| 261187090251420 | mem.virt | 1326464 | com.android.vending | 28815 |
跟踪配置
要每 X 毫秒收集一次进程统计计数器，请在进程统计配置中设置 proc_stats_poll_ms = X。 X 必须大于 100ms，以避免 CPU 使用率过高。有关所收集的特定计数器的详细信息可以在 ProcessStats 参考中找到。
data_sources: {
config {
name: "linux.process_stats"
process_stats_config {
scan_all_processes_on_start: true
proc_stats_poll_ms: 1000
}
}
}
进程内存事件（ftrace）
RSS_统计
最新版本的 Linux 内核允许在驻留集大小 (RSS) mm 计数器发生变化时报告 ftrace 事件。这与 /proc/pid/status 中可用的计数器与VmRSS 相同。该事件的主要优点是，作为事件驱动的推送事件，它允许检测非常短的内存使用突发，否则使用 /proc 计数器无法检测到这些突发。
数百 MB 的内存使用峰值可能会对 Android 产生巨大的负面影响，即使它们只持续几毫秒，因为它们可能会导致大量低内存杀死以回收内存。
支持此功能的内核功能已在 b3d1411b6 中的 Linux 内核中引入，后来由 e4dcad20 进行了改进。自 Linux v5.5-rc1 起，它们在上游可用。此补丁已向后移植到多个运行 Android 10 (Q) 的 Google Pixel 内核中。
mm_事件
mm_event 是一个 ftrace 事件，用于捕获有关关键内存事件的统计信息（/proc/vmstat 公开的事件的子集）。与 RSS-stat 计数器更新不同，mm 事件的数量非常大，单独跟踪它们是不可行的。 mm_event 只报告跟踪中的周期性直方图，从而显着减少开销。
mm_event 仅在某些运行 Android 10 (Q) 及更高版本的 Google Pixel 内核上可用。
当启用 mm_event 时，会记录以下 mm 事件类型：
- mem.mm.min_flt：轻微页面错误
- mem.mm.maj_flt：主要页面错误
- mem.mm.swp_flt：由交换缓存处理的页面错误
- mem.mm.read_io：I/O 支持的读取页错误
- mem.mm…compaction：内存压缩事件
- mem.mm.reclaim：内存回收事件
对于每种事件类型，事件记录：
- count：自上一个事件以来该事件发生了多少次。
- min_lat：自上一个事件以来记录的最小延迟（mm 事件的持续时间）。
- max_lat：自上次事件以来记录的最高延迟。
ui
SQL
在 SQL 级别，这些事件的导入和公开方式与相应的轮询事件相同。这允许收集两种类型的事件（推送和轮询）并在查询和脚本中统一处理它们。
select c.ts, c.value, t.name as counter_name, p.name as proc_name, p.pid
from counter as c left join process_counter_track as t on c.track_id = t.id
left join process as p using (upid)
where t.name like 'mem.%'
| ts | value | counter_name | proc_name | pid |
|---|---|---|---|---|
| 777227867975055 | 18358272 | mem.rss.anon | com.google.android.apps.safetyhub | 31386 |
| 777227865995315 | 5 | mem.mm.min_flt.count | com.google.android.apps.safetyhub | 31386 |
| 777227865995315 | 8 | mem.mm.min_flt.max_lat | com.google.android.apps.safetyhub | 31386 |
| 777227865995315 | 4 | mem.mm.min_flt.avg_lat | com.google.android.apps.safetyhub | 31386 |
| 777227865998023 | 3 | mem.mm.swp_flt.count | com.google.android.apps.safetyhub | 31386 |
跟踪配置
data_sources: {
config {
name: "linux.ftrace"
ftrace_config {
ftrace_events: "kmem/rss_stat"
ftrace_events: "mm_event/mm_event_record"
}
}
}
# This is for getting Thread<>Process associations and full process names.
data_sources: {
config {
name: "linux.process_stats"
}
}
系统范围轮询计数器
该数据源允许定期轮询以下系统数据：
/proc/stat/proc/vmstat/proc/meminfo
ui
可以在跟踪配置中设置跟踪中包含的轮询周期和特定计数器。
SQL
select c.ts, t.name, c.value / 1024 as value_kb from counters as c left join counter_track as t on c.track_id = t.id
| ts | name | value_kb |
|---|---|---|
| 775177736769834 | MemAvailable | 1708956 |
| 775177736769834 | Buffers | 6208 |
| 775177736769834 | Cached | 1352960 |
| 775177736769834 | SwapCached | 8232 |
| 775177736769834 | Active | 1021108 |
| 775177736769834 | Inactive(file) | 351496 |
跟踪配置
data_sources: {
config {
name: "linux.sys_stats"
sys_stats_config {
meminfo_period_ms: 1000
meminfo_counters: MEMINFO_MEM_TOTAL
meminfo_counters: MEMINFO_MEM_FREE
meminfo_counters: MEMINFO_MEM_AVAILABLE
vmstat_period_ms: 1000
vmstat_counters: VMSTAT_NR_FREE_PAGES
vmstat_counters: VMSTAT_NR_ALLOC_BATCH
vmstat_counters: VMSTAT_NR_INACTIVE_ANON
vmstat_counters: VMSTAT_NR_ACTIVE_ANON
stat_period_ms: 1000
stat_counters: STAT_CPU_TIMES
stat_counters: STAT_FORK_COUNT
}
}
}
低内存杀死 (LMK)
背景
Android 框架会杀死应用程序和服务，尤其是后台应用程序和服务，以便在需要内存时为新打开的应用程序腾出空间。这些被称为低内存终止 (LMK)。
注意 LMK 并不总是性能问题的症状。经验法则是，严重性（如：用户感知的影响）与被终止的应用程序的状态成正比。应用程序状态可以从 OOM 调整分数的跟踪中得出。
前台应用程序或服务的 LMK 通常是一个大问题。当用户正在使用的应用程序在他们的手指下消失，或者他们最喜欢的音乐播放器服务突然停止播放音乐时，就会发生这种情况。
相反，缓存的应用程序或服务的 LMK 通常与平常一样，并且在大多数情况下，最终用户不会注意到，直到他们尝试返回应用程序，然后应用程序将冷启动。
这两个极端之间的情况更加微妙。如果缓存的应用程序/服务的 LMK 发生在风暴中（即观察到大多数进程在短时间内获得 LMK），则仍然可能存在问题，并且通常是系统某些组件导致内存峰值的症状。
LowMemorykiller 与 lmkd
内核中的 lowmemorykiller 驱动程序
在 Android 中，LMK 过去由临时内核驱动程序（Linux 的 drivers/staging/android/lowmemorykiller.c）处理。该驱动程序用于在跟踪中发出 ftrace 事件 lowmemorykiller/lowmemory_kill。
用户空间 lmkd
Android 9 引入了一个接管 LMK 职责的用户空间本机守护进程：lmkd。并非所有运行 Android 9 的设备都一定会使用 lmkd，因为内核内还是用户空间的最终选择取决于手机制造商、其内核版本和内核配置。
在 Google Pixel 手机上，自运行 Android 9 的 Pixel 2 起就使用了 lmkd 端查杀。
有关详细信息，请参阅 https://source.android.com/devices/tech/perf/lmkd。
lmkd 发出一个名为kill_one_process 的用户空间atrace 计数器事件。
Android LMK 与 Linux oomkiller
Android 上的 LMK，无论是旧的内核内 lowmemkiller 还是较新的 lmkd，都使用与标准 Linux 内核的 OOM Killer 完全不同的机制。 Perfetto 目前仅支持 Android LMK 事件（内核和用户空间），不支持跟踪 Linux 内核 OOM Killer 事件。 Linux OOMKiller 事件理论上在 Android 上仍然可能发生，但发生的可能性极小。如果发生这种情况，则很可能是 BSP 配置错误的症状。
ui
较新的用户空间 LMK 在 UI 中的 lmkd 轨道下以计数器的形式提供。计数器值是被杀死进程的PID（在下面的示例中，PID=27985）。
SQL
较新的 lmkd 和旧版内核驱动的 lowmemorykiller 事件均在导入时进行标准化，并在即时表中的 mem.lmk 键下可用。
SELECT ts, process.name, process.pid
FROM instant
JOIN process_track ON instant.track_id = process_track.id
JOIN process USING (upid)
WHERE instant.name = 'mem.lmk'
| ts | name | pid |
|---|---|---|
| 442206415875043 | roid.apps.turbo | 27324 |
| 442206446142234 | android.process.acore | 27683 |
| 442206462090204 | com.google.process.gapps | 28198 |
跟踪配置
data_sources: {
config {
name: "linux.ftrace"
ftrace_config {
# For old in-kernel events.
ftrace_events: "lowmemorykiller/lowmemory_kill"
# For new userspace lmkds.
atrace_apps: "lmkd"
# This is not strictly required but is useful to know the state
# of the process (FG, cached, ...) before it got killed.
ftrace_events: "oom/oom_score_adj_update"
}
}
}
应用程序状态和 OOM 调整分数
Android 应用程序状态可以从进程 oom_score_adj 的跟踪中推断出来。映射不是 1:1，状态多于 oom_score_adj 值组，并且缓存进程的 oom_score_adj 范围从 900 到 1000。
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
static final int CACHED_APP_MAX_ADJ = 999;
static final int CACHED_APP_MIN_ADJ = 900;
// This is the oom_adj level that we allow to die first. This cannot be equal to
// CACHED_APP_MAX_ADJ unless processes are actively being assigned an oom_score_adj of
// CACHED_APP_MAX_ADJ.
static final int CACHED_APP_LMK_FIRST_ADJ = 950;
// The B list of SERVICE_ADJ -- these are the old and decrepit
// services that aren't as shiny and interesting as the ones in the A list.
static final int SERVICE_B_ADJ = 800;
// This is the process of the previous application that the user was in.
// This process is kept above other things, because it is very common to
// switch back to the previous app. This is important both for recent
// task switch (toggling between the two top recent apps) as well as normal
// UI flow such as clicking on a URI in the e-mail app to view in the browser,
// and then pressing back to return to e-mail.
static final int PREVIOUS_APP_ADJ = 700;
// This is a process holding the home application -- we want to try
// avoiding killing it, even if it would normally be in the background,
// because the user interacts with it so much.
static final int HOME_APP_ADJ = 600;
// This is a process holding an application service -- killing it will not
// have much of an impact as far as the user is concerned.
static final int SERVICE_ADJ = 500;
// This is a process with a heavy-weight application. It is in the
// background, but we want to try to avoid killing it. Value set in
// system/rootdir/init.rc on startup.
static final int HEAVY_WEIGHT_APP_ADJ = 400;
// This is a process currently hosting a backup operation. Killing it
// is not entirely fatal but is generally a bad idea.
static final int BACKUP_APP_ADJ = 300;
// This is a process bound by the system (or other app) that's more important than services but
// not so perceptible that it affects the user immediately if killed.
static final int PERCEPTIBLE_LOW_APP_ADJ = 250;
// This is a process only hosting components that are perceptible to the
// user, and we really want to avoid killing them, but they are not
// immediately visible. An example is background music playback.
static final int PERCEPTIBLE_APP_ADJ = 200;
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
static final int VISIBLE_APP_ADJ = 100;
// This is a process that was recently TOP and moved to FGS. Continue to treat it almost
// like a foreground app for a while.
// @see TOP_TO_FGS_GRACE_PERIOD
static final int PERCEPTIBLE_RECENT_FOREGROUND_APP_ADJ = 50;
// This is the process running the current foreground app. We'd really
// rather not kill it!
static final int FOREGROUND_APP_ADJ = 0;
// This is a process that the system or a persistent process has bound to,
// and indicated it is important.
static final int PERSISTENT_SERVICE_ADJ = -700;
// This is a system persistent process, such as telephony. Definitely
// don't want to kill it, but doing so is not completely fatal.
static final int PERSISTENT_PROC_ADJ = -800;
// The system process runs at the default adjustment.
static final int SYSTEM_ADJ = -900;
// Special code for native processes that are not being managed by the system (so
// don't have an oom adj assigned by the system).
static final int NATIVE_ADJ = -1000;
参考学习：官方文档
