Android 高效合并第三方AAR的Gradle插件实践指南

1. 为什么我们需要合并第三方AAR？

做Android SDK开发的朋友，估计都遇到过这个让人头疼的场景：你精心封装了一个功能模块，准备打成AAR文件交付给业务方使用。模块本身运行得好好的，但里面用到了几个第三方库，比如网络请求的OkHttp、图片加载的Glide。当你兴冲冲地把AAR交给同事，他集成后一运行，App直接崩溃，日志里赫然写着 ClassNotFoundException。

这感觉就像你送人一个包装精美的礼盒，对方打开一看，发现里面最重要的几件礼物居然只是“提货券”，还得他自己去别处领取。对于业务方来说，他不仅要引入你的AAR，还得把你AAR里用到的所有第三方库，一个一个手动添加到他的build.gradle里。依赖关系一旦复杂，比如你的AAR里又嵌套了别的AAR，这个清单就会变得又长又容易出错，对接成本直线上升。

我自己就踩过这个坑。早期图省事，直接把带第三方依赖的模块打包，结果在Gradle 4.2上就报错了，错误信息非常直白：

Direct local .aar file dependencies are not supported when building an AAR.

意思是，官方的Gradle插件在构建AAR时，根本不会把你模块里依赖的本地AAR文件打包进去。即便旧版本没报错，生成的也是个“残缺”的AAR，运行时必然找不到类。

所以，“合并AAR”的需求本质是简化交付。我们希望交付物是一个“胖”AAR（Fat AAR），它能把所有直接或间接的依赖（包括其他AAR、JAR甚至模块）都“吞”进去，变成一个独立、完整的包。业务方只需要依赖这一个文件，所有功能开箱即用，清爽无比。这对于需要对外提供SDK、封装核心能力给多个团队复用，或者内部模块化架构中简化依赖关系的场景，尤其重要。

2. 选对工具：从 fat-aar 到 fat-aar-android

最早解决这个问题的是 fat-aar 这个Gradle脚本。它的思路很直接，就是拦截AAR的打包过程，把依赖库里的类、资源、清单文件等挖出来，合并到主AAR里。但是，这个项目已经年久失修，最大的问题是它跟不上Android Gradle Plugin（AGP）的迭代速度。

我试过在老项目里用fat-aar，AGP版本一超过3.x，各种稀奇古怪的编译错误就来了，要么资源合并失败，要么R文件生成错乱。维护一个不断适配新Gradle的脚本成本太高，所以原作者也停止了更新。

好在社区有接力者。kezong/fat-aar-android 这个项目完美地接过了接力棒。它完全兼容了fat-aar的功能，并且持续维护，支持AGP从3.0到7.1.x，Gradle从4.9到7.3等主流版本。我用它在新老项目上都实践过，稳定性确实不错，基本做到了“配置即用”，不需要我们去魔改构建脚本。因此，我们接下来的实践就基于这个插件展开。

简单来说，fat-aar-android 插件就像一个智能的AAR打包流水线管理员。在常规打包流程中，它插入了一系列自定义的“合并”任务。当Gradle解析完所有依赖后，插件会识别出哪些依赖被标记为需要嵌入（embed），然后把这些依赖对应的AAR或JAR解包，将其中的classes.jar、res文件夹、AndroidManifest.xml、assets、jni库等资产，按照既定规则，合并到主模块对应的中间产物中，最后再打包成最终的、包含一切的Fat AAR。

3. 5分钟快速上手：基础配置与打包

理论说再多，不如动手跑一遍。我们来创建一个最简单的场景：你有一个library模块，它依赖了一个本地的第三方AAR文件（比如someSDK.aar），现在你想把someSDK.aar合并进你最终输出的AAR里。

3.1 第一步：引入插件到项目

首先，打开你项目根目录下的 build.gradle（注意是Project级别的那个，不是Module的）。在 buildscript 的 dependencies 块里，添加插件的classpath依赖。

buildscript {
    repositories {
        mavenCentral() // 确保能从Maven中央仓库拉取插件
        google() // 通常也需要
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:7.2.1' // 你的