第13章 综合技术

在《第13章 综合技术》中，本页依据任玉刚《Android开发艺术探索》完整目录独立重构，不复制原文。版本锁定电子工业出版社2015年9月第1版、507页、ISBN 9787121269394，原书机制以Android 5.0与Java应用层/源码分析为基线。

原书中的AsyncTask、IntentService、旧权限/后台/存储规则和部分framework实现具有历史边界。在《第13章 综合技术》中，课程先准确解释出版时机制，再单独建立现代targetSdk迁移账本；不会用Compose、协程或当前Jetpack替换原书目录后仍声称一比一覆盖。

从framework因果链开始

Android API只是入口。在《第13章 综合技术》中，每个实验先找生命周期所有者，再画“应用调用 → framework代理 → Binder或消息队列 → 系统/目标对象 → 回调”的链路。调用因果链帮助区分源码事实和表面现象。

在《第13章 综合技术》中，主线程、Binder线程池、HandlerThread、线程池和原生线程有不同责任。线程合同必须写在代码旁。状态也要分为界面暂态、可恢复实例状态、进程内缓存、文件/数据库事实和系统服务状态；进程单例从来不是持久事实源。

本章主线是建立CrashHandler、multidex、动态加载与反编译/重打包实验，理解诊断、构建和代码边界。所有节点都要生成证据链，并声明版本边界。正常截图不证明线程、重建、失败和释放正确。

最小可执行切片

在《第13章 综合技术》中，下面的Java片段只抓住本章核心合同。先预测线程、状态和失败，再在匹配Android 5.0语境的样例工程中运行；代码所依赖的上下文和导入应在工程中显式声明。

public void uncaughtException(Thread thread, Throwable error) {
  CrashEnvelope envelope = CrashEnvelope.from(error);
  envelope.removeSecrets();
  crashStore.writeAtomically(envelope);
  previous.uncaughtException(thread, error);
}
 
// A crash handler records evidence; it must not pretend the process is healthy.

固定环境并保留构建、安装、组件与线程证据：

./gradlew --no-daemon clean test assembleDebug
adb install -r app/build/outputs/apk/debug/app-debug.apk
adb shell am force-stop org.example.art
adb shell monkey -p org.example.art 1
adb shell dumpsys activity processes > processes.txt
adb logcat -d -v threadtime > run.log

将机制写成能失败的行为合同：

Given a pinned JDK, Android plugin, device API, process state, permission state, and input
When the smallest scenario for "adae15-13-integrated-techniques" crosses its owner, thread, or process boundary
Then callbacks, durable state, side effects, timing, and resource release match the prediction
And process death, owner destruction, malformed input, queue pressure, and repeated work stay observable
And modern targetSdk differences are recorded as migration evidence, not original behavior

在《第13章 综合技术》中，三段材料分别约束源码机制、环境重放和用户可见结果。若日志没有线程名、进程号、输入标识和阶段，或测试只断言“没有崩溃”，就无法证明真正经过目标调用链。

四层源码与故障证明

在《第13章 综合技术》中，调用层。 从“第13章 综合技术”选择一次入口，写出应用对象、framework代理、系统服务或目标组件以及返回路径。对源码分析，记录Android版本、类名、方法与关键分支；对应用实验，记录用户动作、Intent或消息标识。先解释谁创建工作、谁持有引用、谁负责结束，再谈API细节。

在《第13章 综合技术》中，线程与进程层。 在每个箭头上标线程和进程。主线程不能执行无界I/O或计算；Binder回调不自动处于主线程；Service也不自动提供后台线程。用线程名、进程号、队列长度和时间戳验证，分别注入进程退出、Binder死亡、队列饱和和组件销毁，检查迟到结果是否被丢弃。

在《第13章 综合技术》中，状态与资源层。 列出可恢复事实、缓存和外部资源。旋转、后台回收、进程重建、列表复用与配置变化后，界面应由事实重建，而不是依赖旧对象。文件、Cursor、Bitmap、动画、Window、线程池和JNI引用都要有关闭或取消点；保存前后资源计数，避免只靠肉眼判断泄漏。

迁移层。 原书锁定Android 5.0。在《第13章 综合技术》中，现代迁移一次只改变targetSdk、组件导出、后台限制、存储、权限、通知、构建插件或替代API之一，比较构建、调用链、用户行为、测试与回滚。新实现可以使用Jetpack或结构化并发，但必须保留原书机制说明，不能抹去历史API为何工作及为何后来受限。

围绕“收集崩溃时泄露敏感数据，或把动态加载与二次打包当作无信任边界的普通功能”预写一个推翻条件：状态丢失、错误线程、越权、ANR、泄漏、结果错位、重复副作用或原生崩溃中的任一项出现，都意味着当前实现不成立。最终交付崩溃包、方法数报告、类加载图、签名差异、反编译结果和安全边界，让他人无需口头提示即可复现。

本章回顾

本页从“第13章 综合技术”覆盖到“13.4.2 使用apktool对apk进行二次打包”，共7个正式节点。掌握标准是能沿“建立CrashHandler、multidex、动态加载与反编译/重打包实验，理解诊断、构建和代码边界”解释调用因果链，运行正常、重建与故障实验，并让另一位开发者凭崩溃包、方法数报告、类加载图、签名差异、反编译结果和安全边界重放结论。

← 上一页：第12章 Bitmap的加载和Cache · 下一页：第14章 JNI和NDK编程 →

原版目录概念补充核对

以下条目补齐官方目录中容易被示例主线掩盖的概念。它们不重复罗列目录，而是明确每项概念的机制、适用边界和验收证据。

13.1 使用CrashHandler来获取应用的crash信息：机制、边界与证据

第13章 综合技术中的13.1 使用CrashHandler来获取应用的crash信息需要区分请求入口、system_server/消息队列状态、目标线程与完成回调。用 PID/TID、token/record、队列时序和最终组件状态交叉验证，并注入进程未启动或迟到消息。

13.2 使用multidex来解决方法数越界：机制、边界与证据

第13章 综合技术中的13.2 使用multidex来解决方法数越界必须放回 Android 5.0/Java 基线的应用调用—framework 代理—Binder/消息队列—目标对象—回调链路。固定版本，先预测状态变化，再以源码符号、运行轨迹和一个失败样本复核。

13.3 Android的动态加载技术：机制、边界与证据

第13章 综合技术中的13.3 Android的动态加载技术必须放回 Android 5.0/Java 基线的应用调用—framework 代理—Binder/消息队列—目标对象—回调链路。固定版本，先预测状态变化，再以源码符号、运行轨迹和一个失败样本复核。

13.4 反编译初步：机制、边界与证据

第13章 综合技术中的13.4 反编译初步必须放回 Android 5.0/Java 基线的应用调用—framework 代理—Binder/消息队列—目标对象—回调链路。固定版本，先预测状态变化，再以源码符号、运行轨迹和一个失败样本复核。

13.4.1 使用dex2jar和jd-gui反编译apk：机制、边界与证据

第13章 综合技术中的13.4.1 使用dex2jar和jd-gui反编译apk必须放回 Android 5.0/Java 基线的应用调用—framework 代理—Binder/消息队列—目标对象—回调链路。固定版本，先预测状态变化，再以源码符号、运行轨迹和一个失败样本复核。