merge-module

Project Url: byhook/merge-module
Introduction: 工程组件化落地实践之后,对指定的多个组件合并成一个 aar 包,灵活裁剪组合业务功能,并发布到私服的完整方案
More: Author   ReportBugs   
Tags:

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

概述

简单介绍一下项目情况,笔者做这个项目快两年了,之所以有这篇文章,源于项目的需求,因为项目除了公司内部使用,还需要抽取 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 版本一致

小结

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

纸上得来终觉浅,绝知此事要躬行!

示例项目

脚本地址

Apps
About Me
GitHub: Trinea
Facebook: Dev Tools