前言

今天不打算展開任何關(guān)于技術(shù)的探討，只是想拋出一些觀點，關(guān)于工程結(jié)構(gòu)上的?？赡苡行┤速澇梢灿行┤朔磳?，但是我覺得技術(shù)的世界還是需要一些討論和探索的。

并沒有指明那些就是最優(yōu)解，可能都只是一些個人觀點而已。

兩種模式其實我都略微有點接觸，當然文章也存粹是個人觀點。我們先看下下面這幅圖，其實就是一個原始工程結(jié)構(gòu)，分倉結(jié)構(gòu)，還有單倉結(jié)構(gòu)的工程。

什么是Monorepo

Monorepo的意思是在版本控制系統(tǒng)的單個代碼庫里包含了許多項目的代碼。這些項目雖然有可能是相關(guān)的，但通常在邏輯上是獨立的，并由不同的團隊維護。

簡單的說當我們把所有的代碼全都放在一個倉庫內(nèi)，然后所有同學都在這個倉庫上進行開發(fā)，這種模式就可以稱之為Monorepo。

很多人認為這種形式不就回到了一開始并沒有完成組件化的單Project的模式。然而并不是這樣的，Monorepo內(nèi)還是會有分層結(jié)構(gòu)設(shè)計，也具有組件化的所有，只是所有的源代碼聚合在一個倉庫內(nèi)，每個同學也是在自己負責的業(yè)務模塊中開發(fā)的。

這種有什么好處呢？那么他的缺點是什么呢？接下來要介紹下他的兄弟，然后可能雙向?qū)Ρ炔拍苷f明這到底是個啥東西。

什么是multi-repo

一個項目由多個git倉庫來構(gòu)成，然后通過依賴aar的形式將幾個倉庫組合在一起。

現(xiàn)在市面上大部分公司的解決方案應該都是多倉，然后通過插件將多個工程同步aar版本配置的形式完成的multi-repo模式。

基本上每個業(yè)務會獨立成一個倉庫，然后基礎(chǔ)庫也會變成一個獨立的倉庫，然后通過依賴aar的方式來引入其對其他倉庫的依賴的形式進行開發(fā)。我把這種模式叫做multi-repo。

多倉模式下因為各個project都是獨立的，所以配置統(tǒng)一,依賴管理等等一直都是個老大難的問題, 但是也并非無解，很多公司包括我以前都會寫一個依賴版本清洗的插件，然后將依賴的ext放在遠端，之后基于branc分支的形式提供給到各個使用的業(yè)務方。

multi-repo的問題

我以前在哈啰的時候遇到過一個場景，我們依賴于業(yè)務方的代碼，然后業(yè)務方也依賴與我們的代碼，然后就變成我先發(fā)布個快照版本給到對方，然后他們基于我們的快照版本再進行代碼開發(fā)，之后我再把他們的快照版本更新過來，進行代碼開發(fā)的情況。

一般情況下可能還好，但是如果萬一有人不小心更改到api的方法入?yún)⒒蛘咭恍┖瘮?shù)的名字。那么在最后的編譯階段會出現(xiàn)運行是出現(xiàn)方法找不到的問題，然后出現(xiàn)崩潰的問題，這種問題發(fā)生的次數(shù)應該是非常的多的。

因為代碼的隔離情況，所以大家都在自己的分支和倉庫上獨立開發(fā)，對于別人的代碼處于一個低感知的狀態(tài)，所以自然而然的我認為代碼上是一個不穩(wěn)定的狀態(tài)。

很多公司最后會在交付階段采用全源代碼進行編譯的方式給到最終的apk。原理就是通過一個aar切換源代碼的插件，然后把所有工程聚合在一起進行打包，避免出現(xiàn)一些非必要的編譯問題。

還有就是項目重構(gòu)以及項目持續(xù)升級，多倉需要對每一個工程都設(shè)置一套ci/cd體系，還有就是分支管理等等問題就會不停的消耗開發(fā)的精力，同時因為大家都是自己的一套系統(tǒng)，后面就會出現(xiàn)不可避免的內(nèi)卷。

我聽一個網(wǎng)友說過一個案例，因為是aar的依賴方式，所以他們在自己的模塊中直接依賴了對方的項目，然后對方的項目也直接依賴了他們的aar產(chǎn)物，在實際開發(fā)中，這種依賴成環(huán)的現(xiàn)象是一定要避免的，但是在多倉中他也不一定會報錯提示。

另外則是一些統(tǒng)一的升級操作，比如說AGP版本升級，koltin版本升級,gralde 插件版本等等配置信息的升級。

代碼復用率方面多倉可能會更低一點。每個業(yè)務可能都會有一些可能更優(yōu)秀的代碼實現(xiàn)，但是如果你想復用的這個就會相對比較糟糕，可能就會涉及到大量的代碼cv。一個穩(wěn)定的功能還好，如果是一個還在迭代過程中的代碼，多倉反倒更容易出現(xiàn)代碼風險。

multi-repo的優(yōu)點

相對來說多倉的工程結(jié)構(gòu)會更獨立，每個工程都是具有獨立打開的能力的，這樣對于業(yè)務同學來說，他的學習成本是相對最低的，因為他基本上只要對自己的業(yè)務模塊負責就可以了，更專注與自己當前所需要關(guān)心的。

工程同步和編譯的速度會更快，因為大部分倉庫都已經(jīng)被編譯成aar產(chǎn)物了，所以對于分倉模式來說，他們的同步和編譯都只需要對于當前工程負責就可以了，不需要編譯與當前工程無關(guān)的東西，所以速度上來說會更快。

學習成本低，因為只要對當前工程負責，所以只要搞懂當前工程如何能工作就可以了。

安全性相對來說會更高，因為工程結(jié)構(gòu)相對獨立，所以對于一些相對涉密的工程來說，分倉的結(jié)構(gòu)的安全性會更高，即時看到代碼也無權(quán)進行任何代碼變動。

MonoRepo的缺點

相比較于分倉模式，MonoRepo的編譯速度會更慢，同步的時間也會更長。因為每個工程都需要重新Configuration策略，將aar依賴方式切換成源代碼依賴。同時不同于aar依賴的情況，源代碼依賴的情況下每個工程的build.gradle還有全局配置以及插件等都需要被執(zhí)行到，所以消耗的時間會更長一點點。也就是正常的gradle相關(guān)的生命周期，對于源碼編譯的工程都是需要執(zhí)行一次的。

工具鏈相對來說會比較復雜，因為所有源代碼都在一起，所以工程內(nèi)可能需要配置更多ndk等等配置環(huán)境，需要更多的工具鏈將這些倉庫進行協(xié)調(diào)，從而能達到混編的狀態(tài)下。

安全性相對來說較差，比如說相對機密的公司核心源代碼。因為單倉的緣故，所以代碼的權(quán)限就會對所有人開放。如果出現(xiàn)源碼泄露的狀況，就相對來說比較嚴重了。

同時工程體量會變得非常巨大，也會造成編碼過程中需要頻繁的rebase主干的代碼，可能每天都會有巨量的代碼落后的情況。但是這個個人覺得是在可預期范圍內(nèi)的。

MonoRepo的優(yōu)點

要說到MonoRepo的優(yōu)點，其實也都是相對于分倉模式來說的。

首先要提出的第一個觀點是開發(fā)狀況下你的倉庫狀態(tài)是穩(wěn)定的。工作流程上來說，都是切出一個分支，然后在這個分支上開發(fā)自己的業(yè)務需求，之后合并回主干。但是和多倉相比，即使是多人協(xié)作開發(fā)，因為大家所使用的都是源代碼，只要拉取了代碼各自的變更都是當場可見的。每一個提交相對來說都是知道彼此互相做了什么事情的，所以這就是相對來說的穩(wěn)定切片。就算我們重新rebase了主干之后，這部分代碼也是相當穩(wěn)定的一個狀態(tài)，因為他們都是編譯完測試完成之后才合入的。即使代碼變更了，因為有編譯階段的語法校驗，所以所有的改動都是一個相對來說的穩(wěn)定狀態(tài)。

這一點我認為是非常重要的一點。對比與多倉，因為每個人都在自己的倉庫可以提交代碼，彼此的提交都是互相隔離分立的，所以我們無法預知到對方的改動是否會對當前的我們產(chǎn)生影響，這就導致了存在更多的風險。這個也就是MonoRepo所說的原子提交。

高參與度與代碼的可復用性，因為所有代碼對大家都是可見的狀態(tài)，所以當我們需要一些我們想要的代碼的時候，并不需要直接去cv他們，而可以直接通過依賴的形式直接獲取到他們的使用權(quán)。如果碰到我們前面所說的不穩(wěn)定狀態(tài)的情況下，因為大家都能參與到代碼的改動中，所以我們可以讓我們的代碼更趨于一個穩(wěn)定狀態(tài)，而不是打補丁的方式這里改一句哪里改一句。

更有效的依賴檢查，前面所說的模塊間互相依賴成環(huán)的問題，MonoRepo也是不存在的，依托于編譯器的特性，當依賴成環(huán)的情況下，編譯自然就會報錯。這樣就可以避免掉一些錯誤的寫法。

更簡便的代碼升級操作，之前和大家介紹過我們當前的AGP的版本相對來說已經(jīng)是比較高的版本了，我們的插件數(shù)量其實也很多，我們也有插件化等等黑科技。在編譯階段上我們也魔改了不少代碼。但是因為我們的單倉結(jié)構(gòu)，我們可以只需要改動一個version版本號就可以對所有的倉庫生效?？焖俚膶pp進行持續(xù)的迭代操作。

單一的檢查工具，這部分就是避免重復性建設(shè)的工作了，因為倉庫單一所以只要對當前倉庫進行一份靜態(tài)檢查就行了，避免重復造輪子的風險。

以上就是Android MonoRepo多倉和單倉的差別理論的詳細內(nèi)容，更多關(guān)于Android MonoRepo多倉單倉的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論