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

這篇文章主要介紹“Android MonoRepo多倉和單倉的差別是什么”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“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進行持續的迭代操作。

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

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