简介Android Simpleperf 开源代码包面向安卓系统开发者与性能优化工程师帮助他们深入理解基于内核 perf 事件框架的用户空间性能分析工具。该压缩包约62.98MB核心源码以C文件与安卓构建蓝图为主涵盖性能数据采集、报告生成、统计输出和硬件跟踪解码等模块。其中记录模块负责命令行接口与采样逻辑报告模块完成数据解析与样本级分析统计模块提供CPU利用率等关键指标动态库与运行环境相关代码处理符号映射ETM解码部分面向特定处理器的高级事件追踪。当前已有184人学习下载说明项目对性能调优学习者具有一定参考价值。通过研究这些源码开发者可掌握Simpleperf的工作原理学会使用内核perf事件创建自定义采样事件、解析复杂性能数据并利用跨进程与线程分析能力优化应用和系统服务。对于希望定制性能分析工具或深入安卓性能调试的开发者这是一份难得的开源学习资料。1. 为什么Android性能优化绕不开simpleperf这个tar.gz如果你做过Android平台上的性能分析大概率见过类似extras-master-simpleperf.tar.gz这样的压缩包。我第一次拿到这个包的时候也挺懵名字看起来像某个开源项目的附属品但打开之后才发现里面装的是Android原生性能分析领域非常关键的一套工具集。简单说simpleperf是Android平台上的CPU性能剖析工具本质上是Linux内核perf工具在Android上的移植版本。它随Android NDK一起发布官方路径在ndk/simpleperf目录下而网上能搜到的extras-master-simpleperf.tar.gz通常是某个源码仓库中extras目录下的打包版本。不管来源是哪核心内容一致一套可以在Android设备上做CPU采样、函数热点统计、调用栈分析以及性能对比的命令行工具外加Python封装脚本和火焰图生成脚本。为什么它重要因为Android平台的性能优化经常卡在一个问题上——你大概知道App整体CPU占用高但说不清到底是哪个线程、哪个函数在烧电。adb shell top只能看到进程级别的粗粒度数据TraceView和Android Studio Profiler对Java层的分析还行一旦涉及C/C代码、游戏引擎渲染线程、图片解码、FFmpeg音视频处理这类native负载它们就显得力不从心。simpleperf做的事情就是把采样粒度压到函数级别让你精确看到时间都消耗在哪一行代码上。我当初使用它是因为负责的一个Unity手游项目在低端机上发热明显Unity Profiler只显示CPU占用飙到了80%多但无法定位到具体是哪个C插件函数在作祟。后来用simpleperf做了一次30秒的采样火焰图一出来问题一目了然一个音频解码库的混音函数占了将近35%的CPU时间。这种定位效率在纯靠看日志猜的阶段是难以想象的。所以这篇我用自己的实操经验把simpleperf从解压到上手分析的全流程以及那些文档里不会写清楚的坑一次讲透。无论是做Unity游戏优化、音视频SDK开发还是普通Android应用里带有大量native代码的性能排查这套东西你都值得掌握。2. 压缩包解开之后先搞清楚里面有什么2.1 目录结构和每个脚本的真实用途拿到包后第一件事先别急着跑命令花几分钟看目录结构。simpleperf的打包版本里通常包含以下几个核心组成部分我用表格梳理一下文件/目录真实用途bin/android/按架构分好的simpleperf可执行文件如arm64-v8a、armeabi-v7a、x86、x86_64app_profiler.py自动化采样脚本自动push可执行文件到设备、设置权限、跑采样、拉取报告最常用report.py把采样得到的perf.data转换成可读报告、火焰图annotate.py把采样结果关联到源代码行号做逐行热点标注simpleperf_report.py另一个报告生成入口老版本中常见新版整合进了report.pybinary_cache/脚本自动生成的符号缓存目录用于存放App中native库的带符号版本*.sh一些辅助脚本比如run_simpleperf_on_device.py等注意新版NDK里simpleperf已经不再需要手动分离可执行文件app_profiler.py会自己处理。但网络上下载的extras-master源码包不会假设你的设备上装有特定版本的NDK所以脚本里的NDK_DIR或者ANDROID_NDK_HOME路径需要自己设置。2.2 选对架构和Android版本sampleperf在Android 5.0API 21及以上的设备上原生支持。如果你的目标是低端机注意Android 8.0以下对采样事件的支持有限部分硬件计数器不可用但基础的CPU周期采样和任务时钟采样是没有问题的。架构这块容易踩坑。现在的设备绝大多数是arm64-v8a但如果你的App里还有32位so库或者你用的测试机是老的armeabi-v7a设备就需要把对应的bin/android目录下的可执行文件push到设备上。app_profiler.py有-p参数指定包名有-abi参数指定架构建议直接指定避免脚本猜错。2.3 别忘了Python环境这个隐性门槛带tar.gz后缀的发布包多半会附带Python脚本simpleperf也不例外。脚本依赖Python 3且需要能够访问adb。官方文档推荐用Python 3.6我实测Python 3.8、3.10都能顺畅跑。但在macOS上跑的时候碰到一个很隐蔽的问题如果你用homebrew自带的Python某些脚本会提示找不到pylib模块——因为脚本用相对路径导入同目录下的Python模块当你从其他目录调用脚本时需要把simpleperf目录加入PYTHONPATH。一个可靠的通用做法是export ANDROID_NDK_HOME/path/to/your/android-ndk-r26d export PATH$PATH:$ANDROID_NDK_HOME/simpleperf/bin/darwin/x86_64 export PYTHONPATH/path/to/simpleperf:$PYTHONPATH如果你更习惯用conda管理的Python环境也没有问题。在conda环境里创建一个干净的Python 3.8环境像下面这样conda create -n perf_env python3.8 -y conda activate perf_env pip install pyperf # 可选部分版本脚本需要然后在这个conda环境里运行simpleperf的Python脚本。这里有一个特别容易忽略的细节脚本调用adb时走的是系统PATH里的adb跟Python环境无关。如果脚本报adb not found先检查你的adb有没有加入PATH而不是怀疑Python环境。conda虚拟环境和系统环境在这个问题上互不干扰但也意味着两边要分别配置好。我自己的习惯是把adb路径也加入PATH然后把simpleperf目录下的Python脚本做个软链接到/usr/local/bin这样无论哪个conda环境都能直接调用省得每次激活环境都要重新设置路径。3. 第一次采样从设备连接到火焰图3.1 用app_profiler.py跑通自动化流程这是最省心的一条路。假设你的应用包名是com.example.myapp手机通过USB连接电脑且开启了USB调试步骤如下# 进入解压后的simpleperf目录 cd extras-master-simpleperf # 拉起App并自动采样30秒 python app_profiler.py -p com.example.myapp -a .MainActivity \ -apk /path/to/your-app.apk \ -r record \ --duration 30参数解释一下-p包名后面-a指定启动的Activity如果App已经在运行可以不加-a只做attach采样。-apk指定APK路径脚本需要解析APK来找到native库并建立符号映射。-r record表示执行采样也可以用-r stat执行计数统计模式只出汇总数据不出调用栈。--duration采样时长单位是秒。跑完之后会在当前目录生成perf.data和binary_cache目录。注意看脚本的日志输出它会自动把simpleperf这个可执行文件push到设备的/data/local/tmp目录并赋予执行权限。如果你在Android 12设备上跑可能会遇到权限问题脚本会提示你通过adb shell手动配置这种情况我们放到最后一部分专门说。3.2 手动采样不依赖脚本的原始命令脚本虽然方便但偶尔会有不够灵活的时候。比如你想在App运行的某个具体阶段采样或者需要多次采样对比这时候手动操作反而更好。先把simpleperf可执行文件推到设备上adb push bin/android/arm64-v8a/simpleperf /data/local/tmp/ adb shell chmod 755 /data/local/tmp/simpleperf然后先启动App进入目标场景再执行# 按应用名过滤采样 adb shell /data/local/tmp/simpleperf record -p $(pidof com.example.myapp) --duration 20 -o /data/local/tmp/perf.data这里-p后面跟的是进程PID不是包名。通过pidof动态获取省去手动查看的麻烦。采样完成后把数据拉回电脑adb pull /data/local/tmp/perf.data3.3 生成报告和火焰图有了perf.data就可以用脚本生成报告了# 生成文本报告 python report.py --kallsyms --symbols-dir binary_cache # 生成火焰图 python report.py --kallsyms --symbols-dir binary_cache --flamegraph--kallsyms表示从设备的内核符号表中读取内核符号这对分析内核态调用栈很重要不加的话内核相关热点会显示为地址。--symbols-dir指定符号缓存目录脚本会用binary_cache里的带符号so库把采样到的地址翻译成函数名。火焰图生成后会输出一个flamegraph.html文件浏览器打开就能看到横轴是采样次数占比纵轴是调用深度函数块越宽说明占用的CPU时间越多。这个图是整个分析流程中最直观的一环一眼就能定位到热点函数。这里补充一个实操中常见的问题新版脚本可能找不到--flamegraph参数但你可能还是想生成火焰图。替代方案是用simpleperf report输出文本报告然后手动用FlameGraph开源脚本转换。不过更省事的办法是用report.py的-o参数导出文本报告再用stackcollapse-perf.pl处理成火焰图脚本需要的输入格式。具体命令长这样python report.py --kallsyms --symbols-dir binary_cache -o report.txt这样生成的report.txt可以直接查看每一行是调用采样占比 函数名和调用栈信息。4. 从报告到优化决策数据到底怎么读4.1 Self、Total和Children的含义拿到文本报告后很多新手会盯着最上面的几行看但这个表有一个容易误读的地方。simpleperf的文本报告包含几个关键字段Self当前函数的执行时间占比不包括它调用子函数的耗时。这是衡量单个函数本身代码效率的核心指标。Children当前函数及其所有子函数消耗的时间总和占比。这是衡量以该函数为根的调用链整体开销的指标。判断优化价值时要两条腿走路。比如某个函数Self只有5%但Children是40%说明它本身不慢但它带着一堆子调用整个调用链占了40%的CPU。这种情况下优化点往往要往下游找看看它调用的子函数里哪些是真正昂贵的。反过来如果一个函数Self占到20%Children也只占20%说明它自己就是热区直接优化它的内部实现收益最明显。我在实际项目中遇到过这样一个例子一个纹理上传函数Self接近30%Children也差不多。代码注释显示作者担心它慢但实际上问题出在每次上传前都调用了一次glGetIntegerv来查询当前绑定纹理这个查询太费了。删掉后函数的CPU占用直接降到12%。这种数据指示的价值就是你优化方向的“导航仪”。4.2 用调用栈定位真实根因只看聚合报告容易犯一个错误把表面热点当根因。采样数据中的调用栈信息才是分析链路的关键。举个例子你看到memcpy的Self占比很高但这不代表你去优化memcpy本身。正确的做法是看memcpy的调用者是谁——是std::string的拷贝构造还是某个图片解码库的缓冲区复制或者是自研代码里的频繁小对象拷贝。跟前端监控一样热点函数的调用者往往是真正的“幕后黑手”。在使用simpleperf时我推荐用火焰图来看调用链而不是纯文本的调用栈列表。火焰图里横向宽度代表时间占比纵向显示调用关系。找准一条最宽的“山顶到底部”的路径就能还原出耗时最多的完整调用链。路径上越靠上靠近栈顶的宽块是直接执行者越靠下的宽块是调用源头的责任方。4.3 用对比分析验证优化效果优化做完了怎么证明有效simpleperf还能做两个场景的对比采样。做法是分别记录优化前后的perf.data# 优化前 python app_profiler.py -p com.example.myapp --duration 30 -o before.perf.data # 优化后先卸载重装App再重新采样 python app_profiler.py -p com.example.myapp --duration 30 -o after.perf.data然后使用report.py的对比模式或者把两份perf.data分别生成报告对比同一个函数的占比变化。我常用的方式是直接盯热点函数的Self占比变化同时观察总CPU使用率是否下降。如果函数占比降了但整体CPU没变说明热点“转移”到了别的地方优化并未真正生效。这种“转移”经常发生在缓存优化、结构体调整之后数据会诚实地告诉你——你把锅从A端挪到了B端。另外一个提高对比可信度的小技巧控制变量。两次采样尽量在同一台设备、同一个App版本、同一个操作路径下进行差异条件只留“是否应用优化”。手机的电量、温度会影响CPU调度最好在采样前重启设备把后台程序清干净。5. 实战中绕不开的坑逐个说清楚5.1 符号表缺失报告里全是地址第一次用的时候我兴冲冲采样完打开报告发现全是0x0000007f12345678这样的地址函数名一个都没有。原因很简单设备上的App里的so库是strip过的不含符号表。App在Release包中通常会移除调试符号simpleperf拿到的是装载进内存的二进制没有符号信息就翻译不出函数名。解决方案就是前面提到的binary_cache。app_profiler.py在做采样前会从APK中提取包含符号的so库存到本地之后report.py利用这些本地so做地址到函数名的映射。所以务必指定-apk参数让脚本能拿到带符号的库。如果是自己编译的so库优化编译选项里要保留符号例如-g选项这样开发版APK里就含完整符号。发布版APK会把符号strip掉所以采样用的APK和线上APK最好区别对待。如果binary_cache里没有目标库你可以手动指定python report.py --kallsyms --symbols-dir /path/to/your/native/libs用NDK编译产物里obj/local/arm64-v8a这个目录下的库一般带符号。5.2 采样频率和设备权限Android设备上运行simpleperf进行CPU周期采样一般不需要root。但Android 10及以上系统对perf_event_open系统调用的访问增加了限制部分与安全相关的采样事件比如记录内核调用栈会失败。解决方法是adb shell setprop security.perf_harden 0这个设置需要root权限且重启后失效。如果没有root也可以退而求其次使用--clockid参数指定单调时钟采样或者用tracepoint事件替代cpu-clock不过能获取的调用栈信息会少一些。我的经验是在非root设备上默认的cpu-clock事件够用做基础热点定位完全没问题需要内核态分析时再考虑root设备或者使用厂商提供的带root的测试机。app_profiler.py在部分设备上会遇到/data/local/tmp被noexec挂载导致无法执行simpleperf的问题。如果你遇到Permission denied或not executable的报错尝试adb shell mount -o remount,exec /data/local/tmp同样需要root权限。没有root时换一台设备或者把simpleperf放到应用私有目录运行不过比较麻烦一般不建议。5.3 Unity和带打包器的App怎么采到有效数据如果你的App是Unity引擎打包的或者是用Flutter之类带自绘引擎的采样多了会遇到一个坑主线程上的热点集中在libunity.so或libil2cpp.so里函数名非常粗粒度定位不到具体业务代码。Unity项目通常会把大量游戏逻辑编译进libil2cpp.so里面有符号但函数名是C风格的整合函数比如GameController_Update_m123这种。单纯看火焰图你只知道自己写的一个MonoBehaviour的Update函数耗时但不知道为什么慢。这时候有两个思路一是把simpleperf的采样能力改成按线程过滤优先分析渲染线程和后台工作线程确认瓶颈到底在哪个线程。python app_profiler.py -p $(package_name) --duration 20 -t 线程ID-t参数后面可以指定线程名或线程ID分析Unity时重点看RenderThread和Worker Thread。二是配合Unity Profiler做交叉验证。先用Unity Profiler确认是CPU bound还是GPU bound如果CPU bound再用simpleperf下钻到native函数。如果仅仅用Unity Profiler会发现自己只能看到方法名看不到底层native调用而simpleperf正好补齐了这一层。5.4 采样时长和频率怎么设才有代表性--duration参数不是随便填的。采样时间太短比如3秒如果App在一个非稳态阶段数据可能完全不具备代表性。我一般建议至少20秒以上让App经历完整的典型业务路径。比如分析启动流程从点击icon开始到首页完全渲染至少30秒分析一个视频播放场景就持续播放采样30到40秒。采样频率由-f参数控制默认是4000Hz也就是每秒采样4000个调用栈。频率越高越容易捕获短时热点但开销量也越大会拖慢App本身。板载设备的经验值日常用2000到4000Hz足够如果热点函数的执行时间非常短而频繁可以提高到8000但要注意App出现可感知卡顿的话就降回去。这里还有一个容易导致误判的因素如果App跑在一个不够稳定的环境中比如后台有其他应用抢占CPU、或者CPU热降频采样结果可能包含大量干扰数据。采样时不要让手机放在被窝或贴着身体放在桌上让它自然运行就好。做前后对比时这一点尤为重要。5.5 conda环境调用脚本时的隐性问题现在很多人用conda管理Python环境在simpleperf场景下常见一个很有意思的“踩雷”conda环境的Python默认带Aki或Cython这类包某些版本会和simpleperf的pylib冲突导致脚本运行报错。这种报错往往出现在import阶段错误信息长得很像路径问题实际是包版本冲突。我的建议是给simpleperf单独建一个干净的conda环境只装必要依赖别把公司的基础数据分析环境直接拿来跑。conda create -n perf python3.8 pip -y conda activate perf pip install pandas # 如果脚本需要读取csv采样结果pandas用得着然后在conda环境中测试python app_profiler.py --help能正常打印帮助就说明环境没问题。后面再跑采样解析就不会遇到莫名奇妙的导入错误了。6. 结合个人实践的一些收尾建议回头看simpleperf这个工具给我的最大感触是性能分析这条路工具只是放大器真正决定效率的还是对数据的理解方式。采样报告和火焰图不直接告诉你“怎么改”但它们能准确告诉你“改哪里”。没有这份精确定位很多优化工作跟蒙眼猜谜没区别。如果想从入门到熟练我的建议顺序是先用app_profiler.py完整跑一遍看火焰图然后打开report.txt练习读Self和Children字段接着手动跑一次adb命令采样体会设备端和PC端的协作方式最后再做两次优化前后的对比分析。这个过程下来常规的Android native性能分析你就基本出师了。最后再分享一个小技巧把常用命令封装成脚本。比如我平时固定使用一台Pixel作为测试机就把“push simpleperf、清后台进程、采样、拉数据、生成报告”五个步骤写成一个shell脚本参数只留包名和时长。这样无论是排查线上反馈的性能问题还是验证自己的优化patch一顿饭的功夫就能拿到结论。踩过几次坑之后我现在养成一个习惯每次新接手一个Android性能优化任务第一件事不是打开代码而是先跑一份simpleperf采样看看当前基线。数据在手后面所有改动都有了对照系也少了很多无谓的口水战。本文还有配套的精品资源点击获取 
长河君 · 2026/9/3 1:44:07 · 阅读 1.2k Android性能优化实战：用simpleperf精准定位CPU热点与火焰图分析
简介Android Simpleperf 开源代码包面向安卓系统开发者与性能优化工程师帮助他们深入理解基于内核 perf 事件框架的用户空间性能分析工具。该压缩包约62.98MB核心源码以C文件与安卓构建蓝图为主涵盖性能数据采集、报告生成、统计输出和硬件跟踪解码等模块。其中记录模块负责命令行接口与采样逻辑报告模块完成数据解析与样本级分析统计模块提供CPU利用率等关键指标动态库与运行环境相关代码处理符号映射ETM解码部分面向特定处理器的高级事件追踪。当前已有184人学习下载说明项目对性能调优学习者具有一定参考价值。通过研究这些源码开发者可掌握Simpleperf的工作原理学会使用内核perf事件创建自定义采样事件、解析复杂性能数据并利用跨进程与线程分析能力优化应用和系统服务。对于希望定制性能分析工具或深入安卓性能调试的开发者这是一份难得的开源学习资料。1. 为什么Android性能优化绕不开simpleperf这个tar.gz如果你做过Android平台上的性能分析大概率见过类似extras-master-simpleperf.tar.gz这样的压缩包。我第一次拿到这个包的时候也挺懵名字看起来像某个开源项目的附属品但打开之后才发现里面装的是Android原生性能分析领域非常关键的一套工具集。简单说simpleperf是Android平台上的CPU性能剖析工具本质上是Linux内核perf工具在Android上的移植版本。它随Android NDK一起发布官方路径在ndk/simpleperf目录下而网上能搜到的extras-master-simpleperf.tar.gz通常是某个源码仓库中extras目录下的打包版本。不管来源是哪核心内容一致一套可以在Android设备上做CPU采样、函数热点统计、调用栈分析以及性能对比的命令行工具外加Python封装脚本和火焰图生成脚本。为什么它重要因为Android平台的性能优化经常卡在一个问题上——你大概知道App整体CPU占用高但说不清到底是哪个线程、哪个函数在烧电。adb shell top只能看到进程级别的粗粒度数据TraceView和Android Studio Profiler对Java层的分析还行一旦涉及C/C代码、游戏引擎渲染线程、图片解码、FFmpeg音视频处理这类native负载它们就显得力不从心。simpleperf做的事情就是把采样粒度压到函数级别让你精确看到时间都消耗在哪一行代码上。我当初使用它是因为负责的一个Unity手游项目在低端机上发热明显Unity Profiler只显示CPU占用飙到了80%多但无法定位到具体是哪个C插件函数在作祟。后来用simpleperf做了一次30秒的采样火焰图一出来问题一目了然一个音频解码库的混音函数占了将近35%的CPU时间。这种定位效率在纯靠看日志猜的阶段是难以想象的。所以这篇我用自己的实操经验把simpleperf从解压到上手分析的全流程以及那些文档里不会写清楚的坑一次讲透。无论是做Unity游戏优化、音视频SDK开发还是普通Android应用里带有大量native代码的性能排查这套东西你都值得掌握。2. 压缩包解开之后先搞清楚里面有什么2.1 目录结构和每个脚本的真实用途拿到包后第一件事先别急着跑命令花几分钟看目录结构。simpleperf的打包版本里通常包含以下几个核心组成部分我用表格梳理一下文件/目录真实用途bin/android/按架构分好的simpleperf可执行文件如arm64-v8a、armeabi-v7a、x86、x86_64app_profiler.py自动化采样脚本自动push可执行文件到设备、设置权限、跑采样、拉取报告最常用report.py把采样得到的perf.data转换成可读报告、火焰图annotate.py把采样结果关联到源代码行号做逐行热点标注simpleperf_report.py另一个报告生成入口老版本中常见新版整合进了report.pybinary_cache/脚本自动生成的符号缓存目录用于存放App中native库的带符号版本*.sh一些辅助脚本比如run_simpleperf_on_device.py等注意新版NDK里simpleperf已经不再需要手动分离可执行文件app_profiler.py会自己处理。但网络上下载的extras-master源码包不会假设你的设备上装有特定版本的NDK所以脚本里的NDK_DIR或者ANDROID_NDK_HOME路径需要自己设置。2.2 选对架构和Android版本sampleperf在Android 5.0API 21及以上的设备上原生支持。如果你的目标是低端机注意Android 8.0以下对采样事件的支持有限部分硬件计数器不可用但基础的CPU周期采样和任务时钟采样是没有问题的。架构这块容易踩坑。现在的设备绝大多数是arm64-v8a但如果你的App里还有32位so库或者你用的测试机是老的armeabi-v7a设备就需要把对应的bin/android目录下的可执行文件push到设备上。app_profiler.py有-p参数指定包名有-abi参数指定架构建议直接指定避免脚本猜错。2.3 别忘了Python环境这个隐性门槛带tar.gz后缀的发布包多半会附带Python脚本simpleperf也不例外。脚本依赖Python 3且需要能够访问adb。官方文档推荐用Python 3.6我实测Python 3.8、3.10都能顺畅跑。但在macOS上跑的时候碰到一个很隐蔽的问题如果你用homebrew自带的Python某些脚本会提示找不到pylib模块——因为脚本用相对路径导入同目录下的Python模块当你从其他目录调用脚本时需要把simpleperf目录加入PYTHONPATH。一个可靠的通用做法是export ANDROID_NDK_HOME/path/to/your/android-ndk-r26d export PATH$PATH:$ANDROID_NDK_HOME/simpleperf/bin/darwin/x86_64 export PYTHONPATH/path/to/simpleperf:$PYTHONPATH如果你更习惯用conda管理的Python环境也没有问题。在conda环境里创建一个干净的Python 3.8环境像下面这样conda create -n perf_env python3.8 -y conda activate perf_env pip install pyperf # 可选部分版本脚本需要然后在这个conda环境里运行simpleperf的Python脚本。这里有一个特别容易忽略的细节脚本调用adb时走的是系统PATH里的adb跟Python环境无关。如果脚本报adb not found先检查你的adb有没有加入PATH而不是怀疑Python环境。conda虚拟环境和系统环境在这个问题上互不干扰但也意味着两边要分别配置好。我自己的习惯是把adb路径也加入PATH然后把simpleperf目录下的Python脚本做个软链接到/usr/local/bin这样无论哪个conda环境都能直接调用省得每次激活环境都要重新设置路径。3. 第一次采样从设备连接到火焰图3.1 用app_profiler.py跑通自动化流程这是最省心的一条路。假设你的应用包名是com.example.myapp手机通过USB连接电脑且开启了USB调试步骤如下# 进入解压后的simpleperf目录 cd extras-master-simpleperf # 拉起App并自动采样30秒 python app_profiler.py -p com.example.myapp -a .MainActivity \ -apk /path/to/your-app.apk \ -r record \ --duration 30参数解释一下-p包名后面-a指定启动的Activity如果App已经在运行可以不加-a只做attach采样。-apk指定APK路径脚本需要解析APK来找到native库并建立符号映射。-r record表示执行采样也可以用-r stat执行计数统计模式只出汇总数据不出调用栈。--duration采样时长单位是秒。跑完之后会在当前目录生成perf.data和binary_cache目录。注意看脚本的日志输出它会自动把simpleperf这个可执行文件push到设备的/data/local/tmp目录并赋予执行权限。如果你在Android 12设备上跑可能会遇到权限问题脚本会提示你通过adb shell手动配置这种情况我们放到最后一部分专门说。3.2 手动采样不依赖脚本的原始命令脚本虽然方便但偶尔会有不够灵活的时候。比如你想在App运行的某个具体阶段采样或者需要多次采样对比这时候手动操作反而更好。先把simpleperf可执行文件推到设备上adb push bin/android/arm64-v8a/simpleperf /data/local/tmp/ adb shell chmod 755 /data/local/tmp/simpleperf然后先启动App进入目标场景再执行# 按应用名过滤采样 adb shell /data/local/tmp/simpleperf record -p $(pidof com.example.myapp) --duration 20 -o /data/local/tmp/perf.data这里-p后面跟的是进程PID不是包名。通过pidof动态获取省去手动查看的麻烦。采样完成后把数据拉回电脑adb pull /data/local/tmp/perf.data3.3 生成报告和火焰图有了perf.data就可以用脚本生成报告了# 生成文本报告 python report.py --kallsyms --symbols-dir binary_cache # 生成火焰图 python report.py --kallsyms --symbols-dir binary_cache --flamegraph--kallsyms表示从设备的内核符号表中读取内核符号这对分析内核态调用栈很重要不加的话内核相关热点会显示为地址。--symbols-dir指定符号缓存目录脚本会用binary_cache里的带符号so库把采样到的地址翻译成函数名。火焰图生成后会输出一个flamegraph.html文件浏览器打开就能看到横轴是采样次数占比纵轴是调用深度函数块越宽说明占用的CPU时间越多。这个图是整个分析流程中最直观的一环一眼就能定位到热点函数。这里补充一个实操中常见的问题新版脚本可能找不到--flamegraph参数但你可能还是想生成火焰图。替代方案是用simpleperf report输出文本报告然后手动用FlameGraph开源脚本转换。不过更省事的办法是用report.py的-o参数导出文本报告再用stackcollapse-perf.pl处理成火焰图脚本需要的输入格式。具体命令长这样python report.py --kallsyms --symbols-dir binary_cache -o report.txt这样生成的report.txt可以直接查看每一行是调用采样占比 函数名和调用栈信息。4. 从报告到优化决策数据到底怎么读4.1 Self、Total和Children的含义拿到文本报告后很多新手会盯着最上面的几行看但这个表有一个容易误读的地方。simpleperf的文本报告包含几个关键字段Self当前函数的执行时间占比不包括它调用子函数的耗时。这是衡量单个函数本身代码效率的核心指标。Children当前函数及其所有子函数消耗的时间总和占比。这是衡量以该函数为根的调用链整体开销的指标。判断优化价值时要两条腿走路。比如某个函数Self只有5%但Children是40%说明它本身不慢但它带着一堆子调用整个调用链占了40%的CPU。这种情况下优化点往往要往下游找看看它调用的子函数里哪些是真正昂贵的。反过来如果一个函数Self占到20%Children也只占20%说明它自己就是热区直接优化它的内部实现收益最明显。我在实际项目中遇到过这样一个例子一个纹理上传函数Self接近30%Children也差不多。代码注释显示作者担心它慢但实际上问题出在每次上传前都调用了一次glGetIntegerv来查询当前绑定纹理这个查询太费了。删掉后函数的CPU占用直接降到12%。这种数据指示的价值就是你优化方向的“导航仪”。4.2 用调用栈定位真实根因只看聚合报告容易犯一个错误把表面热点当根因。采样数据中的调用栈信息才是分析链路的关键。举个例子你看到memcpy的Self占比很高但这不代表你去优化memcpy本身。正确的做法是看memcpy的调用者是谁——是std::string的拷贝构造还是某个图片解码库的缓冲区复制或者是自研代码里的频繁小对象拷贝。跟前端监控一样热点函数的调用者往往是真正的“幕后黑手”。在使用simpleperf时我推荐用火焰图来看调用链而不是纯文本的调用栈列表。火焰图里横向宽度代表时间占比纵向显示调用关系。找准一条最宽的“山顶到底部”的路径就能还原出耗时最多的完整调用链。路径上越靠上靠近栈顶的宽块是直接执行者越靠下的宽块是调用源头的责任方。4.3 用对比分析验证优化效果优化做完了怎么证明有效simpleperf还能做两个场景的对比采样。做法是分别记录优化前后的perf.data# 优化前 python app_profiler.py -p com.example.myapp --duration 30 -o before.perf.data # 优化后先卸载重装App再重新采样 python app_profiler.py -p com.example.myapp --duration 30 -o after.perf.data然后使用report.py的对比模式或者把两份perf.data分别生成报告对比同一个函数的占比变化。我常用的方式是直接盯热点函数的Self占比变化同时观察总CPU使用率是否下降。如果函数占比降了但整体CPU没变说明热点“转移”到了别的地方优化并未真正生效。这种“转移”经常发生在缓存优化、结构体调整之后数据会诚实地告诉你——你把锅从A端挪到了B端。另外一个提高对比可信度的小技巧控制变量。两次采样尽量在同一台设备、同一个App版本、同一个操作路径下进行差异条件只留“是否应用优化”。手机的电量、温度会影响CPU调度最好在采样前重启设备把后台程序清干净。5. 实战中绕不开的坑逐个说清楚5.1 符号表缺失报告里全是地址第一次用的时候我兴冲冲采样完打开报告发现全是0x0000007f12345678这样的地址函数名一个都没有。原因很简单设备上的App里的so库是strip过的不含符号表。App在Release包中通常会移除调试符号simpleperf拿到的是装载进内存的二进制没有符号信息就翻译不出函数名。解决方案就是前面提到的binary_cache。app_profiler.py在做采样前会从APK中提取包含符号的so库存到本地之后report.py利用这些本地so做地址到函数名的映射。所以务必指定-apk参数让脚本能拿到带符号的库。如果是自己编译的so库优化编译选项里要保留符号例如-g选项这样开发版APK里就含完整符号。发布版APK会把符号strip掉所以采样用的APK和线上APK最好区别对待。如果binary_cache里没有目标库你可以手动指定python report.py --kallsyms --symbols-dir /path/to/your/native/libs用NDK编译产物里obj/local/arm64-v8a这个目录下的库一般带符号。5.2 采样频率和设备权限Android设备上运行simpleperf进行CPU周期采样一般不需要root。但Android 10及以上系统对perf_event_open系统调用的访问增加了限制部分与安全相关的采样事件比如记录内核调用栈会失败。解决方法是adb shell setprop security.perf_harden 0这个设置需要root权限且重启后失效。如果没有root也可以退而求其次使用--clockid参数指定单调时钟采样或者用tracepoint事件替代cpu-clock不过能获取的调用栈信息会少一些。我的经验是在非root设备上默认的cpu-clock事件够用做基础热点定位完全没问题需要内核态分析时再考虑root设备或者使用厂商提供的带root的测试机。app_profiler.py在部分设备上会遇到/data/local/tmp被noexec挂载导致无法执行simpleperf的问题。如果你遇到Permission denied或not executable的报错尝试adb shell mount -o remount,exec /data/local/tmp同样需要root权限。没有root时换一台设备或者把simpleperf放到应用私有目录运行不过比较麻烦一般不建议。5.3 Unity和带打包器的App怎么采到有效数据如果你的App是Unity引擎打包的或者是用Flutter之类带自绘引擎的采样多了会遇到一个坑主线程上的热点集中在libunity.so或libil2cpp.so里函数名非常粗粒度定位不到具体业务代码。Unity项目通常会把大量游戏逻辑编译进libil2cpp.so里面有符号但函数名是C风格的整合函数比如GameController_Update_m123这种。单纯看火焰图你只知道自己写的一个MonoBehaviour的Update函数耗时但不知道为什么慢。这时候有两个思路一是把simpleperf的采样能力改成按线程过滤优先分析渲染线程和后台工作线程确认瓶颈到底在哪个线程。python app_profiler.py -p $(package_name) --duration 20 -t 线程ID-t参数后面可以指定线程名或线程ID分析Unity时重点看RenderThread和Worker Thread。二是配合Unity Profiler做交叉验证。先用Unity Profiler确认是CPU bound还是GPU bound如果CPU bound再用simpleperf下钻到native函数。如果仅仅用Unity Profiler会发现自己只能看到方法名看不到底层native调用而simpleperf正好补齐了这一层。5.4 采样时长和频率怎么设才有代表性--duration参数不是随便填的。采样时间太短比如3秒如果App在一个非稳态阶段数据可能完全不具备代表性。我一般建议至少20秒以上让App经历完整的典型业务路径。比如分析启动流程从点击icon开始到首页完全渲染至少30秒分析一个视频播放场景就持续播放采样30到40秒。采样频率由-f参数控制默认是4000Hz也就是每秒采样4000个调用栈。频率越高越容易捕获短时热点但开销量也越大会拖慢App本身。板载设备的经验值日常用2000到4000Hz足够如果热点函数的执行时间非常短而频繁可以提高到8000但要注意App出现可感知卡顿的话就降回去。这里还有一个容易导致误判的因素如果App跑在一个不够稳定的环境中比如后台有其他应用抢占CPU、或者CPU热降频采样结果可能包含大量干扰数据。采样时不要让手机放在被窝或贴着身体放在桌上让它自然运行就好。做前后对比时这一点尤为重要。5.5 conda环境调用脚本时的隐性问题现在很多人用conda管理Python环境在simpleperf场景下常见一个很有意思的“踩雷”conda环境的Python默认带Aki或Cython这类包某些版本会和simpleperf的pylib冲突导致脚本运行报错。这种报错往往出现在import阶段错误信息长得很像路径问题实际是包版本冲突。我的建议是给simpleperf单独建一个干净的conda环境只装必要依赖别把公司的基础数据分析环境直接拿来跑。conda create -n perf python3.8 pip -y conda activate perf pip install pandas # 如果脚本需要读取csv采样结果pandas用得着然后在conda环境中测试python app_profiler.py --help能正常打印帮助就说明环境没问题。后面再跑采样解析就不会遇到莫名奇妙的导入错误了。6. 结合个人实践的一些收尾建议回头看simpleperf这个工具给我的最大感触是性能分析这条路工具只是放大器真正决定效率的还是对数据的理解方式。采样报告和火焰图不直接告诉你“怎么改”但它们能准确告诉你“改哪里”。没有这份精确定位很多优化工作跟蒙眼猜谜没区别。如果想从入门到熟练我的建议顺序是先用app_profiler.py完整跑一遍看火焰图然后打开report.txt练习读Self和Children字段接着手动跑一次adb命令采样体会设备端和PC端的协作方式最后再做两次优化前后的对比分析。这个过程下来常规的Android native性能分析你就基本出师了。最后再分享一个小技巧把常用命令封装成脚本。比如我平时固定使用一台Pixel作为测试机就把“push simpleperf、清后台进程、采样、拉数据、生成报告”五个步骤写成一个shell脚本参数只留包名和时长。这样无论是排查线上反馈的性能问题还是验证自己的优化patch一顿饭的功夫就能拿到结论。踩过几次坑之后我现在养成一个习惯每次新接手一个Android性能优化任务第一件事不是打开代码而是先跑一份simpleperf采样看看当前基线。数据在手后面所有改动都有了对照系也少了很多无谓的口水战。本文还有配套的精品资源点击获取