android-modularization

Android 模块化

适用场景

• 当请求涉及以下内容时使用此技能：Android 模块拆分、Android 功能模块化、打破模块间的循环依赖。
• 主要目标：设计包含功能、核心和构建逻辑模块的 Android 仓库，使其能够扩展且不存在循环依赖。
• 当问题涉及依赖方向、API 归属或功能／数据／核心边界时使用此技能；不要将其用于任务级别的构建速度调优。
• 当范围扩展时，转交给以下技能：
• android-gradle-build-logic
• android-architecture-clean

工作流

1. 首先梳理当前模块图：app、功能、数据、核心、构建逻辑，以及任何动态功能模块或仅用于测试的模块。
2. 找出方向错误之处：功能模块间耦合、框架泄漏到领域／数据层、API 表面过宽，或共享代码重复且归属不明确。
3. 按归属和变更频率拆分，而非拘泥于抽象理论；创建能够消除当前耦合问题的最小模块边界。
4. 明确 api 与 implementation 的使用、公有 API 范围和测试 fixture 的归属，确保新边界保持稳定。
5. 只有在模块图本身清晰合理后，才将构建速度或插件架构问题转交出去。

防护原则

• 如果自定义的本地约定与官方 Android 和 Kotlin 指南冲突，优先遵循官方指南。
• 保持公有 API 简洁明确；避免使用掩盖 Android 生命周期开销的巧妙抽象。
• 除非请求明确需要，否则不要将架构清理与产品行为变更混在一起。
• 记录会影响旧模块或生成代码的兼容性限制。
• 如果真正需要的只是一个更清晰的归属边界，就不要对小型代码库过度模块化。

反模式

• 在各个模块中零散添加辅助代码，却没有明确的归属边界。
• 在纯领域层或数据层中引入特定框架的代码。
• 只需修改一个契约，却重构所有相邻文件。
• 暗示迁移说明而不明确写出。
• 将模块数量当作目标，而不是关注构建隔离和依赖清晰度。

示例

理想路径

• 场景：将 fixture 应用作为 app 模块进行审查，并梳理下一步拆分到功能／核心层的方案。
• 命令：cd examples/orbittasks-compose && ./gradlew :app:projects

边缘情况

• 场景：避免共享 XML 资源和 manifest 占位符泄漏到其他模块。
• 命令：cd examples/orbittasks-xml && ./gradlew :app:dependencies

故障恢复

• 场景：区分模块化请求与 architecture-clean 和 build-logic 相关提示词。
• 命令：python3 scripts/eval_triggers.py --skill android-modularization

完成检查清单

• 实施路径明确、精简，并针对正确的 Android 层面。
• 已运行或更新相关示例命令和基准测试提示词。
• 当请求跨越边界时，已记录向相邻技能的交接。
• 官方参考资料涵盖所选模式以及主要迁移或故障排查路径。

官方参考资料

• https://developer.android.com/topic/modularization
• https://docs.gradle.org/current/userguide/multi_project_builds.html
• https://developer.android.com/build/extend-agp
• https://developer.android.com/build/migrate-to-kotlin-dsl