模块化热修复是将热修复能力与模块化工程深度结合的实践策略，聚焦于可独立编译、动态加载的业务模块，通过dex补丁、插件化或脚本化等方式实现精准、安全的运行时逻辑替换。
模块化热修复（Module Hotfix）不是独立技术，而是将热修复能力与模块化/组件化工程结构深度结合的一种实践策略。它不追求“整个App热修”，而是聚焦于可独立编译、动态加载的业务模块，在运行时精准替换有缺陷的模块逻辑，从而实现更安全、可控、低风险的线上修复。
明确模块边界与可热修前提
只有满足以下条件的模块才适合接入热修复：
- 模块以 Android Library 形式存在，不直接依赖 Application 或全局单例强耦合对象
- 模块对外暴露清晰接口（如 Service API、Router 协议、或 Interface 实现类），调用方通过抽象而非具体类引用
- 模块内部无反射调用主工程私有类、未加固的资源 ID 硬编码、或无法被 ClassLoader 隔离的静态状态
- 模块已启用 独立签名+版本号管理，便于补丁校验与灰度控制
选择适配模块粒度的热修复方案
不同模块规模对应不同技术路径：
- 小功能模块（如登录页、弹窗工具类）：采用 Tinker 或 Sophix 的标准 dex 补丁方式，将修复后的 .dex 打包进 patch.zip，由框架在启动后替换 ClassLoader 中的对应类
- 中型业务模块（如订单中心、消息中心）：使用基于插件化思想的模块热更新，例如 Atlas 或 RePlugin 的“模块化插件”机制，将整个 module 编译为 .apk 插件，运行时卸载旧模块、加载新模块并重连接口
- 纯逻辑模块（如算法引擎、风控规则库）：推荐 DSL 化或脚本化改造，把易变逻辑抽离为 JSON/YAML 规则或 Lua/JS 脚本，热修复即下发新规则包或脚本文件，无需触及 Java/Kotlin 字节码
构建可验证的模块补丁发布流程
模块热修复成败关键不在“能不能换”，而在“换得对不对”。需建立闭环验证链：
- 补丁生成阶段：基于 Git diff 自动识别变更类，强制要求提交时标注影响范围（如 “影响 OrderSubmitActivity + submitOrder() 方法”）
- 本地验证阶段：提供一键式“模块热替模拟器”，在 debug 包中加载补丁 dex 并运行单元测试，确认接口行为一致
- 灰度发布阶段：按模块维度配置灰度比例（如仅对 5% 的“我的订单”模块用户下发），并埋点监控模块初始化成功率、关键方法耗时、异常率
- 回滚机制：保留上一版模块的 dex 或插件包，当监控指标突增时，自动触发降级加载旧版本，10 秒内恢复
规避常见陷阱
模块化热修复容易因工程结构松动而失效：
- 避免在模块中直接 new 主工程 Activity 或 Fragment；应统一走 ARouter 或类似路由跳转
- 禁止模块内使用 BuildConfig.DEBUG 判断环境——补丁包无该字段，会导致编译期常量误判
- 资源热修需额外处理：若模块含 layout/drawable，须同步下发 resources.arsc 差分包，并确保 aapt2 编译时开启
--no-version-vectors保证 ID 稳定 - 混淆必须开启 mapping 上传归档，否则补丁中类名无法对齐线上崩溃堆栈
