第2章 组件化编程

依据电子工业出版社完整目录覆盖46个节点:贯通本地广播、事件总线、ARouter、反射、存储、权限、资源、混淆与多渠道的组件协作合同

第2章 组件化编程

本页依据苍王《Android组件化架构》独立重构,不复制原文。版本锁定电子工业出版社2018年3月第1版、316页、ISBN 9787121336775。原书处在Gradle 4.1、Instant Run、Freeline、JCenter、旧Support Library与传统Manifest合并规则的历史环境。

在《第2章 组件化编程》中,课程先准确解释出版时的依赖、构建、分发和发布机制,再单列现代Android Gradle Plugin、Version Catalog、Build Cache、Jetpack Startup、Activity Result API与Maven Central迁移。已停用或改变的工具不能被删除,也不能冒充当前推荐。

学习目标

  • 能解释“第2章 组件化编程”全部46个正式节点的依赖方向、构建输入、运行所有者、制品与2018年版本边界。
  • 能实现“贯通本地广播、事件总线、ARouter、反射、存储、权限、资源、混淆与多渠道的组件协作合同”的最小垂直切片,并保存配置、任务图、产物、日志和断言。
  • 能比较正常、合并冲突、路由缺失、增量失效、生命周期错位与发布回滚,分析“用全局事件总线和字符串路由掩盖依赖,把权限、数据库、R类和混淆规则留给最终集成时碰撞”。
  • 能设计反例并凭消息时序、路由表、反射创建记录、存储归属、权限矩阵、资源冲突与渠道产物完成独立复现与交接。

机制总览

第2章 组件化编程:机制路径

  1. 1

    从组件边界与证据开始

    运行阶段还要明确 生命周期所有者 。Activity、Fragment、View、Application和后台线程的阶段不同,分发迟到或重复会造成泄漏与副作用。发布阶段用 制品坐标 把源码提交连接到AAR与消费者,任何可变版本都会破坏回滚。

  2. 2

    最小垂直切片

    先预测依赖图和初始化顺序,再运行一个只有壳、合同和业务实现的最小工程。合同放在下层,业务实现不能反向依赖壳工程;注册必须幂等且能释放。

  3. 3

    层架构与故障证明

    源码边界。 画出壳、业务、公共与基础层,列出允许和禁止依赖。公共合同不得泄漏业务实现,资源前缀、包名、ProGuard规则与Manifest占位符都属于边界。用依赖图和违规样例让构建自动失败。

先按顺序建立机制,再进入实验切换阶段并检查失效证据。

章级决策实验

第2章 组件化编程:机制与证据

切换《第2章 组件化编程》的三个关键教学阶段,先解释机制,再用运行与失败证据验证结论。

选择推理阶段

当前阶段 · 从组件边界与证据开始

运行阶段还要明确 生命周期所有者 。Activity、Fragment、View、Application和后台线程的阶段不同,分发迟到或重复会造成泄漏与副作用。发布阶段用 制品坐标 把源码提交连接到AAR与消费者,任何可变版本都会破坏回滚。

可核验证据

以最小多模块工程验证「从组件边界与证据开始」,保存依赖图、任务/合并报告、运行时序、产物校验和,并注入一个冲突或仓库失败样本。

学完《第2章 组件化编程》后,应能从输入和前置条件推导状态变化,并用可重复的构建、运行或边界测试证明结果。

失效—证据矩阵

第2章 组件化编程:失效与核验

从组件边界与证据开始

典型失效

若把「从组件边界与证据开始」简化成拆分 Gradle module,却不约束依赖、构建输入、运行所有者与制品版本,集成成功也会在冲突、重建或回滚时失效。

核验证据

以最小多模块工程验证「从组件边界与证据开始」,保存依赖图、任务/合并报告、运行时序、产物校验和,并注入一个冲突或仓库失败样本。

最小垂直切片

典型失效

若把「最小垂直切片」简化成拆分 Gradle module,却不约束依赖、构建输入、运行所有者与制品版本,集成成功也会在冲突、重建或回滚时失效。

核验证据

以最小多模块工程验证「最小垂直切片」,保存依赖图、任务/合并报告、运行时序、产物校验和,并注入一个冲突或仓库失败样本。

层架构与故障证明

典型失效

若把「层架构与故障证明」简化成拆分 Gradle module,却不约束依赖、构建输入、运行所有者与制品版本,集成成功也会在冲突、重建或回滚时失效。

核验证据

以最小多模块工程验证「层架构与故障证明」,保存依赖图、任务/合并报告、运行时序、产物校验和,并注入一个冲突或仓库失败样本。

每个判断都必须能落到观测、测试或产物,不能只凭代码表面推测。

从组件边界与证据开始

不等于目录或Gradle module。在《第2章 组件化编程》中,边界必须说明谁可以依赖谁、哪些类型公开、资源怎样命名、Manifest怎样合并、初始化由谁调度、制品由谁发布;编译器、构建系统和测试应能拒绝违规关系。

决定一次修改能否增量,以及缓存何时安全命中。需要用项目依赖图与自动测试证明,而不是靠团队口头约定。

运行阶段还要明确。Activity、Fragment、View、Application和后台线程的阶段不同,分发迟到或重复会造成泄漏与副作用。发布阶段用把源码提交连接到AAR与消费者,任何可变版本都会破坏回滚。

本单元主线是贯通本地广播、事件总线、ARouter、反射、存储、权限、资源、混淆与多渠道的组件协作合同。在《第2章 组件化编程》中,交互图把目录节点放入源码、构建、运行、制品和团队五层;故障实验一次只改变一个合并、路由、缓存或发布条件;证据门拒绝只展示“能够运行”的弱结论。

最小垂直切片

先预测依赖图和初始化顺序,再运行一个只有壳、合同和业务实现的最小工程。合同放在下层,业务实现不能反向依赖壳工程;注册必须幂等且能释放。

interface FeatureContract {
    val id: String
    fun start(registry: MutableMap<String, String>)
    fun stop(registry: MutableMap<String, String>)
}
 
class OrderFeature : FeatureContract {
    override val id = "order"
    override fun start(registry: MutableMap<String, String>) { check(registry.put(id, "ready") == null) }
    override fun stop(registry: MutableMap<String, String>) { check(registry.remove(id) != null) }
}

固定环境,保存依赖、Manifest、任务、产物与运行证据。命令名称可按现代工具链调整,但报告必须标明与2018年原书的差异。

./gradlew --no-daemon projects dependencies
./gradlew --no-daemon :app:processDebugMainManifest --info
./gradlew --no-daemon clean :app:assembleDebug --scan
unzip -l app/build/outputs/apk/debug/app-debug.apk > apk-contents.txt
adb logcat -d -v threadtime > component-run.log

把架构结论写成可以失败的行为合同:

Given pinned source, Gradle, plugin, JDK, repository, manifest, resource, and device inputs
When the smallest scenario for "aca18-02-component-programming" crosses build, runtime, or artifact boundaries
Then dependency direction, merged output, initialization order, observable behavior, and release match the prediction
And duplicate resources, missing routes, stale caches, destroyed owners, and unavailable artifacts fail explicitly
And modern replacements are recorded as migration evidence rather than original 2018 behavior

这三段材料分别证明源码合同、构建重放和用户可见行为。若日志没有提交、任务、变体、产物校验和、组件标识和阶段,便无法区分真正的组件机制与本机缓存或偶然初始化顺序。

五层架构与故障证明

源码边界。 画出壳、业务、公共与基础层,列出允许和禁止依赖。公共合同不得泄漏业务实现,资源前缀、包名、ProGuard规则与Manifest占位符都属于边界。用依赖图和违规样例让构建自动失败。

构建边界。 从源码集、资源、注解处理、Manifest合并到DEX、APK或AAR逐项记录输入输出。冷构建、无变更热构建、代码变化、资源变化和插件变化分别测量;Instant Run与Freeline只能在其历史失效条件内评价。

运行边界。 给Application、Activity、Fragment、View、线程任务和路由服务指定所有者。记录注册与释放时序,注入进程重建、配置变化、重复初始化、缺失实现和迟到回调;事件总线或反射成功调用并不自动证明生命周期正确。

制品边界。 AAR发布必须有不可变坐标、依赖元数据、校验和、仓库权限和回滚版本。测试本地缓存损坏、远程不可达、重复类、资源覆盖与消费者版本冲突。JCenter已经成为历史边界,现代迁移应指向受维护仓库。

团队边界。 每个组件明确源码、接口、构建、发布和故障所有者。模板只能加速一致入口,不能替代评审。架构升级以问题和度量驱动,一次只改变一个边界,并保留回退到上一个可发布版本的路径。

围绕“用全局事件总线和字符串路由掩盖依赖,把权限、数据库、R类和混淆规则留给最终集成时碰撞”预写推翻条件:依赖环、合并冲突、路由错配、重复初始化、错误线程、增量产物陈旧、AAR不可追溯或无法回滚中的任一项出现,都意味着当前方案不成立。最终交付消息时序、路由表、反射创建记录、存储归属、权限矩阵、资源冲突与渠道产物,让另一位开发者无需口头提示即可重放。

跨边界验收

在《第2章 组件化编程》中,从一个业务组件的源码修改开始,跟踪它经过依赖解析、资源与Manifest合并、编译打包、壳工程初始化、页面或服务分发,直到发布AAR与消费者升级。每一层都保存成功、失败和回滚证据;任何一步需要手工改壳或猜测版本,都说明自动化合同仍有缺口。

小结

  • 46个节点覆盖广播、路由、反射、存储与多渠道协作
  • 最小切片贯通协作合同,保存消息时序与路由表
  • 故障实验对比依赖掩盖、权限碰撞与资源冲突
  • 凭路由表、反射记录与渠道产物完成交接

练习

问题 1:“第2章 组件化编程”覆盖哪些正式节点与工程主线?

问题 2:怎样建立本章最小垂直切片?

问题 3:本章最需要推翻的错误假设是什么?

问题 4:为什么一次集成成功不能证明组件化架构?

问题 5:怎样迁移历史工具而不改写原书?

问题 6:达到独立交接需要什么?

名词解释

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

组件边界

拥有清晰源码、资源、构建、运行和发布责任,并通过显式合同协作的工程单元。

构建任务图

从源码和资源输入经Gradle任务、变换、打包直到APK或AAR产物的有向过程。

依赖方向

基础、公共、业务和壳层之间只允许按约定方向连接的规则。

生命周期所有者

负责创建、注册、启动、停止并释放组件能力的唯一主体。

制品坐标

由坐标、版本、校验和、依赖元数据和仓库共同标识的可复现二进制。

← 上一页:第1章 组件化基础 · 下一页:第3章 组件化优化 →

原版目录概念补充核对

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

2.1 本地广播:机制、边界与证据

第2章 组件化编程中的2.1 本地广播跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.1.1 本地广播基础介绍:机制、边界与证据

第2章 组件化编程中的2.1.1 本地广播基础介绍跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.1.2 使用方法:机制、边界与证据

第2章 组件化编程中的2.1.2 使用方法要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.1.3 本地广播源码分析:机制、边界与证据

第2章 组件化编程中的2.1.3 本地广播源码分析跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.2 组件间通信机制:机制、边界与证据

第2章 组件化编程中的2.2 组件间通信机制要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.2.1 组件化层级障碍:机制、边界与证据

第2章 组件化编程中的2.2.1 组件化层级障碍要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.2.2 事件总线:机制、边界与证据

第2章 组件化编程中的2.2.2 事件总线跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.2.3 组件化事件总线的考量:机制、边界与证据

第2章 组件化编程中的2.2.3 组件化事件总线的考量要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.3 组件间跳转:机制、边界与证据

第2章 组件化编程中的2.3 组件间跳转要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.3.1 隐式跳转:机制、边界与证据

第2章 组件化编程中的2.3.1 隐式跳转要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.3.2 ARouter路由跳转:机制、边界与证据

第2章 组件化编程中的2.3.2 ARouter路由跳转跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.3.3 Android路由原理:机制、边界与证据

第2章 组件化编程中的2.3.3 Android路由原理跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.3.4 组件化最佳路由:机制、边界与证据

第2章 组件化编程中的2.3.4 组件化最佳路由要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.3.5 空类索引:机制、边界与证据

第2章 组件化编程中的2.3.5 空类索引要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.4 动态创建:机制、边界与证据

第2章 组件化编程中的2.4 动态创建要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.4.1 反射基础:机制、边界与证据

第2章 组件化编程中的2.4.1 反射基础跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.4.2 反射进阶:机制、边界与证据

第2章 组件化编程中的2.4.2 反射进阶跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.4.3 反射简化jOOR:机制、边界与证据

第2章 组件化编程中的2.4.3 反射简化jOOR跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.4.4 动态创建Fragment:机制、边界与证据

第2章 组件化编程中的2.4.4 动态创建Fragment跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.4.5 动态配置Application:机制、边界与证据

第2章 组件化编程中的2.4.5 动态配置Application跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.5 数据存储:机制、边界与证据

第2章 组件化编程中的2.5 数据存储要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.5.1 数据的存储方式:机制、边界与证据

第2章 组件化编程中的2.5.1 数据的存储方式要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.5.2 组件化存储:机制、边界与证据

第2章 组件化编程中的2.5.2 组件化存储要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.5.3 组件化数据库:机制、边界与证据

第2章 组件化编程中的2.5.3 组件化数据库要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.6 权限管理:机制、边界与证据

第2章 组件化编程中的2.6 权限管理跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.6.1 权限机制:机制、边界与证据

第2章 组件化编程中的2.6.1 权限机制跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.6.2 组件化权限:机制、边界与证据

第2章 组件化编程中的2.6.2 组件化权限要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.6.3 动态权限框架:机制、边界与证据

第2章 组件化编程中的2.6.3 动态权限框架跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.6.4 路由拦截:机制、边界与证据

第2章 组件化编程中的2.6.4 路由拦截跨越运行时注册、查找与生命周期所有权,成功调用一次不能证明进程重建或迟到回调仍正确。记录组件标识、进程线程、注册/释放次序与路由结果,并注入缺失实现、重复初始化或 owner 销毁验证显式失败。

2.7 静态常量:机制、边界与证据

第2章 组件化编程中的2.7 静态常量要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.7.1 资源限制:机制、边界与证据

第2章 组件化编程中的2.7.1 资源限制属于从源码与资源输入到 APK/AAR 产物的构建变换,结论受 2018 年 Gradle/AGP 版本约束。保存任务图、合并/生成报告与产物校验和,分别改变代码、资源或插件配置,核对增量命中、冲突诊断和冷构建结果。

2.7.2 组件化的静态变量:机制、边界与证据

第2章 组件化编程中的2.7.2 组件化的静态变量要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.7.3 R2.java的秘密:机制、边界与证据

第2章 组件化编程中的2.7.3 R2.java的秘密要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.8 资源冲突:机制、边界与证据

第2章 组件化编程中的2.8 资源冲突属于从源码与资源输入到 APK/AAR 产物的构建变换,结论受 2018 年 Gradle/AGP 版本约束。保存任务图、合并/生成报告与产物校验和,分别改变代码、资源或插件配置,核对增量命中、冲突诊断和冷构建结果。

2.8.1 组件化的资源汇合:机制、边界与证据

第2章 组件化编程中的2.8.1 组件化的资源汇合要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.8.2 组件化资源冲突:机制、边界与证据

第2章 组件化编程中的2.8.2 组件化资源冲突要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.9 组件化混淆:机制、边界与证据

第2章 组件化编程中的2.9 组件化混淆要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.9.1 混淆基础:机制、边界与证据

第2章 组件化编程中的2.9.1 混淆基础属于从源码与资源输入到 APK/AAR 产物的构建变换,结论受 2018 年 Gradle/AGP 版本约束。保存任务图、合并/生成报告与产物校验和,分别改变代码、资源或插件配置,核对增量命中、冲突诊断和冷构建结果。

2.9.2 资源混淆:机制、边界与证据

第2章 组件化编程中的2.9.2 资源混淆属于从源码与资源输入到 APK/AAR 产物的构建变换,结论受 2018 年 Gradle/AGP 版本约束。保存任务图、合并/生成报告与产物校验和,分别改变代码、资源或插件配置,核对增量命中、冲突诊断和冷构建结果。

2.9.3 组件化混淆:机制、边界与证据

第2章 组件化编程中的2.9.3 组件化混淆要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.10 多渠道模块:机制、边界与证据

第2章 组件化编程中的2.10 多渠道模块要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

2.10.1 多渠道基础:机制、边界与证据

第2章 组件化编程中的2.10.1 多渠道基础属于从源码与资源输入到 APK/AAR 产物的构建变换,结论受 2018 年 Gradle/AGP 版本约束。保存任务图、合并/生成报告与产物校验和,分别改变代码、资源或插件配置,核对增量命中、冲突诊断和冷构建结果。

2.10.2 批量打包:机制、边界与证据

第2章 组件化编程中的2.10.2 批量打包要贯通源码合同、构建任务、运行所有者与发布制品四层。固定工具链和最小工程,只改变一个依赖、合并、路由或仓库条件,用自动拒绝、运行日志、产物校验和与回滚结果证明边界。

2.10.3 多渠道模块配置:机制、边界与证据

第2章 组件化编程中的2.10.3 多渠道模块配置要用允许与禁止的依赖边表达组件边界,而不是以 Gradle module 数量代替解耦。固定工程后导出依赖图和公开 API,加入一个反向依赖或重复类反例,确认构建能拒绝越界且业务实现仍可替换。

资料与写作方式声明

本章以苍王《Android组件化架构》权威目录界定学习范围,并结合正文列出的技术资料独立重写;不宣称复现原书正文,也不沿用原作表述。

原作版权归作者与出版社所有;本站原创教学结构与表述仅供学习交流。

讨论

评论区加载中…