App性能测试脚本开发实战：从adb采集到工程化落地

简介：面向移动应用测试与性能测试初学者，文档以LoadRunner 11.0为工具，系统说明手机App性能测试脚本的开发流程。内容从前提条件讲起，包括已安装LoadRunner、准备待录制APP、电脑开启WiFi热点、必须安装LR_03105_Patch4补丁等；随后按步骤介绍手机与电脑共享网络、安装补丁、录制脚本（选择Mobile App(HTTP/HTML)协议、设置录制模式、在Action中录制操作）以及自动生成脚本，并补充了脚本在应用性能测试、负载测试、压力测试中的典型应用场景。包内仅一个doc格式文档，共1个文件，压缩包大小359KB，内容精炼便于快速阅读。目前已有482人学习下载。文档步骤明确、要点突出，特别点出台式机需无线网卡、录制时必须连接电脑WiFi、补丁安装等易错细节，读者按文档操作即可完成从环境搭建到脚本生成的完整实践，适合作为性能测试入门的速查参考。

1. 手机App性能测试脚本：为什么手工点测永远不够

一个App压测到第七轮，测试同学说“首页有点卡”，但产品经理问“到底卡了多少毫秒？比上个版本差了百分之几？”没人接得上话。这种情况几乎在每个做性能专项的团队里都出现过。手工点测最大的问题不是“点不准”，而是“没法重复”：这次滑动的速度、上次等待的时长、后台残留的进程全都不同，哪怕测出卡顿，也没法确定是哪一轮代码引入的。

手机App性能测试脚本开发，做的就是一件事：用代码驱动App完成一套固定的操作路径，同时在系统层面持续采集CPU、内存、帧率、网络、温度这些指标，把“凭感觉的卡顿”变成一条带时间轴的曲线和一份可对比的报表。脚本能带来的直接价值有三个：建立性能基线、发版前做性能回归、劣化发生后快速定位是哪个步骤哪个模块出问题。适合做这件事的，不只是专职测试开发，也包括想把手工性能测试工程化的性能专项工程师。这篇笔记就是我按实际落地路径整理的经验，从选型到代码，再到踩过的坑一项项讲清楚。

2. 脚本开发前的四块地基：选型、环境、指标定义与场景设计

性能测试脚本不是把代码写出来就能用的。我见过不少团队先写脚本再定口径，最后数据一团糟：CPU采样和帧率采样对不上时间轴，内存忽高忽低，自动化操作比手工还慢。真正让脚本稳定可用的，是动手写代码之前的四块地基：技术选型、设备环境、指标口径、场景设计。这四件事没定好，后面代码写得再漂亮也白搭。

2.1 技术选型：三条路线怎么选，别让测试工具拖垮性能数据

做手机App性能测试脚本，常见的路线有三条，每条都有清晰的使用边界。

第一类是跨平台的UI自动化框架，基于WebDriver协议，支持Android和iOS双端，可以定位控件、模拟复杂用户操作。它对原生控件和混合应用支持好，社区资料多，但自身需要启动一个自动化服务进程，而且每次操作都要经过协议转发，对CPU和帧率的采集会有不可忽略的干扰。适合做功能性的端到端回归，不太适合高精度的性能采样。

第二类是图像识别驱动的自动化框架，通过找图找色来定位和操作。它不依赖控件层级，适合游戏、自绘引擎这类非原生UI，但图像识别要反复截屏处理，速度慢，并且截屏本身会占渲染管线，会让帧率数据产生假性下降。用于游戏帧率采集时，要额外小心。

第三类是纯adb命令加Python脚本。Android系统自带的input命令可以直接产生点击、滑动、输入事件，dumpsys系列命令能读取系统级性能指标。这条路没有额外Agent驻留，对设备性能影响最小，脚本运行在PC侧，手机侧几乎感知不到。缺点是不能精确定位控件，坐标依赖UI布局，UI变动时要调整参数。

我一般做性能专项时选第三条路，也就是纯adb加Python。性能脚本的目标是让采集到的数据尽量接近“没人在测”时的真实表现，任何额外进程都是误差来源。如果场景必须跨多个业务页面且UI经常改，我会用第一类框架驱动操作，再单独用adb采集指标，但会把框架的自身开销记录进日志，方便排查。

选型的判断标准就一条：你测的是“App的性能”，还是“自动化工具在App上的性能”。如果工具本身的CPU占用超过1%，帧率采样就会被污染，选轻量路线才靠谱。

2.2 环境准备：一台不产生脏数据的设备，先做六个设置

脚本跑得再稳，设备环境不稳定，数据一样是脏的。用模拟器测性能结果基本不能信，虚拟机化的CPU和GPU调度策略与真机差异太大。我坚持用一台固定型号、固定系统版本的真机来采集。

拿到设备后，先做六个设置：

第一，开启开发者选项和USB调试，保证adb devices能稳定识别。第二，设置屏幕常亮，因为性能测试动辄三到五分钟，屏幕一灭操作就断。第三，关闭系统自动更新、云同步、省电模式，这些后台任务会在测试期间偷CPU和网络。第四，清理后台进程，把不相关的应用全部强制停止。第五，固定电源供电，尽量不要用充电状态不稳定的USB口。第六，如果被测试App需要登录态，预先登录并将账号状态固化到自动化测试专用环境。

屏幕常亮两条命令最常用：

adb shell svc power stayon true adb shell settings put screen_off_timeout 1800000

svc power stayon true表示USB连接时常亮，screen_off_timeout的单位是毫秒，1800000等于30分钟。注意不同厂商的定制系统可能不生效，最好在测试脚本开头检查一次屏幕状态，如果灭屏就唤醒。

这步的核心理念是“设备环境固定”。同一台设备跑同一套脚本，出来的数据才具备纵向对比意义。换设备、换系统版本、换充电状态，都会让基线失去参考价值。

2.3 指标定义：CPU、内存、帧率、网络、温度的口径先定死

性能指标不是“取一个数”那么简单，同一个指标采样方式不同，结果可以差出几倍。脚本开发之前，先把要采集的指标和统计口径定义清楚，后续代码只是把这些口径落地。

CPU指标，我通常取被测App主进程的CPU占用率，采集间隔1秒。Android命令dumpsys cpuinfo能直接给出每个进程的CPU百分比，但它统计的是“近期平均值”，不同Android版本刷新窗口不完全一样。如果做精密对比，我更倾向读取/proc/<pid>/stat自己算，虽然复杂点，但口径可控。

内存指标，最常用的是PSS（Proportional Set Size），它把共享库按比例摊到各个进程，比RSS更能反映真实占用。dumpsys meminfo里TOTAL PSS就是汇总值，单位是KB。注意内存曲线要区分冷启动和热启动，冷启动前要用am kill杀掉进程，否则会混入上一轮数据。

帧率指标，用dumpsys gfxinfo是最直接的方式。它统计被测App的帧渲染耗时，包括每帧绘制时间、VSYNC延迟、Janky帧数。测试开始前先执行一次reset清零，结束再dump，这样统计窗口才是准确的。

网络指标，不建议用Android系统自带的流量统计，因为它会合并所有进程。更可靠的做法是读取/proc/net/dev或/sys/class/net/<接口>/statistics的收发字节数，测试开始和结束各读数，计算差值。

温度指标，读电池温度文件最常见：/sys/class/power_supply/battery/temp，单位通常是0.1摄氏度，除以10换算。温度数据用来辅助判断发热导致的降频，不能只看CPU曲线。

所有指标必须统一采样时间轴。每个采样点记录绝对时间戳，操作事件也要记录时间戳，后续才能精确对齐。指标表参考如下：

这些口径定下来之后，写脚本只是按表实现而已。

2.4 场景设计：把一条用户路径拆成可重复的脚本步骤

性能脚本要测的不是“所有功能”，而是具有代表性的用户路径。常见场景有四类：冷启动、首页列表滑动、页面打开与返回、长时操作后的稳定性。每类场景要拆成原子步骤，比如“冷启动”至少包含：清空后台进程、启动Activity、等待首屏内容出现、拍照记录启动时间；“列表滑动”包含：进入列表页、按固定方向和时长滑动N次、记录每次滑动前后帧率。

拆好的步骤放到脚本里，要控制变量。每次滑动时长固定为200毫秒或300毫秒，滑动距离固定，等待时间固定。不要依赖人工感觉，全部参数化。

一个简单的场景动作序列用伪代码表示：

def run_scenario(): force_stop(PACKAGE) clear_recents() mark_event("cold_start_start") launch_activity(".MainActivity") wait_for_text("首页标题", timeout=10) mark_event("cold_start_end") for i in range(10): mark_event(f"swipe_{i}_start") swipe(0.5, 0.8, 0.5, 0.2, duration_ms=200) mark_event(f"swipe_{i}_end") sleep(0.5)

这里的mark_event是把操作事件打上时间戳，之后和性能曲线叠加时，就能看到每一段操作对应的CPU和帧率变化。场景设计的核心是“可重复”，宁可步骤少一点，也要保证每次跑出来的操作节奏一致。

3. 从零写一套可复用的性能采集脚本：核心代码与参数说明

地基打完，开始写代码。这一章的代码是我在模拟项目X里实际用过的骨架，可以直接复制改成自己的包名和设备号。核心分成四块：adb命令封装、操作注入、数据采集与落盘、报告生成。每块我都会给出代码和参数解释。

3.1 封装adb命令：建好设备通信的底座

所有脚本的第一步，是把adb命令包成一个Python函数。这样后面每个采集函数都能复用，设备号也只需要在文件头部改一次。

import subprocess import re import time DEVICE = "emulator-5554" # 替换成 adb devices 输出中的序列号 PACKAGE = "com.example.app" # 被测App包名 def adb(args: str) -> str: """在指定设备上执行 adb shell 命令，并返回标准输出""" try: result = subprocess.run( ["adb", "-s", DEVICE, "shell", args], capture_output=True, text=True, timeout=10 ) if result.returncode != 0: print("adb 执行失败:", result.stderr) return result.stdout except subprocess.TimeoutExpired: print("adb 命令超时:", args) return ""

-s DEVICE在多台设备同时连接时指定目标设备，防止命令打到错误的机器上。capture_output=True把标准输出捕获到Python字符串里，text=True让它以文本模式处理。timeout=10是保护措施，adb命令偶尔会卡死，不设超时会拖垮整个测试流程。

有了这个底座，下面的CPU和内存采集就很直接了。

3.2 操作注入：点击、滑动、输入与等待怎么写得像“人”

adb自带input命令可以模拟触摸，但原始命令只接受绝对坐标。为了适配不同分辨率，我封装成百分比坐标，这样在一台设备上调好的脚本换到另一台也能跑。

def get_screen_size(): """获取屏幕宽高，返回 (w, h)""" out = adb("wm size") m = re.search(r"(\d+)x(\d+)", out) return (int(m.group(1)), int(m.group(2))) if m else (1080, 1920) def tap(px, py, duration_ms=100): """px, py 是 0~1 的百分比坐标""" w, h = get_screen_size() x, y = int(px * w), int(py * h) adb(f"input tap {x} {y} {duration_ms}") def swipe(px1, py1, px2, py2, duration_ms=200): """从起点百分比坐标滑动到终点百分比坐标，duration 是滑动总时长""" w, h = get_screen_size() x1, y1 = int(px1 * w), int(py1 * h) x2, y2 = int(px2 * w), int(py2 * h) adb(f"input swipe {x1} {y1} {x2} {y2} {duration_ms}")

关键参数是duration_ms。真实用户快速滑动列表大约100到300毫秒，如果你写成1000毫秒，操作速度明显变慢，帧率数据会被拉低，测出来的不是App的问题。input tap命令在部分Android版本上可以加时长参数，但兼容性一般，不用也无所谓。

等待逻辑要避免硬编码sleep。页面在加载时，你sleep 3秒，结果可能已经加载完了，或者还没加载完。更可靠的方式是循环检测界面元素，用uiautomator dump抓当前控件文本：

def wait_for_text(text, timeout=10): """等待目标文本出现在当前界面""" start = time.time() while time.time() - start < timeout: xml = adb("uiautomator dump --compressed") if text in xml: return True time.sleep(0.5) raise TimeoutError(f"等待 {text} 超时")

注意uiautomator dump每次调用会占用几百毫秒到一两秒，如果把它放在性能采集中间频繁调用，会干扰CPU和帧率。所以等待逻辑只放在页面切换点，不要在滑动操作循环里调用。

3.3 数据采集与落盘：让每个指标都对上操作时间线

性能采集不能和操作串在同一个线程里做，因为adb命令有耗时，串行会拖慢操作节奏。常见做法是启动一个后台采集线程，每秒采样一次CPU和内存，写CSV文件。操作主线程只负责注入事件和打点。

import csv import threading from datetime import datetime def collect_loop(stop_event, writer): """采集线程：每秒采样并在CSV中追加一行""" while not stop_event.is_set(): row = { "ts": datetime.now().strftime("%H:%M:%S") + f".{datetime.now().microsecond // 1000:03d}", "cpu": get_cpu_percent(), "mem": get_mem_pss(), "temp": get_battery_temp(), } writer.writerow(row) time.sleep(1)

stop_event是threading.Event，主线程跑完场景后调用stop_event.set()，采集线程退出。这里采样间隔写死1秒，实际工程里应该从配置读取。

事件日志用单独列表记录：

events = [] def mark_event(name): events.append((datetime.now(), name))

结束时把事件列表写入另一个CSV，或者统一写在一个事件文件里。这样后续绘图时，可以在CPU曲线上画出每个操作阶段的起止竖线。

一次性把大文件写进CSV要注意缓冲。csv.writer每调用一次writerow就落盘一次，高频采集会让磁盘I/O波动，间接拖累性能。我习惯每50行刷新一次：

import csv f = open("perf.csv", "w", newline="", buffering=8192) writer = csv.writer(f)

buffering=8192表示缓冲区满8KB才写盘，搭配每50行手动flush可以兼顾稳定性和实时性。

3.4 最小报告：用采集数据生成带事件的曲线图

数据采集完，需要让人看得懂。用Python的标准库或轻量处理库，直接生成一张包含CPU占用和内存随时间变化的图，并在图上用竖线标出操作阶段。

import pandas as pd import matplotlib.pyplot as plt df = pd.read_csv("perf.csv") df["ts"] = pd.to_datetime(df["ts"]) fig, ax1 = plt.subplots(figsize=(12, 5)) ax1.plot(df["ts"], df["cpu"], color="blue", label="CPU%") ax1.set_ylabel("CPU %") ax2 = ax1.twinx() ax2.plot(df["ts"], df["mem"] / 1024, color="red", label="PSS (MB)") ax2.set_ylabel("Memory (MB)") # 标注事件 for ts, name in events: ax1.axvline(x=ts, color="gray", linestyle="--", linewidth=0.8) ax1.text(ts, ax1.get_ylim()[1]*0.95, name, rotation=90) plt.tight_layout() plt.savefig("report.png")

这段代码把CPU和内存用双y轴画在一起，因为两者量纲不同。df["mem"] / 1024把KB换算成MB。事件竖线帮助快速定位阶段变化。足够当报告雏形了，后续需要更详细分析再补充。

4. 性能脚本开发的避坑指南：五个现实坑与对应解法

脚本写起来不难，难在让它长期稳定地跑出可信数据。下面这五个坑是我在真实项目中踩过或见人踩过的，每条都按“现象、原因、解决”来说，方便你对照排查。

4.1 现象：CPU数据全为0，正则写对了还是没有

有段时间我采集CPU，脚本里get_cpu_percent()返回的都是None，但手动在终端执行命令有数据。排查发现，在Android 10及以上部分设备上，dumpsys cpuinfo输出的进程名带完整包名加冒号后缀，例如com.example.app:remote，而我的正则写的是精确匹配com.example.app，导致匹配失败。另一个原因是某些定制ROM限制普通应用的“读取CPU使用率”权限，需要手动在开发者选项里打开“开启CPU使用情况显示”之类的开关。

解决方法是先打印原始输出，确认格式再写正则：

def get_cpu_percent(): out = adb(f"dumpsys cpuinfo | grep {PACKAGE}") print("raw cpuinfo:", out) # 调试用 m = re.search(r"(\d+(?:\.\d+)?)%\s+\d+.*", out) return float(m.group(1)) if m else None

\s+\d+.*匹配进程名中的PID和包名部分。如果dumpsys不可靠，改用读取/proc/<pid>/stat计算CPU，虽然麻烦，但稳定性和口径都比dumpsys好。

4.2 现象：自己算的帧率和厂商工具差十帧，应该信谁

一次在模拟项目X的首页滑动测试中，脚本算出平均帧率是55，某厂商图形调试工具显示48。后来仔细看官方文档，dumpsys gfxinfo的帧周期是从“上次reset”开始的所有帧，包括动画和输入时间，而厂商工具只统计GPU渲染线程里的每帧耗时，并且会过滤掉超过几秒的空档。

原因是两个统计窗口不对齐。解决方法是严格按流程：冷启动后先执行adb shell dumpsys gfxinfo <pkg> reset，再跑场景，跑完立刻dump。同时读取Total frames rendered和Janky frames两个字段，不要只读一个。只有统一起点、统一字段，数据才可比。

adb shell dumpsys gfxinfo com.example.app reset # 运行你的性能场景 adb shell dumpsys gfxinfo com.example.app > gfx.csv

4.3 现象：脚本跑到一半设备休眠，用例直接中断

有次压测跑到第四分钟时，Python脚本报点击失败，回头一看屏幕锁了。我们明明设置了screen_off_timeout，但某些手机厂商的智能省电策略会无视这个设置，而且svc power stayon true只在USB连接时生效，如果测试中途USB断开或松动，就失效了。

解决方法是多管齐下：测试开始前执行下面三条命令，并在测试脚本的主循环里每隔30秒检查一次屏幕状态，如果灭屏立刻唤醒。

adb shell svc power stayon true adb shell settings put screen_off_timeout 2147483647 adb shell wm dismiss-keyguard

screen_off_timeout设置为2147483647实际上是差不多24天，绕过低版本Android只接受32位整数的上限。wm dismiss-keyguard解锁当前锁屏。测试前检查USB连接，建议用质量好的线，并避免移动PC。

4.4 现象：内存PSS突然暴涨，但手工测并没有

有次脚本报告里内存冲到800MB，我怀疑是App泄漏，但同事手工操作怎么也复现不了。后面对比流程发现：脚本在冷启动前没有清理App进程，直接把上一轮测试残留的页面、缓存、线程带进了新一轮。PSS里包含了共享库按比例分配的一部分，上一轮加载后的共享页面没释放，就会虚高。

解决方法是所有冷启动场景开始前，固定执行：

adb shell am force-stop com.example.app adb shell am kill com.example.app adb shell pm clear com.example.app

am force-stop结束时相关的进程和后台服务，pm clear清空应用数据。但注意：如果被测App登录态需要保留，就不要用pm clear，改成只执行am force-stop。热启动场景则两者都不执行，直接重新启动Activity，测到的内存才是二次启动的稳态。

4.5 现象：自动化操作比人还慢，导致性能数据失真

一次跑出来的帧率明显比人工操作时低，仔细看脚本，滑动input swipe的duration写了2000（毫秒），等于是2秒匀速拖动，而人滑一屏只要200毫秒。操作慢，CPU和GPU负载就变小，帧率数据反而会“变好”或者出现间歇性等待，完全不能反映真实体验。

解决方法是把滑动duration调整到接近真实操作，同时去掉多余的sleep。我把列表滑动统一设成200毫秒，并且等待页面加载不用固定sleep，用wait_for_text循环，但采样间隔改成0.2秒。真实操作中的停顿本来就有，脚本只要保证每个动作的时长符合用户习惯即可。

另外，多操作之间不要反复通过adb shell穿行，因为每次启动shell进程有几十毫秒开销。可以拼成一条命令减少启动次数。例如：

adb shell "input swipe 100 100 200 200 200; sleep 0.2; input swipe 200 200 100 100 200"

分号分隔的多个input命令在同一个shell会话里串行执行，省去多次adb client启动时间。

5. 让脚本更接近工程化：配置化、持续集成与趋势报告

脚本能跑通只是第一步。在一线落地时，你需要让测试同学不写代码也能加场景，让CI可以自动跑回归，让历史性能曲线能被看见。这章讲三件工程化的事。

5.1 用YAML配置驱动测试，改用例不用改代码

把测试设备、包名、指标和场景步骤全部从Python代码里抽出来，放到一个YAML文件里，用统一入口读取。常见做法是这样的配置：

device_id: "device_serial" package: "com.example.app" metrics: - cpu - mem scenario: - name: "cold_start" actions: - type: "launch" component: ".MainActivity" clear_data: true - type: "wait_text" text: "首页标题" timeout: 10 - type: "swipe_list" count: 8 duration_ms: 200

对应的Python加载器：

import yaml with open("scenario.yaml", "r") as f: cfg = yaml.safe_load(f) def run_by_config(cfg): for action in cfg["scenario"]["actions"]: if action["type"] == "launch": launch_app(cfg["package"], action["component"]) elif action["type"] == "swipe_list": for _ in range(action.get("count", 5)): swipe(0.5, 0.8, 0.5, 0.2, action.get("duration_ms", 200))

好处是新产品接入测试时，测试人员只需要改YAML，甚至都不需要碰Python。注意device_id在多设备池部署时要从环境变量或命令行参数传入，不要写死在配置里，否则CI并行跑会冲突。

参数说明：clear_data: true时执行pm clear，false则只重启App。duration_ms给滑动操作提供一个默认值，防止配置缺失。

5.2 接入持续集成：自动跑回归并把结果存档

在CI里做性能回归，核心是“自动”和“可追溯”。我一般把这个过程拆成三段：准备设备、运行场景、归档报表。

CI里的执行命令大致如下：

python prepare_device.py --device "$DEVICE_ID" --clean python run_perf.py --config cold_start.yaml --tag "$CI_COMMIT_SHORT_SHA" python report.py --tag "$CI_COMMIT_SHORT_SHA" --output reports/

prepare_device.py检查设备在线，执行上一章的屏幕常亮和进程清理。run_perf.py读配置跑场景，最后把原始CSV和事件日志存到reports/<tag>/。report.py把每轮结果汇总汇总成一个summary.csv，以便后续画趋势。

CI中还要记录被测App版本号，否则回归结果无法对应到代码提交。可以在run_perf.py里加：

def get_app_version(package): out = adb(f"dumpsys package {package} | grep versionName") m = re.search(r"versionName=([\d.]+)", out) return m.group(1) if m else "unknown"

这个版本号作为summary.csv的一列。性能问题出现后，翻趋势图看到某个版本下跌，就能直接定位到提交记录。

另外，CI任务是否失败要有阈值。比如帧率P95比前三次平均值下降超过5%，就让脚本返回非0退出码。这样性能劣化在发版前就能被拦住。

5.3 趋势图与基线阈值：让性能劣化在发版前被看见

每次跑完一轮，把关键指标摘要追加到summary.csv，字段至少包含日期、App版本、平均CPU、平均PSS、Jank帧数、P95帧间隔。接下来把趋势图画出来：

import pandas as pd import matplotlib.pyplot as plt df = pd.read_csv("summary.csv") df["date"] = pd.to_datetime(df["date"]) plt.figure(figsize=(12, 5)) plt.plot(df["date"], df["jank_count"], marker="o", label="Jank 帧数") plt.plot(df["date"], df["avg_mem"] , marker="s", label="平均 PSS (MB)") plt.legend() plt.xlabel("日期") plt.ylabel("指标值") plt.title("性能回归趋势") plt.savefig("trend.png")

趋势图的价值不是看具体数字，而是看突变。每周跑一次，连续积累一个月，那个突然上升的点就是某次代码改动引入的性能劣化。我习惯在图上把每个版本tag标在横轴下方，一旦看到某个版本曲线抬头，第一反应不是查代码，而是先找出那段时间里所有非功能性改动。

基线阈值从历史数据算，不要拍脑袋。例如：

baseline_jank = df["jank_count"].rolling(window=5).mean().iloc[-1] current_jank = df["jank_count"].iloc[-1] if current_jank > baseline_jank * 1.2: print("性能劣化提示: Jank 帧数超过基线20%")

这一章做完，性能脚本就不再是一次性的脚本，而是一个可持续发现问题的工具。

6. 进阶技巧：脚本时间轴对上系统Trace，定位掉帧函数

前面的脚本能告诉我们“哪里性能不行”，但还不能告诉我们“是哪个函数拖慢了帧率”。要做到这一步，需要把脚本的操作事件和系统Trace工具的时间轴对齐。常见做法是录制一段系统Trace，同时在脚本里往系统日志里写入标记，最后在Trace分析界面上同时看到操作事件和渲染栈。

6.1 在脚本里埋时间标记，导入Trace一起看

系统Trace工具可以抓取App主线程上的函数调用、渲染流水线和调度事件。让脚本在每次操作前向logcat输出一条带tag的消息，例如：

adb shell log -t perf_mark "swipe_1_start"

在脚本里，adb()封装直接调用这条命令即可。录制Trace时，系统Trace工具会同时采集logcat，标记就会出现在时间轴上。这样，Trace里每一段长长的函数调用，都对应了脚本里的一个操作。

启动Trace建议在PC端后台下命令：

adb shell perfetto -o /data/local/tmp/perfetto.trace -t 20s sched freq idle gfx view input &

参数含义：-t 20s是录制时长，sched freq idle gfx view input分别采集CPU调度、频率、空闲、图形、视图、输入事件。脚本在这20秒内运行完整个场景。结束后：

adb pull /data/local/tmp/perfetto.trace .

把Trace文件拖回PC，在Trace查看器里打开，能看到每一帧在主线程上的执行区间，以及耗时最长的调用。

6.2 用Trace找到导致卡顿的具体函数

在Trace时间线上，找到脚本标记“swipe_3_start”对应的时间窗，看主线程里有没有超过16ms的片段。如果每个滑动帧都出现一个耗时时长不稳的柱子，就点开看它对应的函数栈。

我印象最深的一次，是列表滑动时Jank帧率升高，Trace显示主线程反复执行一个图片解码函数，每次占时40ms左右。查原因发现是该函数内部做了同步磁盘读取。后来改成异步加载，帧率从45帧回到60帧。这轮定位耗时不到半天，如果只靠性能曲线，根本找不到根因。

最后提一个习惯：我每次在性能脚本里都强制要求操作动作和Trace标记成对出现，宁可少做两个步骤，也要保证标记完整。因为“能回放问题现场”是所有性能调试的起点。这个习惯陪我解决了十几次玄学卡顿。希望帮到你。

本文还有配套的精品资源，点击获取