简介：面向移动端测试人员与性能测试初学者，围绕 LoadRunner 11.0 讲解手机应用性能测试脚本的开发路径，重点解决已安装工具却不知如何选择协议、配置录制模式以及生成可用脚本等常见实际困惑。文档先说明开发前需要准备的条件，例如安装对应补丁、开启电脑无线热点并确保手机连接成功；再梳理从手机电脑共享网络到新建脚本、录制操作、生成脚本的完整流程与注意事项，同时对关键环节给出前提提醒，能帮助初学者避开网络不通、录制失败等常见问题。文档随后还介绍了脚本在应用程序性能测试、负载测试、压力测试等场景中的用途，方便读者把同一套脚本思路迁移到不同测试目标。资源为单个 doc 文档，压缩包大小约 359KB，内容精炼、按步骤组织；目前已有 482 人学习，适合移动测试工程师、质量保障人员以及性能测试学习者速查和入门。虽然体量不大，但信息密度较高，尤其适合在项目开展前快速建立手机端性能测试脚本开发的基本框架。
1. 手机app性能测试脚本开发：为什么脚本化是性能测试的第一步
做手机App性能测试，有两条路：一条是伸手拿现成工具，点按钮、看报告、截图贴进文档；另一条是自己写脚本，一条命令把采集、操作、记录、导出全串起来。等你真正跑过十几轮版本对比就会发现，第一条路走不通——工具测出来的数字永远是“它想给你看的”，而脚本测出来的才是“你指定条件下真实发生的”。手机app性能测试脚本开发的价值不在写代码本身，而在于把CPU、内存、帧率、网络请求这些指标变成可以重复、可以对比、可以回归的资产，让性能问题从“感觉卡”变成“第12秒到第18秒掉帧34次”这样能定位、能验收的结论。
这篇文章按我实际做性能测试的流程来写：先讲清楚脚本里每一项指标背后的采集原理和选型理由，再给出一套能跑通的最小脚本框架，然后讲场景编排和参数调整，最后把最容易让数据失真、让人白忙一场的坑逐个拆开。内容针对的是已经有App测试基础、想自己搭性能脚本的测试开发工程师，新手照着一步步能跑通，熟手可以直接跳到避坑章节对一下自己的做法。
2. 脚本要采哪些指标：采集原理、选型理由与口径确认
2.1 CPU与内存：先搞清楚top和meminfo里数字的来历
CPU和内存是性能测试脚本里最基础、也最容易误读的两个指标。Android系统里CPU数据的最常用来源是top命令，它是Linux/proc/stat和/proc/<pid>/stat的封装。top -b -n 1以批量模式输出一次快照，-o %CPU可以按CPU占用排序。但这里第一个坑就来了：不同版本的top对-o参数的支持不一样，部分较老系统的toybox top根本不认-o，直接报错。我一般用top -b -n 1 -d 1先把一行完整输出拉下来，再用正则去匹配目标包名去解析，而不是依赖列排序。
内存指标里，dumpsys meminfo <package>的TOTAL PSS是脚本里最常用的口径。PSS（Proportional Set Size）把共享内存按进程数分摊了，比RSS更接近“这个App实际占了多少”的直觉。但是要注意：一个App往往有多个进程——主进程、:push、:remote这类独立进程是分开算的。脚本里用dumpsys meminfo --package <package>可以一次性拿到这个 uid 下所有进程的汇总，这个参数非常关键，很多入门脚本漏了它，导致“App内存越测越低”的怪异结论，其实是主进程内存被副进程分摊走了。汇总之后还要看采样位置，dumpsys meminfo需要在主线程空闲时才能拿到稳定结果，如果App正在做重CPU操作，内存数值会出现瞬时偏高，脚本里要对同一场景至少采3次取中位数，而不是直接拿第一次结果当结论。
2.2 帧率与掉帧：gfxinfo输出的hidden细节
帧率是最能体现“用户觉得卡不卡”的指标，但很多人直接用dumpsys gfxinfo <package> framestats拿到的平均帧率来判断，这是有问题的。framestats输出的每一帧都带FLAGS标记，其中有0表示正常帧，1表示SurfaceFlinger合成异常，2表示App绘制超时。平均值数字可以很好看，但真正影响体验的是jank帧的数量和分布——一次掉帧发生在快速滑屏时远比发生在静止页面时更让用户反感。
脚本采集帧数据时，我建议先强制开启GPU渲染分析，命令是setprop debug.hwui.profile true，然后跑完场景后执行dumpsys gfxinfo <package> reset，清掉framestats的累积数据，接着只采集场景执行期间的数据。dumpsys gfxinfo输出的是一串以framestats为起始标志的帧数据块，每行包含FLAGS、INTENDED_VSYNC、VSYNC、OLDEST_INPUT_EVENT、NEWEST_INPUT_EVENT、READY等时间戳，脚本解析时要先找---PROFILE---标记，然后逐帧计算frame_time = READY - INTENDED_VSYNC，超过16.6毫秒的帧就算掉帧。这套解析逻辑不复杂，但它决定了脚本给出的掉帧率是不是可信。
2.3 网络与电量：非侵入式采集的口径之争
网络和电量是另外两个高频指标，但它们的采集方式各有各的口径问题。网络流量推荐用/proc/uid_stat/<uid>/tcp_rcv和tcp_snd两个文件来读，这两个文件给出的是这个uid累计接收和发送的TCP字节数。脚本在场景开始前读一次、结束后再读一次，差值就是场景期间的真实流量。为什么不用adb shell netstat？因为netstat看到的是瞬时连接状态，拿不到累计流量；为什么不用抓包工具？因为抓包过滤的是链路层，包含TCP重传和协议头，和App业务层的流量口径对不齐。/proc/uid_stat的口径虽然只含TCP，但胜在稳定、无侵入，做App的横向对比足够。uid的获取方法是用dumpsys package <package>里的userId字段，或者用stat -c %u /data/data/<package>直接拿。
电量的采集我一般不建议在脚本里做主线，因为精准的电量数据需要dumpsys batterystats --enable full-wakeup开启完整统计，这要求root权限，而且batterystats本身有延迟刷新。我在实践中更倾向用/sys/class/power_supply/battery/voltage_now和current_now读瞬时电压电流，按固定间隔采样再算出平均值，作为耗电的相对变化趋势。这个做法精度有限，但好在不需要root，适合做不同场景之间的横向对比。真正要做电量专项、要精准到毫安时的，再上专业功耗仪，脚本层面的电量采集定位是筛趋势、找异常，不是出官方功耗报告。
参数口径确认是个容易被忽略的步骤。脚本开发的第一件事不是写代码，而是把“这个指标到底怎么定义的”确认清楚——我的脚本里sample_cpu()采样间隔是多久、内存取的是PSS还是RSS、掉帧的阈值是超过16.6ms还是超过两帧、网络流量是按uid还是按接口累计。这些口径不锁死，脚本跑出来的数据后期根本没法解释。我在每个脚本的配置文件头部都有一份口径说明注释，这个习惯让我在后面复盘的时候少走了很多弯路。
3. 搭一个能跑通的最小脚本框架：环境自检、采集与落盘
3.1 环境准备：ADB连接、设备状态与包名确认
正式开始写脚本之前，先把环境准备这一步做成脚本里的一个函数，让它在每次跑数之前自动检查关键条件。这样能避免“跑了半小时，最后发现设备断连数据全废”的低级事故。环境自检函数至少要做四件事：检测设备是否在线、确认设备未锁屏、确认目标App在前台、确认目标包名的uid存在。设备在线的检查用adb get-state，锁屏状态用dumpsys window policy里的mShowingLockscreen字段判断，前台App用dumpsys activity activities | grep mResumedActivity来拿。
#!/bin/bash # 环境自检：设备状态、锁屏、前台App与uid DEVICE_ID=$(adb devices | awk 'NR==2{print $1}') if [ -z "$DEVICE_ID" ]; then echo "[FATAL] 没有检测到已连接的设备" exit 1 fi # 检查屏幕是否解锁（部分设备上 wakeup 后需要解锁才能跑场景） SCREEN_STATE=$(adb -s "$DEVICE_ID" shell dumpsys power | grep "Display Power" | grep -o "state=ON") if [ -z "$SCREEN_STATE" ]; then echo "[WARN] 屏幕可能处于关闭状态，尝试唤醒" adb -s "$DEVICE_ID" shell input keyevent KEYCODE_WAKEUP sleep 2 fi # 确认目标包名对应的uid（用于后续网络流量统计） PACKAGE="com.example.app" UID_STR=$(adb -s "$DEVICE_ID" shell stat -c %u /data/data/$PACKAGE) echo "[INFO] $PACKAGE 的 uid 是 $UID_STR"这段脚本里stat -c %u直接读/data/data/目录的属主uid，这个方式不需要root也能拿到数字uid，适合绝大多数真机设备。dumpsys power里Display Power的state=ON判断屏幕状态，部分系统版本字段名可能略有差异，如果在这里误报，可以把判断条件放宽成grep -E "Display Power: state=(ON|DOZE)"。整个自检函数跑完，输出一个[INFO]状态摘要，脚本再进入正式的采样流程。这是性能脚本的第一道保险，值得花一点时间做好。
3.2 用Python拉通最小采集链路：CPU、内存、帧数据三个采集器
我习惯用Python来写性能脚本的主体，因为Python的subprocess对ADB命令的封装很顺手，数据解析也比纯bash容易维护。一个最小可运行的框架只需要三部分：一个执行adb命令的封装函数、三个数据采集函数、一个把数据写成CSV的落盘函数。下面是这个框架的核心代码，按我平时项目的习惯做了简化，但结构是完整的。
import subprocess import time import csv import re from collections import defaultdict ADB = "adb" # 多设备时改成 adb -s <serial> PACKAGE = "com.example.app" # 被测App包名 OUTPUT_FILE = "perf_result.csv" def run_adb(cmd): """执行adb命令并返回去尾部空白的输出""" result = subprocess.run(f"{ADB} {cmd}", shell=True, capture_output=True, text=True) if result.returncode != 0: raise RuntimeError(f"adb命令失败: {cmd}, stderr: {result.stderr}") return result.stdout.strip() def sample_cpu_mem(package, interval=1): """采集一次CPU占用率和PSS内存，返回(dict, dict)""" # top输出格式跨系统有差异，这里用正则直接抓包名所在行 top_out = run_adb(f"shell top -b -n 1 -d {interval}") cpu_row = None for line in top_out.split("\n"): if package in line: # 行格式: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ ARGS parts = line.split() cpu_row = { "cpu_percent": float(parts[8].replace("%", "")), "mem_percent": float(parts[9].replace("%", "")), } break # dumpsys meminfo --package 汇总所有进程的 PSS mem_out = run_adb(f"shell dumpsys meminfo --package {package}") mem_match = re.search(r"TOTAL PSS:\s+(\d+)", mem_out) mem_row = {"total_pss_kb": int(mem_match.group(1)) if mem_match else -1} return cpu_row, mem_row def collect_gfx_frames(package, duration): """在duration秒内连续采集gfxinfo帧数据，返回掉帧率与帧时长列表""" run_adb(f"shell dumpsys gfxinfo {package} reset") time.sleep(1) end_time = time.time() + duration frame_times = [] while time.time() < end_time: out = run_adb(f"shell dumpsys gfxinfo {package}") in_framestats = False for line in out.split("\n"): if line.startswith("framestats"): in_framestats = True continue if in_framestats and line.strip(): # 帧数据行: FLAGS INTENDED VSYNC OLDEST_INPUT ... READY ... parts = line.split(",") if len(parts) >= 11: try: frame_time = (int(parts[10]) - int(parts[1])) / 1000000.0 frame_times.append(frame_time) except ValueError: pass time.sleep(1) total_frames = len(frame_times) jank_frames = [t for t in frame_times if t > 16.6] jank_rate = len(jank_frames) / total_frames * 100 if total_frames else 0 return {"frame_count": total_frames, "jank_count": len(jank_frames), "jank_rate": round(jank_rate, 2), "avg_frame_ms": round(sum(frame_times)/total_frames, 2) if total_frames else 0}run_adb的封装把shell=True和capture_output组合起来，简化了每次调用的写法。要注意的是，subprocess.run加上shell=True会把整条命令交给系统shell去执行，参数里如果有特殊字符要先做转义，避免引入注入风险。sample_cpu_mem里解析top输出用的是按行逐个匹配包名的方式，这个比grep后拆字段要稳——因为top的列宽在不同Android版本上不一样，但包名一定出现在该行内部。parts[8]和parts[9]对应CPU和内存百分比列，这个下标是依top默认列顺序来的，如果你的设备top输出列序不同，可以先打印一行看看再调。
collect_gfx_frames里的reset是每次采样前必须做的，否则拿到的帧数据是上一次操作累积下来的历史数据，无法反映当前场景。framestats块里的时间戳单位是纳秒，所以(parts[10] - parts[1]) / 1000000把差值换算成毫秒。注意parts[1]对应的是INTENDED_VSYNC，parts[10]对应的是READY——不同行里列的位置是固定的，但如果你设备输出多了一列（部分定制系统会额外输出DRAW的细分时间），下标就要重新数。
3.3 落盘格式与运行方式：CSV结构、时间戳对齐与一键运行
采集到的数据要落成CSV，后续分析才方便。CSV文件的设计有个关键原则：宁可多打时间戳，不要事后补字段。每行记录必须带timestamp_ms、scenario两个维度字段，再附带该时刻的CPU、内存、帧指标。scenario字段用来区分不同测试场景，比如cold_start_page_a、scroll_home_feed、video_play_10min，这样同一个CSV文件可以承载多个场景的对比，不用每个场景单独开文件。
# 运行入口：跑3分钟场景，每秒采一次CPU/内存，结束后拉一次总帧统计 def run_scenario(duration_sec=180, interval_sec=2): csv_rows = [] end_time = time.time() + duration_sec start_ms = int(time.time() * 1000) while time.time() < end_time: cpu, mem = sample_cpu_mem(PACKAGE, interval=interval_sec) row = { "timestamp_ms": int(time.time() * 1000) - start_ms, "scenario": "main_scroll", "cpu_percent": cpu["cpu_percent"] if cpu else "", "total_pss_kb": mem["total_pss_kb"], } csv_rows.append(row) time.sleep(interval_sec) gfx = collect_gfx_frames(PACKAGE, duration=duration_sec) csv_rows.append({"timestamp_ms": duration_sec * 1000, "scenario": "gfx_summary", "cpu_percent": "", "total_pss_kb": "", "frame_count": gfx["frame_count"], "jank_rate": gfx["jank_rate"]}) with open(OUTPUT_FILE, "w", newline="") as f: writer = csv.DictWriter(f, fieldnames=["timestamp_ms", "scenario", "cpu_percent", "total_pss_kb", "frame_count", "jank_rate"]) writer.writeheader() writer.writerows(csv_rows) print(f"[DONE] 数据已写入 {OUTPUT_FILE}，共 {len(csv_rows)} 条记录")这里强调的是把interval_sec设置成2秒而不是1秒，背后有个实际考量：top命令本身有CPU开销，在性能弱的测试机上1秒一采会影响被测App的CPU数据，导致自己干扰自己。2秒一采对绝大部分场景足够，还能减轻ADB通道的负担。start_ms在循环开始前记录，timestamp_ms用相对时间而不是绝对时间，这样多轮测试的数据集对齐时不用再处理时区偏差。collect_gfx_frames放在场景结束之后调用，因为dumpsys gfxinfo是全局的，App后台没有绘制帧时采集到的数据没有意义。最后的csv.DictWriter每行字段都写全，缺的字段填空字符串，避免CSV列错位。
4. 场景编排与参数调优：让脚本测出真实用户路径
4.1 用ADB事件驱动场景：Monkey、坐标点击与UiAutomator的取舍
性能脚本的“场景驱动”是个容易被低估的环节。很多人的做法是手动在手机上操作，脚本只负责采数，这样做的最大问题是手动操作的不可重复性——两次划屏的速度不同、停留时间不同，最终帧率数据差异可能达到20%以上，脚本再准也白搭。正确的做法是用脚本去驱动App完成操作序列，让每次测试都走同一条用户路径。
驱动场景的三种常见手法：adb shell input系列命令、Monkey随机事件、UiAutomator自动化框架。input命令适合固定路径的场景，比如input swipe x1 y1 x2 y2 duration精确模拟一次滑动，input tap x y模拟点击。Monkey适合压力测试场景，adb shell monkey -p <package> --throttle 400 -s 100 5000按固定种子产生随机事件流，同一种子每次生成的序列完全一致，这正好满足可重复性的需要。UiAutomator适合需要按控件定位的场景，比如要点击“我的”Tab这种位置会随着屏幕分辨率变化的元素，用uiautomator runtest可以拿控件ID来定位，比写死坐标稳健得多。
我一般按场景类型混着用：固定路径业务用input，长时间稳定性用monkey，UI回归用UiAutomator。下面是一段实际跑滑动场景的示例，用Python控制adbd event的写入，模拟从底部向上滑动再轻微回弹的动作。
import subprocess import time # 通过 adb shell input 模拟一个真实的上滑-停顿-下滑的操作序列 def scene_scroll_feed(width, height, rounds=20): """ 滑动手势的节奏用 real_user 模式：快滑-慢停-微回弹， 比匀速滑动更接近真实用户操作，帧率数据更有说服力。 """ start_y = int(height * 0.75) end_y = int(height * 0.25) for i in range(rounds): # 快速上滑，duration 300ms，符合拇指滑动的正常速度 subprocess.run(f"{ADB} shell input swipe {width//2} {start_y} {width//2} {end_y} 300", shell=True) time.sleep(0.4) # 轻微下滑回弹位置，制造一个停顿感 subprocess.run(f"{ADB} shell input swipe {width//2} {end_y} {width//2} {end_y+80} 80", shell=True) time.sleep(0.8) # 使用方法：先获取屏幕分辨率，再调用真下滑动序列 def get_screen_size(): out = subprocess.run(f"{ADB} shell wm size", shell=True, capture_output=True, text=True).stdout # 输出格式: Physical size: 1080x2400 _, res = out.strip().split(":", 1) w, h = res.split("x") return int(w), int(h) if __name__ == "__main__": w, h = get_screen_size() # 滑动场景持续约24秒，期间由主采样循环同时采集指标 scene_scroll_feed(w, h, rounds=20)input swipe的坐标用的是绝对像素值，所以get_screen_size从wm size里解析出真实分辨率是第一步。duration参数设为300毫秒、滑动距离接近半个屏幕，这套参数模拟的是“快速浏览内容流”的操作节奏；如果你测试的是阅读类App，节奏应当调慢——上滑的duration拉长到500毫秒，time.sleep从0.4秒调到0.8秒。不同的测试目的对应不同的手势节奏，这个参数只能在真机上凭手感校准，最好是录一段真实用户的滑屏操作来对照，让脚本节奏尽量贴近真实。rounds=20在这里生成约24秒的操作序列，配合2秒间隔的采样循环，能采集到12组CPU/内存样本，已经足够画出一条有趋势的曲线。
4.2 启动性能的冷热启动控制：清后台、冷启动与首帧时间
启动性能是App性能测试里最常被单独提出来做专项的，但它对脚本要求特别苛刻。冷启动和热启动的数据必须严格区分：冷启动是进程不存在、从桌面图标点入的过程；热启动是App已经在后台、直接切回的过程。脚本控制冷启动的标准做法是先用am force-stop <package>杀掉进程，再am start -W <package/.MainActivity>启动并等待首帧。
am start -W的-W参数是关键，它会等待启动完成后输出TotalTime和WaitTime，单位是毫秒。TotalTime是App自己从onCreate跑到onResume的时间，WaitTime是系统从收到启动指令到首帧显示的总时间，两者差异本质是系统调度时间。脚本拿WaitTime作为冷启动耗时更贴近用户的感知。还有一类“温启动”——进程在后台缓存，但当前Activity被回收，am start -W测出来的耗时介于冷热之间。要得到纯冷启动的数据，每次测试前必须force-stop之后额外等一个短时间（我一般等5秒），避免系统刚杀完进程还有缓存残留。
def cold_start_test(package, activity, rounds=10): """连续执行rounds轮冷启动，输出每次WaitTime与TotalTime""" results = [] for i in range(rounds): subprocess.run(f"{ADB} shell am force-stop {package}", shell=True) time.sleep(5) # 等系统完全回收进程，稳定冷启动环境 out = subprocess.run(f"{ADB} shell am start -W {package}/{activity}", shell=True, capture_output=True, text=True).stdout total = re.search(r"TotalTime:\s+(\d+)", out) wait = re.search(r"WaitTime:\s+(\d+)", out) results.append({ "round": i+1, "TotalTime": int(total.group(1)) if total else -1, "WaitTime": int(wait.group(1)) if wait else -1, }) # 回到桌面，准备下一轮 subprocess.run(f"{ADB} shell input keyevent KEYCODE_HOME", shell=True) time.sleep(2) return results这里的time.sleep(5)是我反复试下来比较稳的一个值：太短了系统还没完成进程回收，测出来的时长偏短；太长了测试总耗时拖太久，10轮测试光等待就多出50秒。KEYCODE_HOME用来在每轮结束后回到桌面，避免下一轮的am start -W因为Activity栈的干扰出现启动秒开的情况。10轮取平均数之后，建议把最大和最小两个极端值也记录下来——如果最大值和平均值之间的差距超过20%，说明启动性能不稳定，这时候光看平均值会放过一个偶尔闪退或长时间卡顿的问题。
4.3 采样频率与持续时间的设置逻辑
采样频率和总持续时间没有“万能参数”，但可以按场景类型给出一套我常用的配置基线，然后根据App本身的行为调整。CPU和内存这类系统级指标，2秒间隔已经能捕捉到大多数异常波动；如果你怀疑某个页面在特定操作瞬间会有一个CPU尖峰，可以临时把interval_sec降到0.5秒，但要意识到高频top调用对测试机的性能干扰会同步上升，采出来的CPU数值可能比实际偏高——这是采样器对被测系统的干扰效应，无法完全消除，只能权衡。帧数据采集每次dumpsys gfxinfo会把当前已经离开的帧一并返回，所以我的做法是每轮场景结束时取一次聚合帧统计，而不是在场景中间反复拉取打断App的布局。
| 参数 | 冷启动场景 | 滑动/浏览场景 | 稳定性长测场景 |
|---|---|---|---|
| 采样间隔 | 不适用（事件驱动） | 2秒 | 5秒 |
| 持续时间 | 10轮取均值 | 30秒到3分钟 | 1小时以上 |
| 关键指标 | WaitTime/TotalTime | 掉帧率/帧时长P50/P95 | 内存PSS趋势/CPU均值 |
| 前置条件 | force-stop后等待5秒 | 主页面已加载完成 | 屏幕常亮并连接充电 |
参数调节还有一个原则：第一次跑通脚本用宽松参数，比如间隔5秒、时长1分钟，先确认整个链路是通的、数据能正常落盘，然后再收紧参数去跑正式测试。很多人上来就按基线参数跑1小时长测，结果跑到第40分钟设备断连，凭白浪费时间。性能测试脚本开发的本质逻辑是把“测试条件”固化成代码，参数的意义是让每个读到脚本的人都能还原出完全相同的测试环境，所以参数的选择和记录比参数本身的大小更重要。
5. 性能脚本开发避坑：数据失真源与现场排查方法
5.1 设备方向、亮度和通知导致的CPU基线漂移
现象：同一台手机、同一个脚本、同一个场景，上下午各跑一轮，CPU均值差了12个百分点，但App代码一行没改。原因排查到最后，发现是上午跑的时候手机在抽屉里锁屏，下午跑的时候屏幕朝上放在桌上且亮度被调到了最大，屏幕亮度和环境温度直接拉高了整机CPU负载。这不是App的性能变了，是你的测试基座变了。
解决：把测试环境变量做成脚本的一部分，写入元数据。每次跑数前固定亮度和屏幕方向——input keyevent KEYCODE_SLEEP会锁屏，测试期间要保证亮屏且亮度固定，用settings put system screen_brightness 200来设一个固定亮度值。系统自动亮度会随环境光变化造成CPU波动，所以正规一点的脚本会同时关闭自动亮度settings put system screen_brightness_mode 0。做横向对比的项目，建议同一台机器、同一个时间段、同一套脚本跑基线，环境变量的微小变化会让CPU数据产生几个百分点的偏差，这在性能测试里已经足以改变结论。
5.2 充电状态和温度对CPU频率的“隐性”影响
现象：一次长稳测试跑完后，前30分钟的CPU均值只有8%，后30分钟飙到25%，被测App的PSS内存也在同步上涨。一度以为是App内存泄漏，后来把/sys/class/power_supply/battery/temp的温度曲线拉出来才发现，后30分钟电池温度到了45℃，CPU因为温控策略被降频、反复升降频，数据完全失真。
原因：App在后台做相同的事情，但CPU的调度策略因为温度发生了变化。很多入门脚本只采集目标App的进程数据，忽略了系统级热管理对结果的影响。
解决：脚本里必须在开始和结束时各记录一次电池温度，并且整个测试过程中保持充电状态一致——要么全程插着充电器，要么全程不插。插拔充电会导致充电电流引起的整机功耗上升，进而影响CPU温控策略。验收时如果电池温度变化超过5℃，需要报废该轮数据重新跑。我把这条写成了一个verify_thermal()函数放在脚本末尾，直接根据温度差值输出PASS/FAIL标记，省得每次事后拿温度曲线手工对齐。
5.3top输出与dumpsys gfxinfo在不同系统版本上的格式差异
现象：脚本在一台Android 11的设备上跑得好好的，换到Android 13的设备上，sample_cpu_mem函数抛IndexError: list index out of range，collect_gfx_frames解析出的帧率变成了负数。
原因：Android系统的toolbox工具集随版本更新改了输出格式。Android 13的top把%CPU的列顺序移到前面了，还多了一列SHR之前没有的输出。gfxinfo在Android 13上，framestats块每行的列数变成了13列，时间戳的下标位置整体后移。
解决：彻底的解决方式是放弃固定列，全部改成正则匹配。CPU那行只要匹配到包名，就再按已知的%CPU文字标记去截取数字——不同版本的top输出中%CPU字样本身是稳定的，只是列顺序变了。对gfxinfo也做同样处理：解析前先判断行里有多少列，再做两种分支处理。这种写法比之前用下标硬算多写了近一半的解析代码，但换来的是在多种设备版本上的稳定性，这笔账划算。
5.4 多进程App的内存数据被“低估”或“高估”
现象：测一款带独立推送进程的App，脚本里用dumpsys meminfo com.example.app取PSS，测试结果里内存一直稳定在一个偏低范围，跟另一个用--package参数汇总全进程内存的同事对不上数。两个人测同一个App得到两个结论，开始互相怀疑对方的脚本有问题。
原因：dumpsys meminfo <package>输出的是该包名主进程的内存，副进程被独立放在了一个:***的条目里。如果被测App有多个进程，漏掉任何一个，内存数据都是不完整的。
解决：脚本里统一使用dumpsys meminfo --package <package>来获取uid汇总数据，同时在采集结果里把每个进程的PSS单独列出来。这条解决方式看起来简单，但它涉及的是对Android内存模型的理解——多进程App的内存优化方案会把一部分工作放到副进程，如果脚本只能感知主进程，那你的性能结论从根上就是错的。
5.5 采样自身对被测App的干扰：赫兹效应
现象：将采样频率从2秒一采改成0.5秒一采后，App的CPU占用率从6%涨到了11%，将近翻倍。起初以为是App在后台做了什么临时任务，后来发现纯粹是top命令本身频繁执行消耗了CPU，抬高了整个系统的负载基数，进而影响被测App的CPU时间片分配。
原因：性能采样这件事自身对被测系统是有干扰的。采样频率越高、采集命令越重，干扰越大。CPU采集的干扰在性能弱的中低端测试机上尤其明显，这类机器上top命令本身就要占掉不少CPU。
解决：把采样频率控制在2秒以上，同时在做CPU专项对比时，所有轮次都用完全相同的采样参数，保证干扰量一致。干扰是不可避免的，但只要干扰量在每轮测试中稳定，对比结论依然成立。用0.5秒间隔去捕捉特殊尖峰场景时，要把“高频采样导致的系统负载上升”写入测试结论的备注栏，不要把这个误差带进正式报告里。
6. 进阶技巧：把性能脚本从“能用”推向“可信”
当脚本已经能稳定跑通数据采集和场景驱动之后，下一步值得做的方向是数据可信度验证。我给自己的脚本定了一条规矩：每次改完脚本，先跑两轮完全相同的测试，计算两轮之间的波动幅度。CPU和内存这类指标的自然波动在5%以内算正常，掉帧率的波动应该控制在3个百分点以内；如果波动超过这个范围，问题大概率不在被测App，而在脚本的环境控制出了问题，要对测试环境做一次全面检查。这条验证习惯成本不高，但能拦住大量“测出结论但不敢信”的情况，非常建议保持。
帧数据的深入分析还有一层值得做：gfxinfo的framestats里除了总帧时长，还能拆出draw_time = OLDEST_INPUT_EVENT - VSYNC、sync_time、upload_time和issue_time这些细分耗时。当App出现掉帧时，脚本不应该只报告“掉帧率8%”，还要能从同一个数据源里拆出“是绘制耗时偏长还是输入事件排队导致”。这个方法能帮你把问题定位到渲染链路的具体阶段，节省大量排查时间。我把这段解析逻辑封装成了一个analyze_frame_breakdown()函数，专门在掉帧率超过预警线时自动输出细分报告。
def analyze_frame_breakdown(frame_line): """ 对gfxinfo的framestats一行做细分耗时分析，定位掉帧发生在渲染链路哪一环。 frame_line是framestats里的一行，这里解析关键列后返回分段耗时（毫秒）。 """ parts = frame_line.split(",") if len(parts) < 13: return None # 各列说明（单位：纳秒）： # parts[1]: INTENDED_VSYNC 帧意图开始 # parts[2]: VSYNC 实际vsync信号 # parts[7]: SYNC_START 同步阶段开始 # parts[8]: ISSUE_START 命令提交开始 # parts[10]: READY 帧准备完成 us = 1000000.0 # 纳秒转毫秒 vsync = int(parts[2]) / us ready = int(parts[10]) / us try: issue_start = int(parts[8]) / us except ValueError: issue_start = ready # draw_time 是同步到命令提交之间的耗时，反映应用侧绘图工作负载 draw_time = max(0, issue_start - vsync) # command_time 是命令提交到帧准备完成的耗时，反映GPU/合成开销 command_time = max(0, ready - issue_start) return { "draw_ms": round(draw_time, 2), "command_ms": round(command_time, 2), "total_ms": round(ready - vsync, 2), }这段进阶解析的前提是设备支持framestats完整输出，而framestats需要App开启硬件加速渲染，绝大多数现代App默认是开着的。若拿到的parts[8]为空或为0，说明该行数据不完整，脚本要跳过而不是算出一个错误分段时长。draw_time偏大意味着App侧的业务逻辑或布局计算拖了后腿，command_time偏大则是渲染管线和合成压力的问题，这两条路径对应的优化方向完全不同——前者看业务代码和布局层级，后者看资源大小和过度绘制。有了这层拆解，性能报告从“你这条列表卡”变成了“你的列表卡是因为item根布局嵌套太深导致draw耗时占了帧预算的70%”，决策价值完全不一样。
性能脚本开发走到这里，才算真正把“测性能”和“写脚本”两件事合成了一件事。数据采集、场景驱动、参数调优、环境控制、可信度验证这五层，每一层都值得单独打磨。我在实际项目中踩过的教训是：脚本只是一个容器，真正有价值的是你对自己测试目标的理解——知道每个指标的口径、每个参数的来源、每个坑的形成机制。按这个思路去搭自己的脚本体系，性能测试就不再是黑匣子，你会拿到每一轮数据的“培养过程”，出问题时能直接看到是哪一环失真。希望帮到你。
本文还有配套的精品资源，点击获取
