Perfetto工具集之traced_perf

1.Perf工具概览

linux中包含了众多性能分析工具，perf（特指linux-tools perf）工具是2009年在linux内核2.6.31中引入的一个工具。它的主要功能是可以跟踪hardware performance counter(PMU)、tracepoints、software performance counter(hrtimer)、dynamic probes等信息。linux内核将这些信息进行封装，通过syscall（perf_event_open等）的形式提供，使之抽象为events的概念，可以供userspace的进程使用。perf作为一个linux下的命令行工具，可以读取这些events，并结合性能分析的场景，提供了诸如stats、top、record、report等子工具命令，适配更细化的分析需求。

Android中一般使用的并不是老牌的linux-tools perf工具，而是使用经过Android客制化的perf工具，用于支持Android中拓展的一些feature。

• simpleperf:

Android最早于Android 6.0(2015年)中引入，距今（2022年）已经有7年的历史。其主要作用就是实现Linux中perf工具的基本功能。

• traced_perf:

Google于2019[在2019年开始开发][修改了一下]年开始开发，其作为perfetto的一个consumer而不是单独的一个项目去开发的。其开发目的是能够：

a.利用perfetto的成熟平台，提供profiling、unwinding、UI等各方面的能力

b.伴随着Android权限管控的愈发严格和MAC的要求，原Simpleperf的独立selinux domain完成所有功能的方式已经无法满足sandbox的需求，需要进行严格的domain隔离

本文着重讲一下traced_perf。

2.traced_perf的结构

2.1.代码结构

traced_perf的代码位于AOSP的external/perfetto/src/profiling/perf/ 目录下，可以看出，traced_perf的代码实际上是perfetto项目的一个子目录。

此目录下的代码如下图：

可以看出代码分为三类：

• 编译脚本相关: BUILD.gn
• 单元测试相关:X_unittest.cc
• 主要代码逻辑

除了上述的代码目录外，在perfetto的主目录下还存在文件：external/perfetto/traced_perf.rc

此文件是traced_perf可执行文件的启动脚本。

2.2运行时结构

根据external/perfetto/Android.bp的编译脚本可以看出，traced_perf最终会被编译为一个可执行文件，并且被install到/system/bin/traced_perf。此可执行文件以daemon的形式存在，其启动和结束受它对应的rc启动脚本的控制。

其运行时的生命周期可以通过traced_perf.rc文件去分析：

• traced_perf的权限配置

?traced_perf的用户设置为了nobody，可以确保权限不会影响到其他用户，避免被恶意破解后获得提权

?traced_perf的组包含nobody、readproc、readtracefs三个，readproc是为了使之被赋予可以读取/proc/PID目录的权限，readtracefs是为了赋予其读取tracefs mount的目录的权限，这两个权限是traced_perf能够正常运行所必须的权限。

?traced_perf赋予了相应的capability，分别为KILL，DAC_READ_SEARCH。KILL是为了使traced_perf能够给其他进程发送信号。DAC_READ_SEARCH是为了使之能够至少能够获取一些文件的权限，而不至于甚至不能够探测某些文件的存在。这两个权限都是traced_perf正常运行所必需的。

?task_profiles是为了给traced_perf设置为高capacity（unwinding）的一类cgroup，从而使得调度器可以给予其更合理的资源分配。

• traced_perf的资源

traced_perf申请了一个名为traced_perf的unix_socket，此unix_socket是traced_perf与待profiling的进程间通信的通道，后续章节有涉及。

• traced_perf的生命周期管控

traced_perf的生命周期管控通过property trigger来完成。当设置persist.traced_perf.enable 为true的时候，会自动启动traced_perf。同时，它还会受到sys.init.perf_lsm_hooks和traced.lazy.traced_perf的管控。

3.traced_perf的架构

3.1perfetto的框架

traced_perf作为perfetto工具集的一个组成部分，其遵循perfetto的service model的。perfetto的service model如下图所示：

3.1.1producer

traced_perf作为Tracing service的producer，其和tracing service的交互由两条通道，分别是IPC channel和shared_memory，其中IPC channel为unix socket，后面有详细描述。

shared_memory是指与tracing service之间建立的共享内存通道，此共享内存通道有两个作用：

1.进行高效的进程间数据传递，这里传递的主要是结构化的采样点数据。

2.与控制流进行隔离，避免被恶意破解后造成安全隐私风险。

traced_perf本身作为producer端，提供了Data Source，每个producer可以提供多种Data Source。traced_perf本身对外提供的Data Source包含linux.perf 和一个metadata的Data Source。后续我们对此Data Souce展开详细的描述。

3.1.2Tracing Service

Tracing Service作为perfetto在手机端的核心服务，其承担了主控的作用。Tracing Service在手机端主要表现为traced进程，它一方面接收consumer的配置文件的控制，另外一方面将配置文件转化为对Producer的控制；同时还承担了producer端与consumer端的桥梁。producer端与consumer的数据通道采用了trace buffer内存，这部分内存是没有进行进程间共享的，从而可以保持数据的隔离。

3.1.3Consumer

consumer端是指对perfetto trace类数据的消耗端，比如perfetto ui、shell command、traceur等，consumer端还可以进行自定义，在Android中添加客制化的consumer，从而对Data Source进行客制化的处理。

consumer端和Tracing Service的IPC通道主要也是通过unix socket进行连接的。

3.2traced_perf与perfetto的交互

3.2.1整体流程

整体流程示意图如下，读者可以根据此流程理解。交互流程涉及到Perfetto内部的众多类的实现，建议读者优先理解涉及到的C++类的声明与函数实现，而不要刚开始就陷入到调用流程的跟踪中，避免陷入到多层嵌套的复杂逻辑中。当把几个关键类的功能和对外关系理清楚之后，再通过调用关系依次跟踪调用流程。

• PerfProducer:

调用ConnectService建立连接流程

实现OnConnect流程

实现OnTracingSetup、StartDataSource等函数

• ProducerEndPoint

创建建立进程间通信的必要对象

实现OnConnect

• ClientImpl

建立Socket连接

实现onConnect、onDataAvaliable等

通过上述流程拆分可以看出，每个类的职责都是非常清晰的。

3.2.2IPC通道建立

对于traced_perf来讲，建立IPC通道由下面几个重要流程：

1.实例化task_runner和AndroidRemoteDescriptorGetter。task_runner是traced_perf中使用的一个Looper工具类实例，AndroidRemoteDescriptorGetter是traced_perf为了获取想要trace的应用的私有进程数据而建立的一个类。后续章节有相关描述。

2.与Tracing Service建立连接

3.启动消息循环

3.2.3IPC通道框架

IPC通道的框架相对来说比较复杂，本小节进行一个原理剖析。

• TaskRunner: 是一个Looper interface，PerfProducer使用的实例是基于unix domain socket实例化的TaskRunner。此task_runner_在各个结构间传递，承担了各类消息的派发和处理。
• ProducerEndPoint: 是Tracing service的producer端的接口类，通过ProducerIPCClientImpl得以实例化。

为了能够将PerfProducer类注册为Tracing Service的producer，需要执行如下操作：

其中，ProducerIPCClient::Connect是一个静态方法，其实例化了ProducerIPCClientImpl并将其以unique_ptr的形式返回。

上述流程走完之后，实际上就建立了PerfProducer的事件处理流程。

关注到ConnectService中，ProducerIPCClient::Connect中的第二个参数是this指针，实际上是把PerfProducer的对象指针传递给了ProducerEndpoint对象，它是通过ProducerIPCClientImpl构造函数中的第三个参数producer传递过去的。

3.2.3.1相关概念

• DataSource

顾名思义，这个是数据源的意思。根据Perfetto的框架图，consumer端需要指明从哪个“数据源”收集数据，而Producer可以提供数据源。数据源在perfetto中的定义以proto的形式进行了规定，在PerfProducer中，它对数据源的定义进行了抽象，通过DataSourceState进行描述。

与DataSource相对应的一个数据结构是traced_perf里面的DataSourceState的结构，可以看到DataSourceState中维护了一个TraceWriter指针，此TraceWriter提供了写入Trace数据的相关方法。

3.2.3.2TraceWriter

TraceWriter类是为了让使用者可以在perfetto的共享内存中，以零拷贝的形式写入Trace数据，方便使用者高效写入Trace数据。

• NewTracePacket

创建一个TracePacket并返回一个handle

• FinishTracePacket

完成之前创建的TracePacket

• Flush

将TracePacket刷入到service端

3.2.3.3IPC消息的接收

ProducerEndPoint对象会通过PerfProducer对象提供的service_sock_name与PerfProducer进行通信，当连接建立之后，就进入了IPC流程，服务端会将消息按照perfetto定义的协议格式发送对应的指令。消息协议如下：

上述消息会被ProducerEndPoint解析，并最终转化为Producer接口类的虚函数调用（注意到ProducerEndPoint维护了一个Producer(PerfProducer)实例的指针）。

Producer的实例需要实现如下接口：

• OnConnect

当与Tracing Service建立Socket连接后会被调用

• OnDisconnect

当与Tracing Service断开Socket连接后会被调用。此时可以销毁PerfProducer对象了。

• OnStartupTracingSetup

当第一个DataSource被创建之前被调用，可以做一些初始化的工作。

• SetupDataSource

设置DataSource时被调用，其传递的参数包含DataSourceInstanceId以及DataSourceConfig

• StartDataSource

启动DataSource

• StopDataSource

停止DataSource

• Flush

Tracing Service要求Producer将数据写入到共享内存中。

• ClearIncrementalState

Producer端应该在此调用后，停止引用之前写入到共享内存的数据。

3.2.3.4IPC消息的发送

ProducerEndPoint提供如下接口：

• Disconnect:

用于与ProducerEndPoint断开连接，此时不再能收到来自于Service端的回调消息。

• RegisterDataSource

注册DataSource

• UpdateDataSource

更新DataSource

• RegisterTraceWriter

注册TraceWriter

• CommitData

通知Tracing Service shared memory中的数据已经更新。

• CreateTraceWriter

创建TraceWriter

• 其他同步方法

4.traced_perf的事件处理

上一章节中，我们讨论了traced_perf与perfetto的框架的关系，本章节中着重阐述traced_perf在perfetto producer框架下，如何实现其作为perfetto的一个producer，达到profiling进线程counter信息、获取调用栈、分析性能问题的目的的。

上一章节中，描述了trace_perf 通过IPC通道从tracing service进行事件接收，这些事件最终转化为了Producer的重写函数，那么traced_perf作为tracing service的producer，需要实现这函数从而完成整个流程。

图中方框里面的是PerfProducer的事件处理状态，连接线上的字是traced_perf中发生的事件或者通过IPC接收到的命令。

4.1onConnect的实现

onConnect的实现非常简单，首先设置连接状态的状态机为“kConnected”状态，其次实例化了两个名字分别为“linux.perf”与“perfetto.metatrace”的DataSourceDescriptor，然后通过endpoint_指针的RegisterDataSource方法进行DataSource注册，其中endpoint_即为上一章节中提到的ProducerEndPoint对象的指针。

4.2StartDataSource的实现

StartDataSource的参数有两个，分别是DataSourceInstanceID和DataSourceConfig，其中DataSourceInstanceID是一个唯一的无符号64位的id，用来标识DataSource的实例；DataSourceConfig是data_source_config.proto生成的protobuf类，其原型可以参考：https://cs.android.com/android/platform/superproject/+/master:external/perfetto/protos/perfetto/config/data_source_config.proto;l=1;bpv=1;bpt=0

4.3启动MetaTraceSource

通过endpoint_智能指针，调用CreateTraceWriter方法，创建一个TraceWriter对象。同时将此metatrace进行使能，并保存到metatrace_writers_维护的一个map结构中。

4.4tracepoint与id的mapping的lookup操作

tracepoint一般是以名字的方式提供给配置文件的，但是linux kernel中一般使用其对应的id进行API访问控制，因此这里需要一个映射的提取。一般来说，此id可以通过位于tracefs的events/GROUP/NAME/id文件中可以提取出来。

4.5打开perf event对应的eventfd

首先将pb格式封装的配置文件转化为perf_event_attr数据结构，之后调用linux kernel提供的系统调用向操作系统注册。

打开perf event所必须的linux syscall为perf_event_open，此API的参数比较复杂，详细介绍可以参考官方文档：https://man7.org/linux/man-pages/man2/perf_event_open.2.html

这里着重讲解一下关键的配置信息：

?perf_event_attr

perf_event_attr是一个比较大的结构体，包含了对perf_event配置的各种属性信息，以比较简单的tracepoint事件为例，一般来说需要设置以下必须的字段：

type: 设置为PERF_TYPE_TRACEPOINT类型

size: 设置为sizeof(perf_event_attr)

config：设置为上一步中获取到的mapping的id信息

sample_type: 设置sample中包含的数据类型

read_format：设置read返回的数值中包含的数据类型

开关bitmask配置：包含是否包含mmap的数据，是否包含comm等近30个配置项

pid

获取哪个pid的perf event事件

cpu

获取哪个cpu的perf event事件

groud_fd

可以将多个events通过同一个event fd进行返回，可以将其中一个事件传入-1作为group leader，后续事件可以将返回的fd传入此参数中。

4.6创建TraceWriter并使能perf event

4.7通知Unwinder启动了DataSource

4.8启动周期性读取任务

周期性的读取任务，主要是从内核的共享内存中，获取perf event的数据。在后续的章节中我们会着重讲述获取的数据。

在TickDataSourceRead函数中的ReadAndParsePerCpuBuffer中，会将从内核的共享内存中读取的sample数据，推送到unwinding_worker的queue中。当调用PostProcessQueue时，会唤醒unwinding_worker对应的线程，并执行unwind操作，直到所有sample都unwind完毕。

若DataSource的状态未停止，则需要继续抓取更多的samples，因此在这个task中，又继续调用了延迟任务，继续让task_runner调度本任务。

5.Sample的获取

Sample事件的获取是从Linux内核中提供的ring buffer共享内存中获取的，这部分操作位于PerfProducer::ReadAndParsePerCpuBuffer中进行的，这部分操作相对来说比较繁琐，下图中截取了一部分。其基本的流程是：

循环通过EventReader的ReadUntilSample获取解析好的Sample，如果DataSource的config中有配置一些filter项，则筛选掉不感兴趣的Sample，直到没有Sample产生了或者已经获取到足够的Sample了。

5.1PerfRingBuffer之环形缓冲区数据的获取

回顾一下perf_event_open函数的原型：

int syscall(SYS_perf_event_open, struct perf_event_attr *attr, pid_t pid, int cpu, int group_fd, unsigned long flags);

其中perf_event_attr结构中包含了众多的配置参数。跟通过ring buffer获取sample相关的参数有以下几个配置：

• sample_period/sample_freq: 指明多久获取一次sample。
• sample_type: 指明什么类型的数据会包含在sample中，比如Instruction pointer、TID、Sample的时间、地址信息等

通过perf_event_open返回的文件描述符，可以进而通过mmap系统调用，返回一个Kernel与Userspace共享的内存地址空间，此内存地址中的数据一般由Kernel写入，Userspace的程序负责对其进行解析。mmap的共享内存地址的分布如下：

metadata页对应的数据结构如下：

• data_head: 指向数据区的首地址，这个地址是持续自增加的，在使用它的时候，需要将其地址与mmap buffer的大小进行一个wrap操作。
• data_tail: 此数据是需要由userspace写入，指明userspace最后读取的数据的位置，从而使得内核不会降未读取的数据覆盖。
• data_offset: perf_sample的起始位置由此述职来确定。
• data_size: 包含了perf_sample区域大小信息

由Linux内核提供的perf sample也包含固定的格式，每个perf sample的数据原型如下：

注意到上述结构右边的if注释，假如对应的选项没有在sample_type中配置，则不包含对应的字段，在解析sample的时候，值的注意。

perf_event_header是每个sample的头信息，它的定义如下：

• size: 本perf sample的大小
• misc：包含本sample的一些额外的信息
• type: 不同的sample类型，只有类型为PERF_RECORD_SAMPLE时，才有上面的perf sample的数据结构。比如当其类型为PERF_RECORD_LOST时，对应的perf event的数据结构为

5.2EventReader之Sample的解析

5.2.1perf sample的读取

perf sample的获取实际上是在对环形缓冲区的读取，环形缓冲区的包含一个读取偏移量以及一个写入偏移量。其中写入偏移量是由内核负责写入的，只要读取偏移量小于写入偏移量，则说明环形缓冲区中仍有数据未读取。

这里注意到环形缓冲区实际上是可以出现回卷操作的，假如出现了回卷操作，需要将数据进行重组。

5.2.2Perf sample的解析

perf sample本身的解析工作是通过EventReader::ParseSampleRecord进行的。解析后的数据结构为ParsedSample，其定义为：

可以看出，traced_perf关注的信息包含：

• CommonSampleData: cpu_mode, cpu, pid, tid, timestamp, timebase_count等信息
• regs: 用作unwinding的userspace寄存器信息
• stack: userspace栈信息
• kernel_ips: 内核instruction pointer信息

下面是Sample解析的具体流程

上述函数会返回解析好的Perf sample，即ParsedSample。进行一系列的筛选逻辑后，此sample会被发送到unwindwing_worker提供的queue中，以便于进行后续的unwinding操作。

至此，所有从内核中所需要的perf event信息已经收集并解析完毕，下一步是将之转化为可读的callstack信息的流程，这离不开unwinding 操作。

6.Unwinding操作

unwinding操作发生在解析完perf event sample之后，其发起动作的调用为：

其主要处理逻辑位于Unwinder::ConsumeAndUnwindReadySamples函数中。

当unwind成功后，调用到PerfProducer中的PostEmitSample中，将unwinding之后的数据写入TraceWriter。

6.1内核栈的解析

内核栈的解析相对简单，其主要操作函数再Unwinder::SynbolizeKernelCallchain中。其主要原理是解析"/proc/kallsyms" 中的内核地址与符号之间的对应关系。根据对应关系，将sample中的kernel态的instruction pointer翻译成地址信息。kernel 态的地址信息介绍见之前章节。

6.2用户栈的解析

用户栈的解析相对复杂，用户栈的解析首先要获取几个必要的信息：

1. Userspace寄存器信息
2. Userspace栈信息
3. /proc//mem信息
4. /proc//maps信息

其中前两个信息已经通过之前的Sample解析操作成功获取了，那么第3、4个信息怎么获取呢？

在之前的Android版本中，特权进程是可以直接访问到对应pid的这两个信息的，随着Android对安全隐私的越来越重视，对不同进程的敏感信息进行了比较强的隔离。因此traced_perf为了获取此信息，必须按照符合Android安全设计的机制，以相对复杂的方式进行实现。

6.2.1traced_perf如何请求目标进程的maps和mem信息

在AndroidRemoteDescriptorGetter类中，实现了获取/proc//mem以及/proc//maps操作的动作，获取操作是通过发起signal操作来完成的，signal的目标是目标进程：

而信息的接收是通过socket来完成的，即traced_perf进程刚启动时创建的socket:

在此socket的数据收取操作中，获取到上述两个文件的文件描述符（文件描述符已经经过内核态转换，可以在traced_perf进程中正常使用）。

上述代码中的delegate实际上指向的是PerfProducer对象，因此delegate_->onProcDescriptors会将两个文件描述符发送给PerfProducer对象。而PerfProducer进而将此文件描述符发送给了UnwinderHandle对象。

6.2.6目标进程如何将maps和mem信息发送给traced_perf

如前面所述，traced perf通过signal通知的目标进程，让目标进程将文件描述符进行了发送，那么目标进程为什么都会响应这类信息呢？（目标进程可能非常多样，包括daemon、系统apk、三方apk等），答案在C库中。

当目标进程接收到信号后，通过unix socket与traced_perf进程建立连接，然后打开两个文件maps和mem，通过unix socket的sendmsg进行发送。关于通过unix socket发送文件描述符，可以参考文档：https://man7.org/linux/man-pages/man7/unix.7.html，这里不做详细描述。

上述代码在android_profiling_dynamic.cpp中，会编译成C库的一部分，并被大多数进程所加载。

到此为止，用户栈的所有所需信息均已准备完毕。

6.2.3用户栈的解析

将所有信息准备好后，真正解析用户栈可以直接通过libunwindstack提供的方法Unwinder::Unwind即可了，反而流程显得很直接。

7.Sample的写入

Sample数据写入到trace中的操作也是比较直接的，将前面流程中获取到的信息，通过TraceWriter返回的TrackPacket protobuf结构进行写入即可。

至此，整个traced_perf的获取sample的执行流程大概完成了。

8.总结

traced_perf的工作流程主要部分包括：

• perfetto流程的嵌入：traced_perf是perfetto的producer
• Sample的获取
• Unwinding操作

这三项主要内容看似复杂，实际上整体结构也是比较清晰的。Perfetto已经将tracing、profiling的框架打通，Tracing producer要接入perfetto，也是一件按部就班的事情而已。

9.参考链接

TracedPerf源码: https://cs.android.com/

traced_perf相关文档: https://perfetto.dev/docs

perf历史: https://en.wikipedia.org/wiki/Perf_(Linux)

simpleperf相关文档: https://android.googlesource.com/platform/prebuilts/simpleperf/+/782cdf2ea6e33f2414b53884742d59fe11f01ebe/README.md

perf_event_open: https://man7.org/linux/man-pages/man2