29、ADB 高级技巧：adb shell dumpsys（全面系统信息）、adb bugreport（生成 Bug 报告）、实战：分析系统崩溃
到了这个阶段，咱们已经能熟练操作 ADB 的日常命令了。但说实话，那些只是皮毛。真正让 ADB 变得“高级”的，是它背后那套强大的系统诊断能力。今天我要聊的 dumpsys 和 bugreport，就是 Android 工程师手里的两把“手术刀”。
我个人习惯，遇到疑难杂症，第一反应不是去翻日志，而是先跑一把 dumpsys 看看系统整体状态。为什么？因为它快，而且信息全。你想想看，一个命令就能把当前内存、CPU、电池、网络、窗口、Activity 栈全拉出来，这比大海捞针地翻 logcat 高效多了。
29.1 adb shell dumpsys：系统信息的“万金油”
dumpsys 的全称是 “dump system services”。说白了，它就是 Android 系统里所有系统服务的“体检报告”。每个服务都可以 dump 出自己的状态。
基本用法很简单：
adb shell dumpsys但千万别这么干。不加参数的话，它会 dump 所有服务的信息，输出量能让你怀疑人生。我建议你指定服务名：
adb shell dumpsys activity activities // 查看 Activity 栈
adb shell dumpsys meminfo com.example.app // 查看某个 App 的内存
adb shell dumpsys battery // 查看电池状态
adb shell dumpsys window displays // 查看屏幕信息
adb shell dumpsys package com.example.app // 查看 App 的包信息这里我重点说几个我常用的。
29.1.1 查看 Activity 栈：定位页面跳转问题
我在项目中遇到过好几次，App 页面跳转后回不来了，或者闪退后页面状态不对。这时候 dumpsys activity activities 就是救命稻草。
adb shell dumpsys activity activities | grep "mResumedActivity"这条命令会输出当前处于前台（Resumed 状态）的 Activity。你能看到它的包名、类名、Task ID。如果发现某个 Activity 不该在前台，那问题就定位了。
dumpsys activity top。它还会显示当前 Activity 的 Intent 和 Fragment 信息，非常实用。
29.1.2 查看内存：揪出内存泄漏
内存泄漏是 Android 开发的老大难。我一般先用 dumpsys meminfo 看个大概：
adb shell dumpsys meminfo com.example.app输出里有个关键字段叫 PSS（Proportional Set Size）。它表示这个 App 实际占用的物理内存。如果 PSS 持续增长，而且 GC 后也不下降，那基本可以断定有内存泄漏了。
| 字段 | 含义 | 我的经验 |
|---|---|---|
| Total PSS | 总物理内存占用 | 超过 300MB 就要警惕了 |
| Native Heap | Native 层堆内存 | C++ 代码泄漏常出现在这里 |
| Dalvik Heap | Java 层堆内存 | Java 对象泄漏的“重灾区” |
| Graphics | 图形内存 | 图片加载不当会暴涨 |
29.1.3 查看电池：分析耗电问题
用户抱怨 App 耗电快？别急着背锅。先跑一下 dumpsys battery：
adb shell dumpsys battery输出里有个 level 字段表示当前电量，temperature 表示电池温度（单位是 0.1 摄氏度）。如果温度异常高，说明 CPU 或网络模块在疯狂工作。
更细粒度的分析，可以用 dumpsys batterystats。它会生成一份详细的耗电报告，包括每个 App 的 CPU 唤醒时间、网络流量、传感器使用情况。嗯，这里要注意，这个命令需要先重置统计：
adb shell dumpsys batterystats --reset
// 然后正常使用 App 一段时间
adb shell dumpsys batterystats > battery.txt打开 battery.txt，搜索你的包名，就能看到它到底干了什么“坏事”。
29.2 adb bugreport：生成 Bug 报告
bugreport 是 Android 系统提供的一键诊断工具。它会把 dumpsys、logcat、dmesg、trace 等所有信息打包成一个 ZIP 文件。说白了，它就是一份“系统快照”。
用法很简单：
adb bugreport执行后，它会生成一个类似 bugreport-设备名-日期.zip 的文件，保存在当前目录。解压后，里面有一个 bugreport-设备名-日期.txt 文件，内容非常庞大，通常有几万行。
dumpsys 就够了。
我曾经遇到过一个系统级 ANR，普通 logcat 根本看不出原因。后来我让测试同事跑了一个 bugreport，在报告里找到了 anr/traces.txt 文件，里面记录了所有线程的堆栈。最终定位到是一个 Binder 线程池耗尽导致的死锁。
29.3 实战：分析系统崩溃
好了，理论说完了。咱们来点实际的。假设你遇到了一个 App 闪退，而且不是每次都能复现。你会怎么做？
我的流程是这样的：
- 先抓 logcat：
adb logcat -b crash只看崩溃日志。 - 再跑 dumpsys：
adb shell dumpsys meminfo看内存是否异常。 - 最后上 bugreport：如果前两步没找到原因，就生成一份完整的报告。
下面我模拟一个场景。假设 App 在某个页面滑动时闪退。我们一步步分析。
步骤 1：抓取崩溃日志
adb logcat -b crash -d > crash.log打开 crash.log，搜索 FATAL EXCEPTION。你会看到类似这样的信息：
FATAL EXCEPTION: main
Process: com.example.app, PID: 12345
java.lang.OutOfMemoryError: Failed to allocate a 12345678 byte allocation with 1234567 free bytes and 1234KB until OOM
at android.graphics.BitmapFactory.nativeDecodeBitmap(Native Method)
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:900)
...嗯，OOM（内存溢出）了。而且是在解码 Bitmap 时发生的。这说明图片加载出了问题。
步骤 2：查看内存状态
adb shell dumpsys meminfo com.example.app输出里，Graphics 那一项可能高达几百 MB。这说明 App 加载了大量图片，而且没有及时释放。
步骤 3：生成 bugreport 做深度分析
adb bugreport解压后，打开 bugreport-xxx.txt，搜索 com.example.app。你会看到这个 App 的详细内存分布、打开的 Activity 数量、Binder 调用次数等。如果 Activity 数量异常多，说明有页面泄漏了。
logcat 定位异常类型，再用 dumpsys 看系统状态，最后用 bugreport 做全景分析。这三板斧下来，90% 的问题都能找到根因。
29.4 知识体系图
为了让你更直观地理解这三者的关系，我画了一张图：
这张图表达的意思很明确：dumpsys 是快速诊断，bugreport 是深度分析，而实战就是两者的结合。你不需要每次都上 bugreport，但遇到棘手问题时，它绝对是你最可靠的帮手。
好了，这一章的内容就到这里。记住，工具是死的，思路是活的。多练几次，你也能成为团队里的“崩溃终结者”。