文章

ADB 与调试工具深度解析——跨平台开发者的 Android 调试利器

面向跨平台开发者的 ADB（Android Debug Bridge）完全指南，从设备管理、日志分析、网络转发到 ANR/crash 日志抓取和远程调试，系统掌握 Android 调试工具链，让 Flutter/RN/鸿蒙开发调试效率翻倍。

发表于
作者 独行的风
33 分钟阅读
ADB 与调试工具深度解析——跨平台开发者的 Android 调试利器

一句话概括

ADB（Android Debug Bridge）是连接跨平台开发者与 Android 设备之间的万能桥梁——它既是设备管理器、又是日志服务器、还是调试通道和控制台，掌握 ADB 的核心命令和调试技巧，意味着你拥有了不依赖任何 IDE 来诊断和解决 Android 运行问题的能力。

背景与意义

如果你有过这样的经历：Flutter 热重载突然连接不上模拟器、React Native 的 Metro bundler 报一堆”无法连接到设备”的错误、或者某个只出现在真机上的 bug 你完全不知道该从哪里下手排查——那你一定需要掌握 ADB。

对于原生 Android 开发者来说，ADB 是日常工作的一部分。但对于 Flutter、React Native 和鸿蒙开发者来说，ADB 往往是一个”被隐藏的工具”——框架的 CLI 命令（如 flutter run、react-native run-android）帮你封装了 ADB，让你在开发调试过程中几乎感知不到 ADB 的存在。

然而，一旦出现问题——无论是设备连接失败、日志无法获取、还是热重载中断——这些封装层往往无法提供足够详细的诊断信息。这时候，你需要直接使用 ADB 来定位问题。

更关键的是，ADB 能做的事情远不止”连接设备”：你可以用它查看系统日志、抓取 ANR（应用无响应）报告、分析内存使用、模拟屏幕操作、以及进行网络调试。对于跨平台开发者来说，这些能力是连接应用层与 Android 底层系统的关键。

本文将系统性地梳理 ADB 的核心用法，并以跨平台开发者的视角重点讲解那些最有价值的调试场景。

核心知识点拆解

ADB 基础：三大组件与工作原理

ADB 是一个 C/S（客户端-服务器）架构的工具，包含三个部分：

  1. ADB Client：运行在你的开发机器上，这是你直接使用的命令行工具（adb）
  2. ADB Server：同样运行在开发机器上，是一个后台进程，负责管理 ADB Client 和设备之间的通信
  3. ADB Daemon（adbd）：运行在 Android 设备或模拟器上的守护进程，处理来自 ADB Server 的命令

当你执行 adb devices 时，实际流程是：

  1. ADB Client 向 ADB Server 发送请求（如果 Server 未启动，Client 会先启动它）
  2. ADB Server 连接设备上的 adbd 守护进程
  3. 信息返回给 ADB Server 再转发给 ADB Client

这个架构设计的优点是：你可以通过 TCP/IP 远程连接设备，而不仅仅是 USB 连接。对于跨平台开发来说，这意味着你可以调试一台在实验室或远程机房的设备。

安装 ADB

ADB 是 Android SDK Platform-Tools 的一部分。安装方式：

1
2
3
4
5

# macOS（通过 Homebrew）
brew install android-platform-tools

# 验证安装
adb --version

如果你使用的是 Flutter，ADB 通常已经随 Flutter SDK 一同下载。可以通过 flutter doctor 检查 ADB 环境是否正常。

设备管理：从连接到断开

列出已连接的设备

1

adb devices

输出示例：

1
2
3

List of devices attached
emulator-5554   device
RF8N203KSDD    device
  • device：设备已连接且正常工作
  • offline：设备已连接但无法通信，需要重启 ADB 或设备
  • unauthorized：设备请求连接但未在设备上确认授权（需要在手机上点”允许 USB 调试”）
  • no device：没有连接的设备

连接和断开设备

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# USB 连接：自动识别，不需要额外命令

# 通过 Wi-Fi 连接（Android 11+）
adb pair ip地址:端口    # 先配对
adb connect ip地址:端口  # 再连接

# 通过 TCP/IP 连接（Android 10 及以下）
adb tcpip 5555                        # 先在 USB 连接状态下切换为 TCP 模式
adb connect 设备IP:5555               # 然后通过 IP 连接

# 断开设备
adb disconnect 设备IP:5555

# 重启 ADB Server（解决各种连接问题）
adb kill-server
adb start-server

针对特定设备执行命令

当连接了多台设备时，使用 -s 参数指定目标设备：

1
2

adb -s emulator-5554 install app.apk
adb -s RF8N203KSDD logcat -c

安装和卸载应用

基础安装

1
2
3
4
5
6
7
8
9
10
11

# 安装 APK
adb install app-release.apk

# 覆盖安装（保留数据）
adb install -r app-release.apk

# 安装到 SD 卡（如果设备支持）
adb install -s app-release.apk

# 降级安装（允许版本号降低）
adb install -d app-release.apk

调试安装

对于跨平台开发者来说，-t 参数特别有用——它允许安装测试 APK（targetSdkVersion 高于设备 API 级别的 APK）：

1

adb install -t app-debug.apk

卸载应用

1
2
3
4
5

# 通过包名卸载
adb uninstall com.example.myapp

# 保留数据目录
adb uninstall -k com.example.myapp

获取包名的快速方法：

1
2
3
4
5

# 方案一：列出所有已安装应用的包名
adb shell pm list packages | grep 关键词

# 方案二：对于正在运行的应用
adb shell dumpsys window | grep mCurrentFocus

Flutter/RN 项目中实际使用的安装命令

在 Flutter 项目中，当你运行 flutter run 时，底层实际上是依次执行了 adb install、adb shell am start 等命令。如果你遇到”安装失败”的问题，可以直接使用 ADB 重新安装来获取更详细的错误信息：

1
2
3

# Flutter 构建后直接使用 ADB 安装
flutter build apk --debug
adb install build/app/outputs/flutter-apk/app-debug.apk

对于 React Native：

1
2
3

react-native bundle --platform android --dev false --entry-file index.js --bundle-output android/app/src/main/assets/index.android.bundle
cd android && ./gradlew assembleDebug
adb install app/build/outputs/apk/debug/app-debug.apk

ADB Shell：深入设备内部

adb shell 是 ADB 中最强大的命令之一，它可以让你在 Android 设备上执行任意 Linux 命令，相当于在设备上打开了一个终端窗口。

基础用法

1
2
3
4
5
6
7
8

# 进入交互式 shell
adb shell

# 直接在宿主机上执行命令
adb shell ls /data/data/
adb shell cat /proc/meminfo
adb shell dumpsys battery
adb shell dumpsys wifi

文件操作

1
2
3
4
5
6
7
8

# 从设备拷贝文件到本地
adb pull /sdcard/Download/crash.log ./crash.log

# 从本地拷贝文件到设备
adb push ./config.json /sdcard/Download/

# 查看设备目录树
adb shell find /sdcard/ -name "*.txt"

应用管理相关 shell 命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 查看应用列表（按包名显示）
adb shell pm list packages

# 查看应用的详细信息
adb shell dumpsys package com.example.myapp

# 启动一个应用
adb shell monkey -p com.example.myapp 1

# 强制停止应用
adb shell am force-stop com.example.myapp

# 清除应用数据（相当于"清除存储"）
adb shell pm clear com.example.myapp

文件权限问题

跨平台开发者最容易遇到的一个问题：使用 adb push 将文件推送到 data/data/ 目录时，会遇到权限拒绝。这是因为 data/data/ 目录对非 root 设备不可写。

解决方法：

  1. 对于一些需要写入应用私有目录的文件，可以使用 run-as 命令（仅限 Debug 版本的应用）
  2. 或者先把文件推送到 /sdcard/，再通过应用自身的代码复制到私有目录
1
2

# 以应用的 UID 执行命令
adb shell run-as com.example.myapp cat /data/data/com.example.myapp/databases/mydb.db > ./mydb_backup.db

logcat：日志分析的艺术

logcat 是 Android 系统的日志工具，所有来自应用、系统服务和框架层的日志都会汇集到这里。对于跨平台开发者来说，它是连接应用层与系统层的”望远镜”。

日志格式

Android 的日志系统有四个级别（从低到高递增）：

  • V（Verbose）：详细日志，仅用于开发阶段
  • D（Debug）：调试信息
  • I（Info）：普通信息
  • W（Warning）：警告信息
  • E（Error）：错误信息
  • F（Fatal）：致命错误

每条日志记录包含：日期时间、进程 ID、线程 ID、日志级别、Tag 标签、消息内容。

基础用法

1
2
3
4
5
6
7
8
9
10
11
12
13

# 最简单的使用——持续输出所有日志
adb logcat

# 清空历史日志
adb logcat -c

# 只输出错误级别及以上的日志
adb logcat *:E

# 按标签过滤
adb logcat -s Unity
adb logcat -s ReactNativeJS:V
adb logcat -s flutter:* I

日志过滤技巧

按标签和级别组合过滤

1
2
3
4
5

# 只输出 Flutter 标签的警告和错误
adb logcat -s flutter:W

# 同时过滤多个标签
adb logcat -s flutter:V ReactNativeJS:V *:S

这里的 *:S 表示”所有其他标签静默”，使得只有指定的标签的日志会显示。

按进程 ID 过滤

1
2
3
4
5
6
7

# 先获取你的应用的 PID
adb shell pidof com.example.myapp
# 或
adb shell ps | grep com.example.myapp

# 按 PID 过滤日志
adb logcat --pid=12345

时间戳过滤

1
2
3
4
5

# 只显示某个时间点之后的日志
adb logcat -t "2026-09-29 14:00:00.000"

# 显示最近的 n 行
adb logcat -t 500

保存日志到文件

1
2
3
4
5
6
7
8

# 将日志保存到本地文件
adb logcat -d > app_logs.txt

# 持续保存到文件
adb logcat -f /sdcard/Download/logs.txt

# 带时间戳保存
adb logcat -v time > app_logs_with_time.txt

ADB Forward/Reverse：网络调试的核心

adb forward：将设备端口映射到宿主机

adb forward 将宿主机的一个端口转发到设备上的端口。对于跨平台开发者，最常见的场景是调试 React Native 或 Flutter 的热重载。

1
2
3
4
5

# 将设备上的 8081 端口转发到宿主机的 8081 端口
adb forward tcp:8081 tcp:8081

# 将设备上的 Unix socket 转发到宿主机端口
adb forward tcp:5497 localabstract:chrome_devtools_remote

React Native 的热重载原理：

当你运行 react-native start 时，Metro bundler 在宿主机的 8081 端口上启动了一个 HTTP 服务器。当你在真机上运行 RN 应用时，应用需要访问这个服务器获取 JavaScript Bundle。

ADB forward 在这里的作用是：将设备上的 8081 端口请求转发到宿主机的 8081 端口。这相当于在设备和宿主机之间建立了一个隧道。

1
2
3

# RN 开发中的典型配置
adb forward tcp:8081 tcp:8081
adb reverse tcp:8081 tcp:8081

adb reverse：将宿主机端口映射到设备

adb reverse 是 adb forward 的反向操作——它将宿主机的一个端口转发到设备上的端口。这在不同场景中都非常有用。

1
2
3
4
5

# 将宿主机 8081 端口的请求转发到设备 8081 端口
adb reverse tcp:8081 tcp:8081

# 常见用途：在真机上调试时，让设备访问宿主机的本地服务器
adb reverse tcp:3000 tcp:3000  # 将设备上的请求转发到宿主机正在运行的开发服务器

Flutter 热重载依赖 adb forward：

Flutter 使用 flutter run 启动应用时，底层会通过 adb forward 建立一个调试通道。当你修改代码并保存时，Flutter 引擎会通过这个通道将增量更新（incremental changes）推送到设备上的 Dart VM，从而触发热重载。

如果这个 forward 通道中断了（比如 USB 线接触不良），热重载就会失败——你会在终端看到 “Error connecting to the service protocol” 或 “Lost connection to device” 的错误信息。

此时，手动检查 ADB 连接状态通常是第一步：

1
2
3
4

adb kill-server
adb start-server
adb devices
# 确认设备已显示在列表中

抓取 ANR 和 Crash 日志

ANR 的成因

ANR（Application Not Responding）发生在主线程被阻塞超过一定时间时：

  • 输入事件（触摸/按键）超过 5 秒未响应
  • BroadcastReceiver 超过 10 秒未返回
  • Service 超过 20 秒未完成

对于跨平台开发者来说，常见的导致 ANR 的原因包括：

  • Flutter 的 compute 函数中执行了耗时操作阻塞了 UI 线程
  • RN 的 JavaScript 线程执行了长时间的同步计算
  • 原生端在主线程中调用了阻塞 API（如网络请求、大文件读写）

什么是 traces.txt

当发生 ANR 时，Android 系统会在 /data/anr/traces.txt 文件中记录所有线程的堆栈信息。这个文件包含了 ANR 发生时系统中最关键的信息——每个线程在做什么、锁竞争情况、GC 状态等。

获取 ANR 日志：

1
2
3
4
5

# 方法一：直接拉取
adb pull /data/anr/traces.txt

# 如果权限不足，可以尝试
adb shell cat /data/anr/traces.txt > traces.txt

文件权限的问题：在非 Root 设备上，可能需要先 adb root（仅限模拟器或已 Root 的真机）。对于未 Root 的真机，抓取 ANR 日志最好使用 adb bugreport：

1

adb bugreport bugreport.zip

这个命令会收集完整的设备信息并打包成一个 ZIP 文件，其中包含 ANR 日志、内存信息、系统日志等。

使用 adb logcat 抓取 Crash 日志

当应用崩溃时，日志中会包含崩溃信息。对跨平台开发者来说，原生层的崩溃（如 Java/Kotlin 层的 Exception）和框架层的崩溃（如 Flutter 引擎崩溃）的抓取方式不同：

1
2
3
4
5
6
7
8
9
10
11

# 抓取所有应用崩溃相关的日志
adb logcat -s AndroidRuntime:E

# 抓取 Native 层（C/C++）崩溃
adb logcat -s DEBUG

# 抓取 Flutter 引擎错误
adb logcat -s flutter:E

# 组合过滤
adb logcat -s AndroidRuntime:E DEBUG:E flutter:E *:S

实时监控和分析

对于间歇性崩溃，最好的方式是将日志输出到文件并在崩溃时查看：

1
2
3
4
5
6
7
8
9

# 在终端 A：持续记录日志
adb logcat -v time > full_log.txt

# 在终端 B：操作应用直到崩溃
# ...

# 崩溃后，在终端 A 按 Ctrl+C 停止记录
# 然后搜索 "FATAL EXCEPTION" 或 "crash"
grep -n "FATAL EXCEPTION\|crash\|ANR" full_log.txt

dumpsys：系统状态快照

adb shell dumpsys 是一个功能极其强大的命令，它可以输出 Android 系统中几乎任何服务的信息。对于跨平台开发者，以下是最有价值的子命令：

查看 Activity 栈

1
2
3
4
5

# 查看当前显示的 Activity
adb shell dumpsys activity | grep mCurrentFocus

# 查看当前应用的所有 Activity 栈
adb shell dumpsys activity activities

这对检查你的 Flutter/RN 应用的 Activity 状态特别有用——比如验证应用是否正确启动了 Native 模块的 Activity。

查看内存信息

1
2
3
4
5
6
7
8

# 查看应用内存使用
adb shell dumpsys meminfo com.example.myapp

# 查看全局内存状态
adb shell dumpsys meminfo

# 查看内存压力级别
adb shell dumpsys meminfo --memorycap

dumpsys meminfo 的输出包括：

  • Dalvik Heap：Java/Kotlin 堆内存使用
  • Native Heap：C/C++ 原生堆内存
  • Graphics：显存使用（对于 Flutter 应用来说非常重要）
  • Stack：栈内存
  • Code：代码占用的内存
  • Total：总计

对于 Flutter 应用，由于 Flutter 引擎使用 Skia 进行渲染，Graphics 行的数值值得特别关注——它反映了 GPU 内存的消耗。

查看电池信息

1
2
3
4
5
6
7
8
9
10
11
12

# 查看电池状态
adb shell dumpsys battery

# 设置电量（测试低电量场景）
adb shell dumpsys battery set level 10

# 模拟充电/不充电
adb shell dumpsys battery set status 2  # 充电中
adb shell dumpsys battery set status 1  # 未充电

# 重置电池设置
adb shell dumpsys battery reset

查看网络和 Wi-Fi 信息

1
2
3
4
5
6
7
8

# 查看 Wi-Fi 连接信息
adb shell dumpsys wifi

# 查看网络统计
adb shell dumpsys netstats

# 查看连接的网络接口
adb shell dumpsys connectivity

查看窗口信息

1
2
3
4
5
6
7
8

# 查看当前窗口的详细状态
adb shell dumpsys window windows

# 查看屏幕尺寸和密度
adb shell dumpsys display

# 获取当前显示的 Activity 和 Fragment
adb shell dumpsys activity top

截图和录屏

截图（screencap）

1
2
3
4
5
6
7
8

# 截图并保存到设备
adb shell screencap /sdcard/Download/screenshot.png

# 直接保存到本地
adb exec-out screencap -p > screenshot.png

# 使用 dumpsys+截图获取窗口信息
adb shell screencap -p /sdcard/Download/screen.png && adb pull /sdcard/Download/screen.png

对于 React Native 开发者，在使用原生 UI 组件时，截图功能可以帮助你判断组件是否在屏幕上正确显示。

录屏（screenrecord）

1
2
3
4
5
6
7
8
9
10
11

# 开始录屏（默认 4 分钟，保存在设备上）
adb shell screenrecord /sdcard/Download/demo.mp4

# 指定录制时长（秒）
adb shell screenrecord --time-limit 30 /sdcard/Download/demo.mp4

# 指定分辨率和码率
adb shell screenrecord --size 720x1280 --bit-rate 4000000 /sdcard/Download/demo.mp4

# 拉取录屏文件
adb pull /sdcard/Download/demo.mp4 ./demo.mp4

对于跨平台开发者来说，录屏功能在性能分析时特别有用——你可以录制一段操作，然后逐帧分析 UI 渲染的性能问题。

实战案例

案例一：Flutter 热重载连接失败排查

问题描述：Flutter 开发者正在真机上运行应用，一切正常，但突然热重载失效。终端输出：

1

Error connecting to the service protocol: HttpException: Connection closed before full header was received

排查过程：

  1. 检查 ADB 连接状态：
    1
2
3

    $ adb devices
List of devices attached
RF8N203KSDD   device

    设备连接正常。

  2. 检查是否有多个 ADB 进程冲突：
    1

    $ ps aux | grep adb

    发现有两个 ADB server 在运行——一个来自 Flutter SDK，一个来自系统安装的 platform-tools。这会导致端口冲突。

  3. 清理 ADB 进程：
    1
2

    $ adb kill-server
$ adb start-server
  4. 重新连接设备：
    1

    $ adb devices
  5. 重新运行 Flutter 应用：
    1

    $ flutter run

    热重载恢复正常。

根本原因：同时安装了多个版本的 Android SDK Platform-Tools，导致 ADB Server 端口冲突。

案例二：React Native 真机调试无法连接 Metro Bundler

问题描述：RN 应用在真机上运行，Metro bundler 已经在 8081 端口启动，但设备始终显示”无法连接”。

排查过程：

  1. 检查 Metro bundler 是否启动：
    1
2
3

    $ lsof -i :8081
COMMAND   PID  USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
node    12345 user   22u  IPv4 0x...      0t0  TCP *:8081 (LISTEN)

    Metro 正常。

  2. 检查 ADB forward 是否存在：
    1
2

    $ adb forward --list
RF8N203KSDD tcp:8081 tcp:8081

    forward 存在。

  3. 尝试使用 adb reverse：
    1

    $ adb reverse tcp:8081 tcp:8081

    有时候 forward 方式在 Android 10 及以上版本中会有问题，改用 reverse 可以解决。

  4. 检查设备网络：
    1

    $ adb shell dumpsys wifi | grep "mNetworkInfo"

    确认设备已连接到与开发机器同一 Wi-Fi 网络。

  5. 在 Metro 终端重启 bundler：
    1

    Metro bundler 已经收到连接请求，重新建立通信。

最终解决：使用 adb reverse 代替 adb forward，并且确保设备与电脑在同一网络下。

案例三：使用 logcat 和 dumpsys 定位内存泄漏

问题描述：某 Flutter 应用在长时间使用后变得卡顿，且偶尔崩溃，怀疑存在内存泄漏。

排查过程：

  1. 启动并记录初始内存：
    1

    $ adb shell dumpsys meminfo com.example.myapp > mem_before.txt

  2. 执行可疑操作（多次打开关闭某个页面）。

  3. 记录操作后的内存：
    1

    $ adb shell dumpsys meminfo com.example.myapp > mem_after.txt
  4. 对比内存变化：
    1

    $ diff mem_before.txt mem_after.txt

  5. 关键发现：Native Heap 和 Graphics 内存持续增长，每次页面打开关闭后都增加约 5MB 且不释放。

  6. 抓取详细日志确认：
    1

    $ adb logcat -s flutter:E AndroidRuntime:E | grep -i "memory\|leak\|allocate"

结论：页面中有 Flutter 图片资源没有被正确释放，导致每次页面销毁时图像缓存仍然保留。通过在页面 dispose 时主动调用 imageCache.clear() 解决。

案例四：抓取并分析 ANR 日志

问题描述：RN 应用在使用推送通知时偶尔出现 ANR。

排查过程：

  1. 触发 ANR 后立即获取日志：
    1

    $ adb bugreport bugreport_$(date +%Y%m%d_%H%M%S).zip
  2. 解压并查找 ANR 报告：
    1
2

    $ unzip bugreport_*.zip
$ find . -name "traces.txt" -exec cat {} \;
  3. 分析 traces.txt 中的主线程堆栈：
    1
2
3
4

    "main" prio=5 tid=1 Blocked
  at com.example.rnapp.MainActivity.onCreate(Native Method)
  - waiting to lock <0x...> (a java.lang.Object) held by thread 23
  at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3589)
  4. 定位问题：主线程在等待一个锁，这个锁被另一个线程持有了超过 5 秒。进一步分析发现是推送 SDK 的回调处理中，在 IntentService 中执行了数据库操作，但由于某个异常未释放锁。

解决方案：更新推送 SDK 版本，并在应用层添加超时保护和异常捕获。

常见问题

Q1：adb devices 显示设备列表为空，但设备确实连接了

排查步骤：

  1. 换一根 USB 线（数据线而非充电线）
  2. 在设备上检查”开发者选项”→”USB 调试”是否开启
  3. 在设备上重新授权：撤销 USB 调试授权后重新连接
  4. 重启 ADB Server：adb kill-server && adb start-server
  5. macOS/Linux 检查 USB 权限：lsusb 确认设备是否被识别

Q2：adb install 安装失败，提示 “INSTALL_FAILED_UPDATE_INCOMPATIBLE”

这意味着设备上已安装的版本与新安装版本签名不一致。解决方案：

  1. 卸载旧版应用：adb uninstall com.example.myapp
  2. 确认新旧版本使用的是相同的签名密钥
  3. 确认包名是否一致

Q3：logcat 输出太多，根本找不到我的应用的日志

使用精确的包名匹配和标签过滤：

1
2
3
4
5
6
7
8

# 方法一：按 PID 过滤
adb logcat --pid=$(adb shell pidof com.example.myapp)

# 方法二：使用 grep 过滤包名
adb logcat | grep "$(adb shell pidof com.example.myapp)"

# 方法三：结合标签和级别
adb logcat -s flutter:V ReactNativeJS:V *:S

Q4：真机调试时，adb forward/reverse 无法建立连接

检查以下问题：

  1. 设备是否有多个（导致 forward 命令发送到了错误的设备）→ 使用 -s 指定设备
  2. 端口是否被占用 → lsof -i :端口号 检查
  3. 设备是否开启了网络权限 → 检查开发者选项中的”网络 ADB 调试”
  4. Wi-Fi 和设备是否在同一网络（对于 reverse 模式）

Q5：如何在不使用 Android Studio 的情况下查看 Flutter 应用的日志？

完全不需要 Android Studio。使用以下组合拳：

1
2
3
4
5
6
7
8

# 启动 Flutter 应用
flutter run & 

# 在另一个终端查看原生日志
adb logcat -s flutter:V *:S

# 或使用 Flutter 自带的日志查看
flutter logs

flutter logs 命令本质上就是封装后的 adb logcat，它会自动过滤出 Flutter 引擎相关的日志。

总结

ADB 是 Android 开发调试的基石。无论你使用的是 Flutter、React Native 还是原生 Android，ADB 提供的设备管理、日志分析、网络转发和系统诊断能力都是不可或缺的。

对于跨平台开发者来说，以下是最值得掌握的核心 ADB 技能：

  1. 设备连接与故障排查：adb devices、adb kill-server、无线调试——这是所有调试工作的基础
  2. 日志分析：adb logcat 的各种过滤技巧——这是解决运行时问题的第一工具
  3. 网络转发：adb forward 和 adb reverse——这是热重载和开发服务器连接的核心
  4. 系统诊断：adb shell dumpsys——这是定位内存、性能、ANR 问题的利器
  5. Bug 报告：adb bugreport——在遇到难以重现的问题时，它能提供最全面的设备状态快照

最后分享一个技巧：将常用的 ADB 命令封装成 Shell 脚本或别名，可以大幅提高调试效率。例如，将以下内容添加到你的 .zshrc 或 .bashrc 中：

1
2
3
4
5
6
7
8
9
10

# 抓取 Flutter 应用日志
alias flogs='adb logcat -s flutter:V *:S'

# 抓取 RN 应用日志
alias rnlogs='adb logcat -s ReactNativeJS:V *:S'

# 按包名过滤日志
function applog() {
  adb logcat --pid=$(adb shell pidof $1)
}

掌握 ADB，你就不再是一个只知道”运行 flutter run”的开发者，而是一个能够深入 Android 系统底层、独立诊断各种奇怪问题的调试专家。

原生扩展, Android
原生扩展 Android ADB 调试 logcat dumpsys 热重载
本文由作者按照 CC BY 4.0 进行授权