逛掘金很久了，之前注册过邮箱账号，但是现在每次登录，都要求重置密码，改了也没用，很绝望，重新注册了一个账号。 今天第一次在掘金上分享，废话不多说，直接开始正题。

• 概述
• 合并的坑
• 思考与扩展
• 混淆配置
• 小结

概述

简单介绍一下项目情况，笔者做这个项目快两年了，之所以有这篇文章，源于项目的需求，因为项目除了公司内部使用，还需要抽取 sdk 给第三方合作公司使用，并且不同的合作方可能会对 sdk 作改动，A 公司可能不要录屏功能，B 公司可能只要视频播放功能,不要视频发布，如何在不侵入我们主版本业务的情况下解决这个问题呢？

聪明的你肯定想到了，切分支呗！

这种方式只能解决一时之需，但是后续的主版本迭代，差异会越来越大，主版本同步到 SDK 的效率越来越低。 所以一旦是你采用了此种方案，我个人建议你做好跑路的准备！

所以去年底的时候，将组件化落地到了项目中，将各个模块独立，按照第三方的需要，实现灵活的搭配，这样一来，可以解耦我们的各个模块，便于维护，也可以适应第三方的定制需求，但是今天笔者讨论的并非组件化相关的内容，与该主题相关的内容很多，笔者今天想讨论的是组件化之后踩到的一些坑，，可能这些坑你永远也不会碰到，但是既然来了，看完又何妨呢？

目前项目架构如图所示：

组件化已基本完成，这才迈开了第一步，如何实现差异化呢？

1.分别打包

将各个独立的组件分别打包成对应的 aar，提供给第三方，但是又涉及到一个问题，那就是混淆的问题，如果直接分别提供原始的 aar 包，那么源代码几乎等于完全暴露，如果分别混淆，又会存在一个问题，公共组件中常用的工具类被混淆，上层的短视频这些组件就会找不到对应的类。

2.合并打包

这种方案具备良好的可行性，因为最终合并的文件只有一个，便于混淆，遗憾的是 Android 官方并没有提供这种合并的操作，但是发现 github 上有作者开源了一个合并脚本[fat-aar.gradle](https://github.com/adwiv/android-fat-aar)，这个脚本的作用实际就是合并我们的多个组件为一个 aar

合并的坑

下面笔者将用一个示例工程来演示合并的一些相关问题。 合并组件工程示例

用一张简单的图来描述其中的依赖关系

最上层的是我们要生成的最终的 merge.aar 他会合并直播间 liveroom 模块，合并 video 视频模块，而对应的模块也会依赖下层的组件，如何依赖合并呢？

apply from: "../fat-aar.gradle"

embedded project(':common')
embedded project(':upload')
embedded project(':download')
embedded project(':video')
embedded project(':liveroom')

注意: 需要合并的组件，只需要在最上层的组件中使用embedded关键字标记即可，并且下层所依赖的所有组件，都需要标记一次

接下来直接使用命令打包合并

cd merge
gradle clean asR

合并完成之后你以为就结束了吗？你太年轻了！！！ 当你给别人使用的时候，马上就会发现第一个坑：

出现这个错误的原因，经过笔者肉眼的分析(各种 google，各种 stackoverflow)，发现是由 gradle 的插件版本引起的

笔者工作的环境

系统: ubuntu 16.04
gradle 插件版本是 2.3.3
gradle 的版本是 3.5

降级到 gradle 插件版本

classpath 'com.android.tools.build:gradle:2.2.3'

此时编译直接报错：

笔者用了一个比较笨的方法： 强行指定 fat-aar.gradle 脚本中的版本

终于合并完成！！！ 但是不明白这两者合并出来的 aar 包差异在哪里，所以我将两个插件版本分别合并的 aar 包截图观察了一下

gradle2.3.3 版本合并的 aar 包 gradle2.2.3 版本合并的 aar 包

可以看到后者打包出来的 aar 文件，在 libs 目录中有一个 jar 包，这个 jar 包里存放的就是相关的 R 文件

所以解决上述问题的方案：

1.降级 gradle 插件版本到 2.2.3 版本，并修改对应脚本里的版本号

2.使用 gradle 插件版本 2.2.3 以上，但是需要手动修改 fat-aar.gradle 插件的内容，使之合并相关的 R 文件的 jar 包，这个问题大家也可以思考一下？

要知道，gradle 的远程依赖功能实在是太方便了，我们可以很轻易的指定相关的依赖包，但是由于 aar 文件的特殊性，我们在组件中包含的一下远程依赖并不会被实际的合并到 aar 中去，例如你远程依赖了 okhttp 或者 glide 等相关的库，合并 aar 之后，就会出现如下的错误：

如何解决这个问题呢？聪明的你一定想到，maven

我们完全可以把这些依赖合并发布到 maven 中去，于是笔者尝试着搭建了nexus 私服，具体的搭建不是本文讨论的重点。

幸运的是，fat-aar 的作者给我们提供了相关的 publish.gradle 的脚本，真的不得不说，想什么来什么啊，既然有了现成的轮子，我们就直接跑呗！

在最上层的merge模块中添加依赖

apply from: '../publish.gradle'

并添加如下配置

android {

    ...

    libraryVariants.all { variant ->
        variant.outputs.each { output ->
            def outputFile = output.outputFile
            if (outputFile != null && outputFile.name.endsWith('.aar')) {
                def fileName = getArtifactFileName()
                output.outputFile = new File(outputFile.parent, fileName)
            }
        }
    }

}

def getArtifactFileName() {
    return "${POM_ARTIFACT_ID}-${VERSION_NAME}.aar"
}

接下来配置自己的 nexus 私服即可

maven {
     //替换自己搭建的私服
     url "http://127.0.0.1:8081/nexus/content/repositories/releases"
 }

通刚才的合并打包方式，最后发布到自己的 nexus 私服上

你以为这样就结束了吗？并没有！！！

实际操作过程中，笔者发现，我们本地实际是有依赖本地第三方的 aar 包的，换句话说，并非所有的库都是远程依赖，你会发现，原来脚本居然会将本地依赖的 aar 文件，也合并到 pom.xml 文件中，继而发布到 nexus 私服上去了，这个时候给别人远程依赖，就会一直找不到相关的本地库

如何解决呢？

看来偷懒是不行的了，还是得改脚本，经过笔者的观察，发现在生成的 pom.xml 中可以过滤掉

pom.withXml {
                def dependenciesNode = asNode().appendNode('dependencies')

                depList.values().each {
                    ResolvedDependency dep ->
                        def hasGroup = dep.moduleGroup != null
                        def hasName = (dep.moduleName != null && !"unspecified".equals(dep.moduleName) && !"".equals(dep.moduleVersion))
                        def hasVersion = (dep.moduleVersion != null && !"".equals(dep.moduleVersion) && !"unspecified".equals(dep.moduleVersion))

                        if (hasGroup && hasName && hasVersion) {
                            def dependencyNode = dependenciesNode.appendNode('dependency')
                            dependencyNode.appendNode('groupId', dep.moduleGroup)
                            dependencyNode.appendNode('artifactId', dep.moduleName)
                            dependencyNode.appendNode('version', dep.moduleVersion)
                        }
                }
            }

即把版本号为空的过滤掉即可。

思考与扩展

经过一番折腾，好歹也是合并出来我们想要的东西，但是笔者刚刚也说到了，公司主项目除了自己使用，还是组合成 sdk 给第三方使用，第三方可能会改下首页的布局，颜色，等等。如何在不侵入主业务的情况下，作变更呢？其实很简单，借鉴 Android 中多渠道包的生成，同名的资源放在不同的目录 遗憾的是原生的脚本并不支持这种姿势，我在最上层的merge模块中使用同名的资源试图覆盖下层的资源，达到替换的目的，并未得逞！！！ 没办法，还是得改脚本，改动的思想实际就是在脚本合并的过程中，优先记录最上层的资源名称，当合并下层模块的资源文件时，直接跳过即可，改过的脚本在文章的末尾。

混淆配置

关于混淆的配置，只需要在最上层的 merge 模块中配置即可

注意事项

1.尽量不要使用原本的脚本文件，因为原作者已经几年未更新过，文章末尾有笔者的改动过的脚本文件

2.各个组件的清单会合并，不需要在最上层的组件中统一注册

3.本地依赖的 jar 包不用担心，因为脚本会合并到最终 aar 库的 lib 目录下

4.本地依赖的 aar 包，要记得随着远程依赖，给第三方一起依赖，即第三方除了依赖我们的远程依赖，还需要本地依赖我们所使用的 aar 文件，这也算是一个缺陷吧

5.第三方依赖的插件版本最好跟我们合并使用的 gradle 版本一致

小结

到目前为止，合并多组件的几个坑基本已经走了一遍了，其实在去年底，笔者在公司的直播项目中已经将组件化落地了，而后在实现多组件的道路上也踩了不少坑，本来这篇文章并没有打算发布出来，因为并不是所有人都会碰到这类需求，但是前段时间有个朋友公司问了我相关的问题，看他踩坑了很久，所以还是觉得发布出来，至少对于看到的人而言，以后碰到类似问题，可以少走些弯路，提高效率。

纸上得来终觉浅，绝知此事要躬行！

示例项目

脚本地址