本文探讨了组件API模块的设计，如何通过EventBus简化事件传递，以及如何通过RefactorMan工具自动化组件拆分。还介绍了主工程与组件的编译策略，处理包含子业务线组件的复杂联动问题和动态模块结构的应用。
获取实例并调用
Provider.get(AbcInterface.class).doSomething()
(5) EventBus
这个自不必说，虽然说滥用是一个问题，但是有些场景下，使用事件还是最为方便简单的方式
(6) 组件 API 模块
上面提到的接口和事件以及一些跨组件使用的 Model 放到哪里好呢？如果直接将这些类下沉到一个公共组件中，由于业务的频繁更新，这个公共组件可能会更新得十分频繁，开发也十分的不方便，所以使用公共组件是行不通的，于是我们采取了另一种方式——组件 API ：为每个有对外暴露需求的组件添加一个 API 模块，API 模块中只包含对外暴露的 Model 和组件通信用的 Interface 与 Event。有需要引用这些类的组件只要依赖 API 即可。
[图片上传中...(image-a39cd0-1598345691997-6)]
一个典型的组件工程结构是这个样子：
以上图为例，它包含三个模块：
template ：组件代码，它包含了这个组件所有业务代码
template-api：组件的接口模块，专门用于与其他组件通信，只包含 Model、Interface 和 Event，不存在任何业务和逻辑代码
app 模块：用于独立运行 app，它直接依赖组件模块，只要添加一些简单的配置，即可实现组件独立运行。
**组件半自动拆分**
有了解耦的方法，剩下的就是采取行动拆分组件了，拆组件是一个很头疼的问题，它非常考虑一个人的细心与耐心，由于无法准确知道有哪些代码要被拆走，也不能直观的知晓依赖关系，移动变得非常的困难且容易出错，一旦不能一次性拆分成功，到处都是编译错误，便只能靠人肉一点一点的挪。
工欲善其事，必先利其器。为了解决这个问题，我们开发了一个辅助工具 RefactorMan： 它可以递归的解析出工程中所有源码的引用和被引用情况，同时会根据预设规则自动分析出所有不合理的依赖，在开发人员根据提示解决了不合理依赖之后，即可将组件一键移出，大大减少了拆组件的工作量。我们在组件化初期曾经走过一些弯路，最初拆出的八个组件工程的的部分源码经历了几次的反复移动才得出最优解，而有了 RefactorMan，我们可以面对反复的拆分和组合组件有恃无恐。
Bonus ：由于可以分析和移动资源，所以额外获得了清理无用资源的功能。
**联合编译完整包**
单独运行组件 app 并不能完整的覆盖所有的 case，尤其是在给 QA 测试的时候，还是需要编译完整的主工程包的，所以我们需要一个直接编译完整包的方案：
最初我们的实现方式只针对组件，比较简单：
首先在 setting.gradle 中动态引入组件 module：
def allComponents = [“base”, “account” … “template” …]
allComponents.forEach({ name ->
if (shouldUseSource(name)) {
// 动态引入外部模块
include “:
n
a
m
e
"
p
r
o
j
e
c
t
(
"
:
{name}" project(":
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 50: …NT_GROUP } }̲ else { …{COMPONENT_GROUP}:
n
a
m
e
:
{name}:
name:{versions[name]}") { exclude group: COMPONENT_GROUP }
}
})
由于所有组件的 group 都是一样的，所以这样做并没有什么问题，但是后来一些基础 SDK 也出现了这种需求，这时候就需要一种通用的源码依赖方案，因此做了一下修改，直接使用 gradle 提供的依赖替换功能，只需要修改 setting.gradle 即可：
// … 忽略读取配置代码 …
configs.forEach { artifact, prj ->
include “:
p
r
j
.
n
a
m
e
"
p
r
o
j
e
c
t
(
"
:
{prj.name}" project(":
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 也会很慢，并且随着时间的推移，各个业务线的代码边界会像组件化之前的主工程一样逐渐劣化，耦合会越来越严重。
所以现在需求变成了这个样子：
1. 对外保持只有一个组件：有联动需求的时候，组件仍然只发布一次更新
2. 各个子业务仍旧保持互相独立和隔离，可以独立运行
我们曾经试图使用 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("…/
s
u
b
P
r
o
j
e
c
t
/
s
r
c
/
m
a
i
n
/
j
a
v
a
"
)
r
e
s
.
s
r
c
D
i
r
s
+
=
f
i
l
e
(
"
.
.
/
{subProject}/src/main/java") res.srcDirs += file("../
subProject/src/main/java")res.srcDirs+=file("../{subProject}/src/main/res")
最后
由于题目很多整理答案的工作量太大，所以仅限于提供知识点，详细的很多问题和参考答案我都整理成了 PDF文件
CodeChina开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》
厂面试真题+项目实战源码》](https://codechina.csdn.net/m0_60958482/android_p7)**
[外链图片转存中…(img-coLOIS8j-1630929539019)]
[外链图片转存中…(img-7ocS9SOp-1630929539021)]
7万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
