Android?MonoRepo多倉和單倉的差別是什么

這篇文章主要介紹“Android MonoRepo多倉和單倉的差別是什么”的相關(guān)知識(shí)，小編通過實(shí)際案例向大家展示操作過程，操作方法簡單快捷，實(shí)用性強(qiáng)，希望這篇“Android MonoRepo多倉和單倉的差別是什么”文章能幫助大家解決問題。

前言

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

什么是Monorepo

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

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

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

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

什么是multi-repo

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

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

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

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

multi-repo的問題

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

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

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

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

還有就是項(xiàng)目重構(gòu)以及項(xiàng)目持續(xù)升級(jí)，多倉需要對(duì)每一個(gè)工程都設(shè)置一套ci/cd體系，還有就是分支管理等等問題就會(huì)不停的消耗開發(fā)的精力，同時(shí)因?yàn)榇蠹叶际亲约旱囊惶紫到y(tǒng)，后面就會(huì)出現(xiàn)不可避免的內(nèi)卷。

我聽一個(gè)網(wǎng)友說過一個(gè)案例，因?yàn)槭莂ar的依賴方式，所以他們?cè)谧约旱哪K中直接依賴了對(duì)方的項(xiàng)目，然后對(duì)方的項(xiàng)目也直接依賴了他們的aar產(chǎn)物，在實(shí)際開發(fā)中，這種依賴成環(huán)的現(xiàn)象是一定要避免的，但是在多倉中他也不一定會(huì)報(bào)錯(cuò)提示。

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

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

multi-repo的優(yōu)點(diǎn)

相對(duì)來說多倉的工程結(jié)構(gòu)會(huì)更獨(dú)立，每個(gè)工程都是具有獨(dú)立打開的能力的，這樣對(duì)于業(yè)務(wù)同學(xué)來說，他的學(xué)習(xí)成本是相對(duì)最低的，因?yàn)樗旧现灰獙?duì)自己的業(yè)務(wù)模塊負(fù)責(zé)就可以了，更專注與自己當(dāng)前所需要關(guān)心的。

工程同步和編譯的速度會(huì)更快，因?yàn)榇蟛糠謧}庫都已經(jīng)被編譯成aar產(chǎn)物了，所以對(duì)于分倉模式來說，他們的同步和編譯都只需要對(duì)于當(dāng)前工程負(fù)責(zé)就可以了，不需要編譯與當(dāng)前工程無關(guān)的東西，所以速度上來說會(huì)更快。

學(xué)習(xí)成本低，因?yàn)橹灰獙?duì)當(dāng)前工程負(fù)責(zé)，所以只要搞懂當(dāng)前工程如何能工作就可以了。

安全性相對(duì)來說會(huì)更高，因?yàn)楣こ探Y(jié)構(gòu)相對(duì)獨(dú)立，所以對(duì)于一些相對(duì)涉密的工程來說，分倉的結(jié)構(gòu)的安全性會(huì)更高，即時(shí)看到代碼也無權(quán)進(jìn)行任何代碼變動(dòng)。

MonoRepo的缺點(diǎn)

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

工具鏈相對(duì)來說會(huì)比較復(fù)雜，因?yàn)樗性创a都在一起，所以工程內(nèi)可能需要配置更多ndk等等配置環(huán)境，需要更多的工具鏈將這些倉庫進(jìn)行協(xié)調(diào)，從而能達(dá)到混編的狀態(tài)下。

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

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

MonoRepo的優(yōu)點(diǎn)

要說到MonoRepo的優(yōu)點(diǎn)，其實(shí)也都是相對(duì)于分倉模式來說的。

首先要提出的第一個(gè)觀點(diǎn)是開發(fā)狀況下你的倉庫狀態(tài)是穩(wěn)定的。工作流程上來說，都是切出一個(gè)分支，然后在這個(gè)分支上開發(fā)自己的業(yè)務(wù)需求，之后合并回主干。但是和多倉相比，即使是多人協(xié)作開發(fā)，因?yàn)榇蠹宜褂玫亩际窃创a，只要拉取了代碼各自的變更都是當(dāng)場(chǎng)可見的。每一個(gè)提交相對(duì)來說都是知道彼此互相做了什么事情的，所以這就是相對(duì)來說的穩(wěn)定切片。就算我們重新rebase了主干之后，這部分代碼也是相當(dāng)穩(wěn)定的一個(gè)狀態(tài)，因?yàn)樗麄兌际蔷幾g完測(cè)試完成之后才合入的。即使代碼變更了，因?yàn)橛芯幾g階段的語法校驗(yàn)，所以所有的改動(dòng)都是一個(gè)相對(duì)來說的穩(wěn)定狀態(tài)。

這一點(diǎn)我認(rèn)為是非常重要的一點(diǎn)。對(duì)比與多倉，因?yàn)槊總€(gè)人都在自己的倉庫可以提交代碼，彼此的提交都是互相隔離分立的，所以我們無法預(yù)知到對(duì)方的改動(dòng)是否會(huì)對(duì)當(dāng)前的我們產(chǎn)生影響，這就導(dǎo)致了存在更多的風(fēng)險(xiǎn)。這個(gè)也就是MonoRepo所說的原子提交。

高參與度與代碼的可復(fù)用性，因?yàn)樗写a對(duì)大家都是可見的狀態(tài)，所以當(dāng)我們需要一些我們想要的代碼的時(shí)候，并不需要直接去cv他們，而可以直接通過依賴的形式直接獲取到他們的使用權(quán)。如果碰到我們前面所說的不穩(wěn)定狀態(tài)的情況下，因?yàn)榇蠹叶寄軈⑴c到代碼的改動(dòng)中，所以我們可以讓我們的代碼更趨于一個(gè)穩(wěn)定狀態(tài)，而不是打補(bǔ)丁的方式這里改一句哪里改一句。

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

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

單一的檢查工具，這部分就是避免重復(fù)性建設(shè)的工作了，因?yàn)閭}庫單一所以只要對(duì)當(dāng)前倉庫進(jìn)行一份靜態(tài)檢查就行了，避免重復(fù)造輪子的風(fēng)險(xiǎn)。

關(guān)于“Android MonoRepo多倉和單倉的差別是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。