告别第三方插件：官方Fused Library如何重塑Android库的合并与发布流程

1. 为什么我们需要告别fat-aar在Android SDK开发中模块化设计是提高代码复用性和维护性的关键。但当我们想把多个模块打包成一个AAR文件发布时长期以来都依赖第三方插件如fat-aar。这就像组装电脑时我们不得不使用各种转接头才能让不同厂商的配件协同工作。fat-aar确实解决了燃眉之急但随着Android Gradle Plugin(AGP)的版本迭代问题开始显现。我去年在项目中使用fat-aar时就踩过坑当AGP升级到8.0后构建突然失败不得不花两天时间寻找兼容方案。更糟的是不同团队fork的版本行为不一致导致CI环境构建结果与本地不一致。核心痛点有三版本兼容性每次AGP大版本更新都可能破坏现有构建流程依赖传递问题需要手动处理子模块的依赖关系容易遗漏维护风险依赖社区维护的插件存在项目弃保风险2. Fused Library带来的变革Android官方在AGP 8.12中推出的Fused Library就像Google终于提供了原装数据线。它从根本上改变了多模块合并的游戏规则我在实际迁移过程中发现了几个关键优势2.1 原生支持的可靠性使用官方方案后最直接的感受是构建稳定性大幅提升。不再需要担心AGP升级导致构建失败因为插件本身就是Android工具链的一部分。我在AGP 8.10上测试时发现虽然文档说需要8.12但基础功能已经可以工作。配置方式极其简单plugins { id com.android.fused-library }2.2 依赖管理的智能化传统方案需要手动处理依赖传递// fat-aar需要额外配置 dependencies { embed project(:module1) embed com.example:lib:1.0 }而Fused Library使用更符合直觉的include语法dependencies { include(project(:module1)) include(com.example:lib:1.0) }更重要的是它会自动生成正确的POM文件解决了依赖传递问题。这意味着下游使用者能正确获取所有传递依赖避免了运行时类找不到的经典问题。3. 迁移实操指南3.1 环境准备首先确保你的环境满足AGP 8.10推荐8.12Gradle 8.0Android Studio Flamingo或更高在项目的settings.gradle中添加插件仓库pluginManagement { repositories { google() gradlePluginPortal() } }3.2 基础配置在被合并的模块build.gradle中plugins { id com.android.library id com.android.fused-library } android { namespace com.example.mylibrary compileSdk 34 } dependencies { include(project(:submodule1)) include(project(:submodule2)) include(com.google.code.gson:gson:2.10.1) }3.3 解决常见问题Kotlin模块冲突是迁移时最容易遇到的问题。当两个模块都包含base模块时会出现2 files found with path META-INF/base_release.kotlin_module解决方案是在每个模块的build.gradle中配置唯一模块名kotlinOptions { freeCompilerArgs [-module-name, com.your.package.${project.name}] }4. 当前局限性与应对策略虽然Fused Library是官方方案但作为新功能仍有不足4.1 已知限制变体支持有限不能合并不同buildType的模块变通方案为每个变体创建单独的融合任务部分依赖类型不支持// 这些目前会报错 include(files(libs/local.jar)) include(com.unknown:lib:1.0) // 无法解析的依赖混淆问题需要在主模块统一配置ProGuard规则4.2 调试技巧当遇到合并失败时可以启用调试模式tasks.withType(com.android.build.gradle.tasks.FusedLibraryMergeArtifactTask) { debugEnabled true }这会输出详细的合并日志帮助定位问题。我在处理资源冲突时就靠这个找到了重复的资源文件。5. 工程实践建议经过三个项目的实际迁移总结出以下最佳实践渐进式迁移先在新模块试用逐步替换现有fat-aar配置使用变体感知配置确保兼容CI/CD适配# 在CI脚本中添加版本检查 ./gradlew --version | grep AGP | grep 8.1依赖管理优化将常用依赖提取到版本目录使用约束条件确保一致性文档更新在README中明确标注融合模块关系提供最小化配置示例迁移过程中最大的收获是理解了官方方案的设计哲学不是简单地把所有代码打包在一起而是建立正确的模块边界和依赖关系。这促使我们重新思考SDK的架构设计最终得到了更清晰的模块划分。对于还在使用fat-aar的团队我的建议是现在就开始规划迁移。虽然需要一些适应成本但长远来看拥抱官方方案能减少大量维护负担。就像Android Studio取代Eclipse一样早期切换虽然痛苦但最终会获得更顺畅的开发体验。