Android应用的调试

学习目标

• 能沿“Android应用的调试”的用户事件解释Android组件、状态所有者、线程与销毁边界。
• 能围绕“掌握 Android Studio 调试工具——Logcat 日志过滤、断点调试、变量监视和堆栈追踪分析。”改出一个可运行结果，并用前后状态而非组件数量验收。
• 能在旋转、进程重建、拒权、离线或无效输入中选择适用反例，定位首个状态分叉。
• 能用构建指纹、用户操作、状态快照、原始日志和行为断言独立重放结论，并标明第四版机制与现代targetSdk政策的边界。

Bug 来了——先看黑匣子

用户说「闪退」，你的第一步不是改代码，而是打开 Logcat。配合断点和堆栈追踪，大多数问题能在十分钟内定位到文件和行号。

Logcat 过滤

典型崩溃行：

E/AndroidRuntime: FATAL EXCEPTION: main
    java.lang.NullPointerException
    at com.example.MainActivity.onCreate(MainActivity.kt:42)

读法：异常类型 → 你的包名 → 行号。

⚡分步1 / 4

1. 1
2. 2
3. 3
4. 4

① 选择日志级别

在 Logcat 顶部下拉框将 Log Level 设为 Error（或 Warn+Error），过滤掉无关的 Debug 和 Verbose 输出。崩溃日志的优先级一定是 Error。

上一步重置播放下一步

断点调试

类型	用途
普通断点	暂停查看变量
条件断点	如 index == 99，循环里只停一次
异常断点	Run → View Breakpoints → Any exception，崩溃即停

堆栈追踪

从下往上读，第一个你的包名通常是根因：

at com.example.MainActivity.loadData(MainActivity.kt:42)  ← 根因
at com.example.MainActivity.onCreate(MainActivity.kt:18)
at android.app.Activity.performCreate(...)

小结

• Crash → Logcat Error + 堆栈第一行自己的代码
• ANR → 主线程堆栈找阻塞点
• 断点：条件断点省时间，异常断点抓崩溃

练习

问题 1：“第5章 Debugging Android Apps”覆盖哪些正式节点和项目主线？

查看答案

覆盖5个节点，从“5. Debugging Android Apps”到“Challenge: Exploring the Profiler”。主线是从症状、异常栈和最后可信边界定位问题，并组合断点、Lint、Layout Inspector与Profiler，交付物是故障复现步骤、最小失败输入、栈帧解释和修复回归测试。

问题 2：怎样建立本页最小可执行实验？

查看答案

在“Android应用的调试”的验证中，固定JDK、SDK、Gradle、设备API、语言、权限和输入，完成一个从用户动作到可观察结果的垂直切片；保存干净构建、设备操作、原始日志、状态快照与断言。

问题 3：为什么只在正常点击路径运行不能证明完成？

查看答案

它没有覆盖组件重建、进程死亡、异步取消、权限拒绝、外部输入失败、资源释放和版本变化。应逐项注入故障，并用故障复现步骤、最小失败输入、栈帧解释和修复回归测试核对。

问题 4：怎样设计能推翻当前实现的反例？

查看答案

在“Android应用的调试”的验证中，保持其他变量不变，分别注入旋转、后台回收、进程死亡、拒权、断网、无效输入与重复操作；任何状态丢失、越权、崩溃、泄漏或重复副作用都推翻完成结论。

问题 5：从第4版语境迁移到现代目标SDK时如何控制变量？

查看答案

先按原书还原机制并锁定基线，再查询目标SDK合同；一次只迁移组件导出、存储、权限、后台、通知或依赖之一，保存构建、行为、测试和回滚差异。

问题 6：本页达到独立交接标准需要什么？

查看答案

需要版本与设备指纹、源码提交、输入、构建命令、生命周期轨迹、原始日志、失败测试、安全边界与发布产物，让他人凭故障复现步骤、最小失败输入、栈帧解释和修复回归测试重放。

名词解释

本章出现的专业名词，用大白话再讲一遍。

Logcat

Android Studio 中显示系统和应用运行时日志的窗口，按时间与级别输出调试信息。排查闪退、异常的第一站。

ANR

Application Not Responding——主线程阻塞超约 5 秒，系统弹窗。常见原因：主线程 IO、死锁、过度布局。

堆栈追踪（Stack Trace）

异常时的方法调用链。从下往上读，定位第一个业务代码帧。

“Android应用的调试”不使用未获授权的纸书正文；InformIT出版信息与授权电子版完整目录只用于确认第四版32章、269个正式目录节点和时代语境，第四版官方勘误用于识别工具链变更。下列中文解释、图示、交互、代码与练习均为独立教学重写，平台行为再以Android Developers的一手文档复核。

为什么“Android应用的调试”必须回到可观察状态

“Android应用的调试”的学习结果不是记住类名，而是能预测“掌握 Android Studio 调试工具——Logcat 日志过滤、断点调试、变量监视和堆栈追踪分析。”在一次输入、一次重建和一次失败中的不同状态，并指出哪条Android合同产生差异。

第四版机制逐项深读

5. Debugging Android Apps

在“Android应用的调试”中，“5. Debugging Android Apps”从症状回溯首个异常帧、日志事件或状态分叉；修复证据必须包含可复现输入和失败前后的同一断言。

Exceptions and Stack Traces

在“Android应用的调试”中，分析“Exceptions and Stack Traces”区分编译、运行时、布局、线程与资源问题，避免在后续连锁报错处停止定位。

Android-Specific Debugging

在“Android应用的调试”中，“Android-Specific Debugging”从症状回溯首个异常帧、日志事件或状态分叉；修复证据必须包含可复现输入和失败前后的同一断言。

Challenge: Exploring the Layout Inspector

在“Android应用的调试”中，“Challenge: Exploring the Layout Inspector”的视觉正确性必须与语义树一致；看得见但读屏无名称、焦点不可达或点击区过小仍判失败。

Challenge: Exploring the Profiler

在“Android应用的调试”中，分析“Challenge: Exploring the Profiler”区分编译、运行时、布局、线程与资源问题，避免在后续连锁报错处停止定位。

“Android应用的调试”验收回顾

“Android应用的调试”只有在构建指纹、用户操作、状态快照、原始日志和行为断言能够从相同基线再次得到相同断言时才通过；第四版机制与现代平台政策分别记录，不用新API名称掩盖旧行为。

← 上一页：UI状态的保存与恢复 · 下一页：第二个Activity →

章专属可重放状态实验

先预测“重放最小失败用例并一次只改变一个原因”发生后，测试、Logcat、断点与问题工件的责任人应怎样改变失败输入、线程、异常、调用栈和修复假设；再操作三个实验。第四版示例与当前 Android 政策分别记录，实验不把新 API 名称倒填为原书内容。

实验一：所有者—状态—结果合同

选择任一正式目录节点和正常/边界场景，检查它是否真的进入本章状态合同。目录标题只有同时出现在解释、可视状态和交付证据中才算覆盖。

Owner · state · observable result

Android应用的调试：状态合同

从稳定失败、堆栈首个业务帧和设备状态定位 Android 缺陷

重置实验

验证场景

正常任务边界恢复

第四版正式目录节点

5. Debugging Android AppsExceptions and Stack TracesAndroid-Specific DebuggingChallenge: Exploring the Layout InspectorChallenge: Exploring the Profiler

debugging · 正常任务

5. Debugging Android Apps：固定 SDK、设备配置和初始状态，触发“重放最小失败用例并一次只改变一个原因”

状态所有者测试、Logcat、断点与问题工件的责任人

受控状态失败输入、线程、异常、调用栈和修复假设

触发事件重放最小失败用例并一次只改变一个原因

冻结入口：5. Debugging Android Apps

记录测试、Logcat、断点与问题工件的责任人的初始失败输入、线程、异常、调用栈和修复假设

观察：失败测试、完整堆栈、断点快照、修复差异和回归结果中的“5. Debugging Android Apps”轨迹

预期：由测试、Logcat、断点与问题工件的责任人提交失败输入、线程、异常、调用栈和修复假设，并持续满足“同一失败输入在修复前稳定失败、修复后稳定通过且邻近用例不回归”

实验二：事件与生命周期轨迹

沿五次转换逐步执行“重放最小失败用例并一次只改变一个原因”。每一步只允许测试、Logcat、断点与问题工件的责任人按职责提交状态，并持续核对“同一失败输入在修复前稳定失败、修复后稳定通过且邻近用例不回归”。

Deterministic event replay

Android应用的调试：事件轨迹

重置实验

选择一次状态转换1 / 5

1. 冻结入口：5. Debugging Android Apps记录测试、Logcat、断点与问题工件的责任人的初始失败输入、线程、异常、调用栈和修复假设失败测试、完整堆栈、断点快照、修复差异和回归结果中的“5. Debugging Android Apps”轨迹2. 触发事件：Exceptions and Stack Traces以“重放最小失败用例并一次只改变一个原因”改变失败输入、线程、异常、调用栈和修复假设失败测试、完整堆栈、断点快照、修复差异和回归结果中的“Exceptions and Stack Traces”轨迹3. 提交状态：Android-Specific Debugging只由测试、Logcat、断点与问题工件的责任人提交新状态失败测试、完整堆栈、断点快照、修复差异和回归结果中的“Android-Specific Debugging”轨迹4. 重建边界：Challenge: Exploring the Layout Inspector在销毁、取消或重建后拒绝旧所有者回调失败测试、完整堆栈、断点快照、修复差异和回归结果中的“Challenge: Exploring the Layout Inspector”轨迹5. 核对交付：Challenge: Exploring the Profiler以“同一失败输入在修复前稳定失败、修复后稳定通过且邻近用例不回归”判断通过失败测试、完整堆栈、断点快照、修复差异和回归结果

不变量：同一失败输入在修复前稳定失败、修复后稳定通过且邻近用例不回归

交付证据：失败测试、完整堆栈、断点快照、修复差异和回归结果

实验三：章专属反例与同输入恢复

注入“捕获异常或删除日志让界面不崩，却没有修复无效状态”，保存第一个偏离点；撤销后以完全相同的 SDK、设备状态和用户事件重放。只有失败测试、完整堆栈、断点快照、修复差异和回归结果一起恢复才算修复。

Fault · cancel · restore

Android应用的调试：反例与恢复

重置实验

注入章专属故障同输入重放

故障：捕获异常或删除日志让界面不崩，却没有修复无效状态

1. 冻结输入一致

第 1 次使用相同 SDK、设备配置、初始状态与用户事件

2. 注入边界一致

保持正常输入不变，仅注入“捕获异常或删除日志让界面不崩，却没有修复无效状态”

3. 检查所有者一致

同一失败输入在修复前稳定失败、修复后稳定通过且邻近用例不回归

4. 核对结果一致

失败测试、完整堆栈、断点快照、修复差异和回归结果