当前位置:   article > 正文

一款Android性能分析神器!Perfetto(建议收藏)_android perfetto

android perfetto

大家好,我是皇叔,最近开了安卓进阶涨薪训练营第二期,可以帮助大家突破技术&职场瓶颈,从而度过难关,进入心仪的公司。

详情见文章: 皇叔安卓训练营第二期开启啦!

概念

什么是Perfetto?Perfetto是 Android 10中引入的全新平台级跟踪工具。这是适用于 Android、 Linux和 Chrome的更加通用和复杂的开源跟踪项目。与 Systrace不同,它提供数据源超集,可让您以 protobuf编码的二进制流形式记录任意长度的跟踪记录。您可以在 Perfetto界面中打开这些跟踪记录。 Perfetto是一款比较强大的安卓性能分析工具(它还可以用于分析其他系统),其功能涵盖了对 CPU的追踪、电池耗电追踪、系统调用的追踪,内存分配与释放的追踪。除了性能数据记录还,它还有自带的分析工具,分析工具包括:通过自定义追踪功能来拼接命令行,用 SQL方式筛选数据,将数据转换成其他格式方便自定义数据处理, Web形式的火焰图( Web可离线),以及 Web上的 ADB功能(有 bug)。

  • Perfetto的优缺点是什么?

优点:

1.功能强大;

2.效率高;

3.可靠性强。

缺点:

1.只针对Android 9及以上机型;

2.学习门槛略高,至少需要知道些许ADB、Python、LLM、pprof、Perfetto命令行的知识点,才能熟练运用该工具;

3.功能复杂且已嵌入安卓系统中修改难度大;

4.无法过滤so,只能全部分析完了再筛选;

5. 暂时只能在Mac上操作,否则无法解析函数堆栈信息(需要自己编译一个windows的trace-to-text程序);

6. 无对比功能。

  • Perfetto的内存分析原理是什么?

Perfetto:

源码:git clone

https://android.googlesource.com/platform/external/perfetto/

Perfetto也是使用注入( hook)的方式,将内存分配和释放的几个函数修改为自己的代码指令后,当内存分配和释放时进行统计。与 LoliPerfiler不同的是,它有得天独厚的优势,就是它本身就是安卓系统自带的程序,不需要用 JDWP方式启动某个程序,直接启动执行程序就可以了。

系统分析(适用于Liux和Android系统范围分析)

Perfetto-系统分析,应用程序跟踪和跟踪分析。 Perfetto是用于性能检测和跟踪分析的生产级开源堆栈。它提供用于记录系统级和应用程序级跟踪的服务和库,本机+ Java堆分析,使用 SQL分析跟踪的库以及基于 Web的 UI以可视化和探索多 GB跟踪。

Linux内核跟踪:捕获高频 ftrace数据:调度活动,任务切换延迟, CPU频率等等。

用户空间分析器和额外的探针:本机堆分析,Java堆分析,/ proc状态文件的轮询器。

内置于Android:自 Android 9 Pie以来该平台的一部分,也可在 Linux上运行。

应用追踪

raceconv工具将Perfetto跟踪转换为其他跟踪格式。

高效的跟踪点仪器:以高吞吐量,低开销的跟踪点记录C++应用程序的活动。

结构化和可配置的事件:定义自定义protobuf消息以表示强类型的应用程序特定信息,仅跟踪您需要的信息。

与系统范围的跟踪集成:在同一时间线上将应用程序的状态与系统范围内的分析数据相关联。

追踪查看器

heapprofd:Android堆分析器。

此CI用于AOSP的 TreeHugger的顶部(而不是替代)。它提供早期测试信号,并涵盖 TreeHugger不支持的其他操作系统和较旧的 Android设备。

有四个主要部分:

前端:AppEngine

控制器:AppEngine BG服务

工作者:Compute Engine + Docker

数据库:Firebase实时数据库

它们通过Firebase数据库耦合。 DB是整个 CI的真理之源。

交互式痕迹探索:使用Perfetto UI记录,查看和处理跟踪数据。

支持流行的跟踪格式文件:TraceEvent JSON, Android systrace, ftrace文本输出。

完全在您的浏览器中运行:不涉及服务器交互,即使您离线也可以工作。

痕量分析

痕量分析-跟踪处理器是一个C++库( / src / trace_processor),它吸收以多种格式编码的跟踪,并公开一个 SQL接口,用于查询一致的表集中所包含的跟踪事件。它还具有其他功能,包括计算摘要度量,使用用户友好的描述注释跟踪以及从跟踪的内容派生新事件。

基于SQL的跟踪模型:跟踪处理器提取跟踪并公开基于SQLite的接口以通过外壳和UI访问跟踪的内容。

大痕量分析:支持高达数十GB的跟踪。

可互操作的:可以导入和导出流行的跟踪格式:Chromium JSON跟踪格式,Android Systrace, ftrace, CSV。

Perfetto的使用方法

官方说明,CPU分析:

https://perfetto.dev/docs/quickstart/android-tracing#perfetto-cmdline

官方说明,c++内存分析:

https://perfetto.dev/docs/data-sources/native-heap-profiler

使用web界面:

https://ui.perfetto.dev

分析命令行说明:

https://perfetto.dev/docs/reference/perfetto-cli

堆内存分析说明:

https://perfetto.dev/docs/reference/heap_profile-cli

  • 使用系统工具获取跟踪记录

1)在Android 10的手机上,开发者模式新增加了一个“系统跟踪”的功能,我们首先将开发者模式下的“系统跟踪”打开:

2) 从“类别”选项中选择我们关注的信息类别:

3) 设置完之后,下拉快捷选项多了个棒棒糖形状的图标:

这个时候杀掉我们需要调试的应用,然后点击开启棒棒糖,接着打开应用,等待应用完全打开之后,再点击一次棒棒糖,结束录制。

4)我们保存录制后生成的跟踪文件存储在设备的“/data/local/traces”目录下,文件的后缀名为“.perfetto-trace”,我们就可以在网站界面(https://ui.perfetto.dev)中打开这些跟踪记录,进行性能分析了。

  • 使用 Perfetto 网站获取 perfetto-trace 文件

1)打开https://ui.perfetto.dev;

2)点击record new trace;

3)在web站点上选指令,可选择更详细的指令,包括cpu综合数据、gpu综合数据、函数调用堆栈、内存memory分配情况;

4)开始录入,点击start recording,网站自动生成脚本代码,默认是10秒dump一次(或一次性导出);

5)点击stop结束录制,在/data/misc目录下,即可看到生成的.perfetto-trace文件。

  • 使用脚本语言

Android Q及P先设置:

adb shell setprop persist.traced.enable 1

Android Q以上perfetto默认运行,无需上述步骤。

常规选项:

下表列出了在perfetto的两种模式下都可使用的选项:

两种方式,两种方式不能混用:

简单模式:

使用类似与systrace。如果需要设定时间加 -t,默认跟踪 10s。 -o输出文件的位置,使用 /data/misc/perfetto-traces/,否则 perfetto没有权限访问, 然后 pull出文件,在 Perfetto UI中打开使用。如下命令可直接使用,通常这种信息对大多数情况都够用了。

生成.perfetto-trace文件:

adb shell perfetto gfx input view wm am ss sched freq idle binder_driver res rs -o /data/misc/perfetto-traces/trace -t 10s

导出.perfetto-trace文件:

adb pull /data/misc/perfetto-traces/trace ~/trace

普通模式

借助config文件配置要调试的内容,命令行如下,其中 config.pbtx为config file,可以借助 Perfetto UI的 recording setting( Perfetto UI)生成,或者在 Perfetto UI中的 redording settings中设置后好,在 recording command中 copy所有内容,在 terminal中直接 copy执行即可。

cat config.pbtx | adb shell perfetto -c - --txt -o /data/misc/perfetto-traces/trace.perfetto-trace

解析perfetto-trace文件

导入文件

官方网址:

https://ui.perfetto.dev/#!/

打开上述网址,点击Open trace file,选择本地录制好的 perfetto trace或 ftrace等文件,即可以 Timeline方式展现各进程、线程的详细跟踪信息。

当 trace文件大于1G时, Open trace file会出现内存溢出无法访问。

此时需要使用trace_processor来辅助,该程序建议在Linux环境下运行, Win10系统可安装 WSL( Ubuntu20.04),参考附录安装 WSL。

# 下载官方trace_processor:

curl -LO https://get.perfetto.dev/trace_processor

chmod +x ./trace_processor

运行如下命令来加载 perfetto trace文件:

./trace_processor --full-sort -D xxx.pftrace

Windows下也可以运行如下命令(不稳定,内存耗用大):

python3 trace_processor --full-sort -D xxx.pftrace

Chrome浏览器打开 https://ui.perfetto.dev/#!/,会自动检测本地是否已经有 trace_processor生成的 HTTP SERVER( 9001端口),如下图提示,请选择:

“ YES, use loaded trace”,将自动解析 trace_processor已经加载的 pftrace文件。

常规分析

a. 图例指标

slice(片段,选中片段后会显示黑色边框),对应代码中 Trace.beginSection/ATRACE_BEGIN记录的事件。

counter(计数器,离散的数值点) 代码中 Trace.traceCounter/ATRACE_INT记录的事件。

sched/freq( CPU调度、频率)

thread_state(线程状态)

Running),可以看到线程当前运行在哪个 CPU上。

点击向右箭头图标,可以在 CPU调度中看到该运行片段,可以看到调度时延信息。被 P(Process):system_server的 T(Thread):Binder_1754_18线程唤醒,从就绪到运行延迟了 363us,再次点击,可以回到原片段,这个跳转比 systrace更加灵活方便。同样的, Binder调用也可以如此在目标和原调用线程跳转来分析查看。

b. 添加标记

点击最上方的时间轨道即可添加时间点标记;通过按住鼠标左键选中一块区域或者点击某一片段,然后按下“ shift+m”即可添加常驻区域标记。选中已经添加的标记,底部出现的 Current Selection TAB里可以为其添加标记名,更改其颜色,以及执行移除操作。

按下“m”添加的是临时区域标记,再次选中另外一块区域添加临时区域时,上一个临时区域会自动移除。

c. 锁竞争( lock contention)

看到 lock contention片段,可以点击上边的 monitor contention来查看当前对象锁竞争发生的调用栈,如下详情中显示当前对象锁被 Owner( Binder:1754_16)持有,其持锁当前运行在 serviceDoneExecuting( AMS.java 16426行),且当前等待该对象锁的线程已经有2个了;当前线程执行被阻塞在 getUidState方法中( AMS.java 6614行)。

SQL查询与展现

在已经加载 trace的 perfetto UI界面, Search框中输入 : ,即可开启 SQL输入,我们就可以使用 SQL来查询并定位具体的 trace片段( slice)。

输入 SQL语句, Enter,得到查询结果,显示在底部表格中,点击表格中的每一行,可以跳转到具体的 slice中,根据 trace上下文可以进一步分析问题。

列举几个常用的 SQL查询:

1

列出所有doFrame片段,按耗时倒序排列,取前100条

select slice_id,track_id,ts,dur,dur/1e6,name from slice WHERE name like '%doFrame%' order by dur desc limit 100

2

1查询的基础上,指定process name为systemui,即systemui自身的绘帧信息

select slice_id,track_id,ts,dur,dur/1e6,slice.name from slice JOIN thread_track ON slice.track_id = thread_track.id JOIN thread USING(utid) JOIN process USING(upid) WHERE process.name = 'com.android.systemui' and slice.name like '%doFrame%' order by dur desc limit 100

3

system_server中各OPF:关键字片段的耗时信息,包含各片段的真实running_time(每个slice可能有一段时间running,一段时间sleep,一段时间runnable,需要借助thread_state表来查询slice中各调度时间片的状态)

select slice_id,track_id,thread.utid,slice.ts,slice.dur,(slice.dur/1e6) as dur_ms, (select total(case when thread_state.ts < slice.ts then MIN(slice.ts+slice.dur,thread_state.ts+thread_state.dur)-slice.ts when (thread_state.ts+thread_state.dur) > (slice.ts+slice.dur) then (slice.ts+slice.dur-MAX(thread_state.ts,slice.ts)) else thread_state.dur end) from thread_state where thread_state.utid=thread.utid and thread_state.state='Running' and thread_state.ts < (slice.ts+slice.dur) and (thread_state.ts+thread_state.dur) > slice.ts)/1e6 as total_running,slice.name from slice JOIN thread_track ON slice.track_id = thread_track.id JOIN thread USING(utid) JOIN process USING(upid) WHERE process.name='system_server' and slice.name like 'OPF:%' order by slice.dur desc limit 400

4

system_server中的锁竞争情况(lockcontention),lock_depth表示当时参与此对象锁竞争的线程个数

select count(1) as lock_depth, s.slice_id,s.track_id,s.ts,s.dur,s.dur/1e6 as dur_ms,ctn.otid,s.name

from slice s, (select slice_id,track_id,ts,dur,name,substr(name, 46, instr(name,')')-46) as otid

from slice t

WHERE name like 'Lock contention on a monitor lock %'

order by dur) ctn

JOIN thread_track ON s.track_id=thread_track.id JOIN thread USING(utid) JOIN process USING(upid)

WHERE

process.name = 'system_server'

and s.name like 'Lock contention on a monitor lock %'

and substr(s.name, 46, instr(s.name,')')-46) = ctn.otid

and ctn.slice_id <> s.slice_id

and ctn.ts >= s.ts and (ctn.ts+ctn.dur) <= (s.ts+s.dur)

group by s.slice_id

order by s.dur desc

应用实战

来一个简单例子,模拟卡顿现象,代码如下:

从 log立可以看出损耗的相关代码:

进入perfetto,导入trace文件,界面如下,找到对应的包名线程:

能看到 onResume方法阻塞 了4s的样子,这样能在具体的类里尽快定位产生耗时的方法,其余的功能可以具体分析。

项目实际应用

由于 android手机日益更新换代,现在折叠屏手机已经面市,搜狐视频要根据折叠屏幕尺寸不同变化适配不同的 UI展示,这次的需求。

是手机界面展示成这样:

折叠屏展开后展示成不同样子:

结果发现只要手机展开就会无响应,然后就 crash崩溃, log里也没啥有用信息,实在不好定位问题,百思不得其解,最后想到用 Perfetto看看有没有什么有用信息,按照上述步骤得到 trace文件,导入界面如下,找到搜狐视频的包名线程,可以看到:

上千次执行RV onBindView方法,在代码里找到对应位置,发现是2个xml的UI都在刷新,所以导致图片View加载混乱,所以一直重复刷新,修改后切换界面就正常了,长叹一口气,问题圆满解决,鼓掌撒花~

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/知新_RL/article/detail/812837
推荐阅读
相关标签
  

闽ICP备14008679号