简介面向移动端测试人员与性能测试初学者围绕 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是脚本里最常用的口径。PSSProportional 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 NR2{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 stateON) if [ -z $SCREEN_STATE ]; then echo [WARN] 屏幕可能处于关闭状态尝试唤醒 adb -s $DEVICE_ID shell input keyevent KEYCODE_WAKEUP sleep 2 fi # 确认目标包名对应的uid用于后续网络流量统计 PACKAGEcom.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的stateON判断屏幕状态部分系统版本字段名可能略有差异如果在这里误报可以把判断条件放宽成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}, shellTrue, capture_outputTrue, textTrue) if result.returncode ! 0: raise RuntimeError(fadb命令失败: {cmd}, stderr: {result.stderr}) return result.stdout.strip() def sample_cpu_mem(package, interval1): 采集一次CPU占用率和PSS内存返回(dict, dict) # top输出格式跨系统有差异这里用正则直接抓包名所在行 top_out run_adb(fshell 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(fshell dumpsys meminfo --package {package}) mem_match re.search(rTOTAL 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(fshell dumpsys gfxinfo {package} reset) time.sleep(1) end_time time.time() duration frame_times [] while time.time() end_time: out run_adb(fshell 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的封装把shellTrue和capture_output组合起来简化了每次调用的写法。要注意的是subprocess.run加上shellTrue会把整条命令交给系统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_VSYNCparts[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_sec180, interval_sec2): 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, intervalinterval_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, durationduration_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长时间稳定性用monkeyUI回归用UiAutomator。下面是一段实际跑滑动场景的示例用Python控制adbd event的写入模拟从底部向上滑动再轻微回弹的动作。import subprocess import time # 通过 adb shell input 模拟一个真实的上滑-停顿-下滑的操作序列 def scene_scroll_feed(width, height, rounds20): 滑动手势的节奏用 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, shellTrue) time.sleep(0.4) # 轻微下滑回弹位置制造一个停顿感 subprocess.run(f{ADB} shell input swipe {width//2} {end_y} {width//2} {end_y80} 80, shellTrue) time.sleep(0.8) # 使用方法先获取屏幕分辨率再调用真下滑动序列 def get_screen_size(): out subprocess.run(f{ADB} shell wm size, shellTrue, capture_outputTrue, textTrue).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, rounds20)input swipe的坐标用的是绝对像素值所以get_screen_size从wm size里解析出真实分辨率是第一步。duration参数设为300毫秒、滑动距离接近半个屏幕这套参数模拟的是“快速浏览内容流”的操作节奏如果你测试的是阅读类App节奏应当调慢——上滑的duration拉长到500毫秒time.sleep从0.4秒调到0.8秒。不同的测试目的对应不同的手势节奏这个参数只能在真机上凭手感校准最好是录一段真实用户的滑屏操作来对照让脚本节奏尽量贴近真实。rounds20在这里生成约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, rounds10): 连续执行rounds轮冷启动输出每次WaitTime与TotalTime results [] for i in range(rounds): subprocess.run(f{ADB} shell am force-stop {package}, shellTrue) time.sleep(5) # 等系统完全回收进程稳定冷启动环境 out subprocess.run(f{ADB} shell am start -W {package}/{activity}, shellTrue, capture_outputTrue, textTrue).stdout total re.search(rTotalTime:\s(\d), out) wait re.search(rWaitTime:\s(\d), out) results.append({ round: i1, 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, shellTrue) 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 rangecollect_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%”决策价值完全不一样。性能脚本开发走到这里才算真正把“测性能”和“写脚本”两件事合成了一件事。数据采集、场景驱动、参数调优、环境控制、可信度验证这五层每一层都值得单独打磨。我在实际项目中踩过的教训是脚本只是一个容器真正有价值的是你对自己测试目标的理解——知道每个指标的口径、每个参数的来源、每个坑的形成机制。按这个思路去搭自己的脚本体系性能测试就不再是黑匣子你会拿到每一轮数据的“培养过程”出问题时能直接看到是哪一环失真。希望帮到你。本文还有配套的精品资源点击获取