Android MonoRepo多仓单仓

前言

今天不打算展开任何关于技术的探讨，只是想抛出一些观点，关于工程结构上的。可能有些人赞成也有些人反对，但是我觉得技术的世界还是需要一些讨论和探索的。

并没有指明那些就是最优解，可能都只是一些个人观点而已。

两种模式其实我都略微有点接触，当然文章也存粹是个人观点。我们先看下下面这幅图，其实就是一个原始工程结构，分仓结构，还有单仓结构的工程。

什么是Monorepo

Monorepo的意思是在版本控制系统的单个代码库里包含了许多项目的代码。这些项目虽然有可能是相关的，但通常在逻辑上是独立的，并由不同的团队维护。

简单的说当我们把所有的代码全都放在一个仓库内，然后所有同学都在这个仓库上进行开发，这种模式就可以称之为Monorepo。

很多人认为这种形式不就回到了一开始并没有完成组件化的单Project的模式。然而并不是这样的，Monorepo内还是会有分层结构设计，也具有组件化的所有，只是所有的源代码聚合在一个仓库内，每个同学也是在自己负责的业务模块中开发的。

这种有什么好处呢？那么他的缺点是什么呢？接下来要介绍下他的兄弟，然后可能双向对比才能说明这到底是个啥东西。

什么是multi-repo

一个项目由多个git仓库来构成，然后通过依赖aar的形式将几个仓库组合在一起。

现在市面上大部分公司的解决方案应该都是多仓，然后通过插件将多个工程同步aar版本配置的形式完成的multi-repo模式。

基本上每个业务会独立成一个仓库，然后基础库也会变成一个独立的仓库，然后通过依赖aar的方式来引入其对其他仓库的依赖的形式进行开发。我把这种模式叫做multi-repo。

多仓模式下因为各个project都是独立的，所以配置统一,依赖管理等等一直都是个老大难的问题, 但是也并非无解，很多公司包括我以前都会写一个依赖版本清洗的插件，然后将依赖的ext放在远端，之后基于branc分支的形式提供给到各个使用的业务方。

multi-repo的问题

我以前在哈啰的时候遇到过一个场景，我们依赖于业务方的代码，然后业务方也依赖与我们的代码，然后就变成我先发布个快照版本给到对方，然后他们基于我们的快照版本再进行代码开发，之后我再把他们的快照版本更新过来，进行代码开发的情况。

一般情况下可能还好，但是如果万一有人不小心更改到api的方法入参或者一些函数的名字。那么在最后的编译阶段会出现运行是出现方法找不到的问题，然后出现崩溃的问题，这种问题发生的次数应该是非常的多的。

因为代码的隔离情况，所以大家都在自己的分支和仓库上独立开发，对于别人的代码处于一个低感知的状态，所以自然而然的我认为代码上是一个不稳定的状态。

很多公司最后会在交付阶段采用全源代码进行编译的方式给到最终的apk。原理就是通过一个aar切换源代码的插件，然后把所有工程聚合在一起进行打包，避免出现一些非必要的编译问题。

还有就是项目重构以及项目持续升级，多仓需要对每一个工程都设置一套ci/cd体系，还有就是分支管理等等问题就会不停的消耗开发的精力，同时因为大家都是自己的一套系统，后面就会出现不可避免的内卷。

我听一个网友说过一个案例，因为是aar的依赖方式，所以他们在自己的模块中直接依赖了对方的项目，然后对方的项目也直接依赖了他们的aar产物，在实际开发中，这种依赖成环的现象是一定要避免的，但是在多仓中他也不一定会报错提示。

另外则是一些统一的升级操作，比如说AGP版本升级，koltin版本升级,gralde 插件版本等等配置信息的升级。

代码复用率方面多仓可能会更低一点。每个业务可能都会有一些可能更优秀的代码实现，但是如果你想复用的这个就会相对比较糟糕，可能就会涉及到大量的代码cv。一个稳定的功能还好，如果是一个还在迭代过程中的代码，多仓反倒更容易出现代码风险。

multi-repo的优点

相对来说多仓的工程结构会更独立，每个工程都是具有独立打开的能力的，这样对于业务同学来说，他的学习成本是相对最低的，因为他基本上只要对自己的业务模块负责就可以了，更专注与自己当前所需要关心的。

工程同步和编译的速度会更快，因为大部分仓库都已经被编译成aar产物了，所以对于分仓模式来说，他们的同步和编译都只需要对于当前工程负责就可以了，不需要编译与当前工程无关的东西，所以速度上来说会更快。

学习成本低，因为只要对当前工程负责，所以只要搞懂当前工程如何能工作就可以了。

安全性相对来说会更高，因为工程结构相对独立，所以对于一些相对涉密的工程来说，分仓的结构的安全性会更高，即时看到代码也无权进行任何代码变动。

MonoRepo的缺点

相比较于分仓模式，MonoRepo的编译速度会更慢，同步的时间也会更长。因为每个工程都需要重新Configuration策略，将aar依赖方式切换成源代码依赖。同时不同于aar依赖的情况，源代码依赖的情况下每个工程的build.gradle还有全局配置以及插件等都需要被执行到，所以消耗的时间会更长一点点。也就是正常的gradle相关的生命周期，对于源码编译的工程都是需要执行一次的。

工具链相对来说会比较复杂，因为所有源代码都在一起，所以工程内可能需要配置更多ndk等等配置环境，需要更多的工具链将这些仓库进行协调，从而能达到混编的状态下。

安全性相对来说较差，比如说相对机密的公司核心源代码。因为单仓的缘故，所以代码的权限就会对所有人开放。如果出现源码泄露的状况，就相对来说比较严重了。

同时工程体量会变得非常巨大，也会造成编码过程中需要频繁的rebase主干的代码，可能每天都会有巨量的代码落后的情况。但是这个个人觉得是在可预期范围内的。

MonoRepo的优点

要说到MonoRepo的优点，其实也都是相对于分仓模式来说的。

首先要提出的第一个观点是开发状况下你的仓库状态是稳定的。工作流程上来说，都是切出一个分支，然后在这个分支上开发自己的业务需求，之后合并回主干。但是和多仓相比，即使是多人协作开发，因为大家所使用的都是源代码，只要拉取了代码各自的变更都是当场可见的。每一个提交相对来说都是知道彼此互相做了什么事情的，所以这就是相对来说的稳定切片。就算我们重新rebase了主干之后，这部分代码也是相当稳定的一个状态，因为他们都是编译完测试完成之后才合入的。即使代码变更了，因为有编译阶段的语法校验，所以所有的改动都是一个相对来说的稳定状态。

这一点我认为是非常重要的一点。对比与多仓，因为每个人都在自己的仓库可以提交代码，彼此的提交都是互相隔离分立的，所以我们无法预知到对方的改动是否会对当前的我们产生影响，这就导致了存在更多的风险。这个也就是MonoRepo所说的原子提交。

高参与度与代码的可复用性，因为所有代码对大家都是可见的状态，所以当我们需要一些我们想要的代码的时候，并不需要直接去cv他们，而可以直接通过依赖的形式直接获取到他们的使用权。如果碰到我们前面所说的不稳定状态的情况下，因为大家都能参与到代码的改动中，所以我们可以让我们的代码更趋于一个稳定状态，而不是打补丁的方式这里改一句哪里改一句。

更有效的依赖检查，前面所说的模块间互相依赖成环的问题，MonoRepo也是不存在的，依托于编译器的特性，当依赖成环的情况下，编译自然就会报错。这样就可以避免掉一些错误的写法。

更简便的代码升级操作，之前和大家介绍过我们当前的AGP的版本相对来说已经是比较高的版本了，我们的插件数量其实也很多，我们也有插件化等等黑科技。在编译阶段上我们也魔改了不少代码。但是因为我们的单仓结构，我们可以只需要改动一个version版本号就可以对所有的仓库生效。快速的将app进行持续的迭代操作。

单一的检查工具，这部分就是避免重复性建设的工作了，因为仓库单一所以只要对当前仓库进行一份静态检查就行了，避免重复造轮子的风险。