App 卡顿、发热、耗电, 用 adb 看数据说话

App 卡顿、发热、耗电，开发第一句话就是"你复现一下"。

光说"很卡"没用，你得拿出数据。

adb 自带性能监控命令，不用装任何第三方工具。这篇文章把常用的几个命令讲清楚。

第一步：先连上设备

USB 连接：手机开开发者模式，USB 调试打开，插上数据线，终端执行：

adb devices

看到设备编号加 device 状态，连接成功。

无线连接（手机不方便插线时）：手机和电脑连同一个 Wi-Fi，先 USB 连一次执行：

adb tcpip 5555

然后拔线，执行：

adb connect 手机IP:5555

手机IP在哪看：设置-关于手机-状态信息-Wi-Fi的IP地址。

第二步：CPU 占用

adb shell top -n 1

-n 1 表示只取一次快照（不写会一直刷新）。

输出重点看两列：

· PID：进程号· CPU%：CPU占用率

怎么判断有没有问题：被测 App 的 CPU% 持续超过 50% 不降，大概率有问题。

更精确的用法：指定只看某个进程：

adb shell top -n 1 -p 进程号

先跑一次 top 找到被测 App 的 PID，再盯它。

注意：页面静止时 CPU 应该接近 0。如果啥都不干 CPU 还一直 20%+，后台在偷跑，提单。

第三步：内存使用

adb shell dumpsys meminfo 包名

包名怎么看：adb shell pm list packages | findstr 关键词

输出重点看三个值：

· Total PSS：进程真实占用的物理内存，最准的指标· Java Heap：Java 层内存· Native Heap：底层（C/C++）内存

怎么判断有没有问题：重点观察一个现象：反复进出页面，Total PSS 持续上涨不回落，就是内存泄漏。

比如：进首页 Total PSS 是 80MB，出来再进变成 100MB，反复操作涨到 150MB 不降。这就是泄漏的典型特征。

顺手看 GC 次数，GC 频繁说明内存压力大，App 会卡。

第四步：帧率（卡顿）

adb shell dumpsys gfxinfo 包名

关键概念：一帧超过 16ms，人眼就能感觉到卡顿（60帧/秒的极限）。

找两个数：

· 超过 16ms 的帧数占比：占比高 = 卡顿明显· Janky frames（卡顿帧）数量：直接给的结论

用法：在页面里滑动操作 30 秒，然后执行命令，看这段时间的帧数据。滑动时卡顿帧明显变多，就是页面渲染有问题。

第五步：电量与流量

电量：

adb shell dumpsys batterystats

看哪个应用耗电最多、前台/后台耗电分布。重点场景：用户反馈"这App后台耗电严重"，就用这个命令查。后台耗电占比高，说明有后台任务在跑。

流量：

adb shell dumpsys netstats

重点场景：用户反馈"流量跑得飞快"，查一下是不是 App 在后台频繁请求接口。配合 Network 抓包看请求频率，实锤。

第六步：自动化采集

手动敲命令太累，写个循环脚本。每 5 秒采集一次 CPU 和内存，压测时后台跑，结束后把数据存成文件。

循环 100 次：  adb shell top -n 1 >> cpu.txt  adb shell dumpsys meminfo 包名 >> mem.txt  等待 5 秒

为什么值得做：单次快照看不出趋势，数据对比才有说服力。压测前采集一份"基线数据"，压测中持续采集，结束后对比：内存涨了多少、CPU 峰值多少。报告里贴两组数据，开发没法反驳。

· · ·

5个命令速查表

写到最后

性能问题，最怕"我觉得很卡"。

学会用 adb 拿数据，你的 Bug 单会完全不一样：

"App 进入订单列表滑动时，Janky frames 从 2 涨到 40，CPU 峰值 65% 持续 10 秒。"

开发拿到这种提单，第一反应不是质疑，而是去查代码。

数据，是测试最硬的底气。