GitHub标星9-8k，知乎阅读10w+，极致干货-CSDN博客

本文链接：https://blog.csdn.net/2401_84002409/article/details/137170430

if (shouldUseSource(name)) {
// 动态引入外部模块
include “: ${name}" project(":$ {name}”).projectDir = getComponentDir(name);
}
})

然后在 app/build.gradle 中切换依赖，需要将所有被间接依赖的组件全部 exclude 以防止同时依赖了一个组件的 module 和 aar：

allComponents.forEach({ name ->
if (shouldUseSource(name)) {
implementation(project(“: $KaTeX parse error: Expected 'EOF', got '}' at position 46: …PONENT_GROUP } }̲ else { impleme…$ {COMPONENT_GROUP}: ${name}:$ {versions[name]}”) { exclude group: COMPONENT_GROUP }
}
})

由于所有组件的 group 都是一样的，所以这样做并没有什么问题，但是后来一些基础 SDK 也出现了这种需求，这时候就需要一种通用的源码依赖方案，因此做了一下修改，直接使用 gradle 提供的依赖替换功能，只需要修改 setting.gradle 即可：

// … 忽略读取配置代码 …
configs.forEach { artifact, prj ->
include “: ${prj.name}" project(":$ {prj.name}”).projectDir = new File(prj.dir)
}
gradle.allprojects { project ->
if (project == project.rootProject) {
return
}
project.configurations.all {
resolutionStrategy.dependencySubstitution {
configs.forEach { artifact, prj ->
// 在这里进行替换
substitute module(artifact) with project(“😒{prj.name}”)
}
}
}
}

而 build.gradle 的依赖写法与普通的工程完全一样。

普通状态下的的主工程：

源码引用 template 组件后的主工程：

这样我们就可以像之前在单工程中一样写代码了。

得益于源码引用，我们直接在提交组件代码的时候，CI 会自动联合主工程编译出完整包，QA 会根据完整包进行测试，在测试通过后即可自动发布到公司的仓库，并通过内部的集成平台集成到主工程

小 tip ：工程 .idea/vcs.xml 中定义了当前工程关联的 Git 仓库，可以在联合编译的同时通过修改 vcs.xml 来把组件目录也关联到主工程 Git 配置中，在开发过程中就可以使用 Android Studio 的内置 Git 功能了

包含子业务线的组件

我们当前的组件，绝大部分是一个组件一个仓库的，对于一般的组件来说，并没有什么问题，但是对于有的业务线，本身规模比较大，包含了若干个子业务，比如知乎大学，电子书、live 和私家课等子业务，这些子业务本身功能独立，但是共享整个业务线的基础代码，同时大业务线也有会一些汇总所有子业务的页面，它们的关系是这个样子：

这几个业务如果都要拆分出去独立成组件，然后抽离公共部分成为也成为一个业务线基础组件，这时候会面临一个很大的问题：由于几条业务线都属于同一个主业务线，做活动或者上新 Feature 的时候，这几个组件经常会发生联动，需要先更新 base 再更新其他业务线，提交 mr 也要同时提多个仓库，出现频繁的连锁更新；而如果不拆的话，业务线代码本身就已经很庞大，即使是单独编译组件 app 也会很慢，并且随着时间的推移，各个业务线的代码边界会像组件化之前的主工程一样逐渐劣化，耦合会越来越严重。

所以现在需求变成了这个样子：

对外保持只有一个组件：有联动需求的时候，组件仍然只发布一次更新
各个子业务仍旧保持互相独立和隔离，可以独立运行

我们曾经试图使用 sourceSets 的方式将不同的业务代码放到不同的文件夹，但是 sourceSets 的问题在于，它并不能限制各个 sourceSet 之间互相引用，base 模块甚至可以直接引用最上层的代码，虽然可以在编译期进行检查，但是总有一些后知后觉的意味，并且使用 sourceSets 想让各个模块单独跑起来配置也比较麻烦。而 Android Studio 的 module 天然具有隔离的优势。所以我们的解决方案是在组件工程中使用多 Module 结构：

各个子业务线分别拆成同一个工程中不同的 Module：它们共同依赖 base ，同时各个业务线互相不依赖，这些子业务又在一个主 Module 中汇集起来，正如上面图片所示那样

对于外界来说只有一个 main 组件，如果直接通过 ./gradlew :main:uploadArchives 来发布，那么就只能把 main Module 的代码发布上去，其他 Module 的代码是无法被连带上去的，所以我们需要在发布的时候将所有的代码合并到 main 中去。这时候只能使用添加 sourceSet 的方式，而一旦使用了 sourceSet，代码就不再隔离了。所以我们使用了一个动态的策略：编译时使用 sourceSet 依赖，其他时候使用 module 依赖，这样可以同时拥有两者的优势。

也就是说：表面看起来，这是一个普通的多模块的工程，但是实际上，他们的关系是动态的：写代码时是七个葫芦娃，编译时是葫芦小金刚：

如何做到呢，可以简单的判断当前启动的 Task，一般我们只在 assemble、install、upload 的时候使用合体操作，而其他时候使用普通的 project 依赖，示例代码如下：

boolean useSource = gradle.startParameter.taskNames.any {
it.contains(“assemble”) || it.contains(“install”) || it.contains(“upload”))
}
subProject.forEach { subProject ->
if (useSource) {
android.sourceSets.main {
java.srcDirs += file(“…/ ${subProject}/src/main/java") res.srcDirs += file("../$ {subProject}/src/main/res”)
}
} else {
dependencies { implementation project(“:$subProject”) }
}
}

其他资源例如 resources、assets、aidl、renderscript、jni、jniLibs、shaders 以及 aar 和 jar 文件，它们都是多文件的，可以使用与上面类似的方法添加。

但是 manifest 不同，一个 module 中只有一个 AndroidManifest.xml ，所以需要有一个方法将子业务的 manifest 合并。我们使用了官方提供的 ManifestMerger 实现了 manifest 的合并，这里不再展开合并的具体代码，有兴趣的同学可以自己去看源码。

将上面代码封装了一个方法 using，主 module 就可以这样引用子 module 了：

dependencies {
using “base”
using “sub1”
using “sub2”
using ‘sub3’
using ‘sub4’
}

由于每个子业务组件都是独立的，仍然可以单独配置独立编译独立运行，由于每个业务的代码量相对整个业务线来说大大减少了，所以得到了更快的编译速度。

总结

最近两年很多公司都开始了 App 的组件化，组件化的基础思想都是相通的，但是并没有一个放之四海而皆准的通用解决方案，各个公司在组件化的过程中都会根据自身的情况不断的调整方案，适合自身发展的，才是最好的。一些组件化初期看起来不起眼的问题，可能进行到后期才会慢慢显现出来，这时候就要及时调整方案。知乎的组件化也是在不断的变动中逐渐完善的，并且以后肯定也会随着业务和代码的变动不断的进行优化，这会是一个持续的过程，后续我们也会持续分享一些组件化遇到的问题和解决方案。

以上就是我们在组件化过程中的一部分实践，由于本人的水平有限，如有错误和疏漏，欢迎各位同学指正。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。