Android組件化項目如何利用Git的Submodule

背景

有些公司的項目可能須要作到兩個或多個項目公用一個業務組件，好比項目A和項目B公用一個業務組件A，若是項目使用的是Git來管理的話，業務組件A的源碼是放在項目A中的，一般咱們都是把業務組件A打包成jar或者aar，而後把包上傳到公司內部的maven倉庫中，項目B經過引用該包的maven 座標（groupId, artifactId, packaging, version）來進行依賴。可是這樣作項目B的同事可能會拿不到業務組件A源碼來修改，由於項目A和項目B可能在不一樣權限組。

你可能會說maven不是能夠上傳源碼的嗎？項目B的同事能夠讀取到源碼。的確是能夠maven上相關包的源碼，可是這不能修改。

你可能會說幹嗎要修改，業務組件A是屬於項目A的同事纔有權去修改的，項目B的同事只要拿來用就行，不須要管怎樣去修改。的確是這樣的，項目B的同事只須要拿來用就行，這也是比較合理的。

可是實際狀況，項目B可能在使用業務組件A的時候可能遇到一些比較難以復現的問題，這種狀況下實在沒有辦法只能引用業務組件A源碼進行調試。因此像這種業務組件A其實最好仍是單獨做爲一個項目來管理好一些。

怎麼把業務組件建立成一個項目來單獨管理

首先咱們來建立一個項目SubmoduleStudy，而後對這個項目配置Git管理，爲它生成一個名字叫common的Android Library Module，這時候項目的結構是下面這樣的，你們應該都很熟悉。

一個可運行的app和一個普通的common基本就是這樣結構，咱們上面說了須要把業務模塊進行分離，成爲一個項目，而後還能夠對這個項目的一個模塊進行引用。

接下來咱們單獨爲common建立一個項目，跟SubmoduleStudy同樣的建立，名字叫SubmoduleStudy_common項目，而後包含一個以前同樣的common module。以下圖所示。

SubmoduleStudy裏面的common module能夠刪除了。

仍是同樣的你得把SubmoduleStudy_common用Git管理起來，而後在主工程SubmoduleStudy的根目錄下運行 git submodule add <repository> <path>,記得後面接的是SubmoduleStudy_common的倉庫地址。

完成你就能夠看到以下圖的目錄結構，這樣就能夠把業務模塊項目引進來了。

並且你還會發現多了一個文件.gitmodules。裏面就是關聯了SubmoduleStudy_common。

這個時候打開IDE右邊的Gradle欄就會發現其實整個項目並不能找到SubmoduleStudy_common。

接下來就是重要的一步了，咱們得找到項目根目錄的settings.gradle打開進行對SubmoduleStudy_common下的common進行關聯。

好了，這個時候項目才能識別到這個業務組件。

接下來主項目就能夠對這個業務組件進行依賴了。

咱們暫時先無論SubmoduleStudy_common下的app，咱們對SubmoduleStudy 的 app的dependencies配置上implementation project(":common")這樣就能夠實現依賴了。

在前面的步驟中，當我把SubmoduleStudy_common關聯到主項目的時候，經過觀察IDE右下角的分支那裏還能夠看到 SubmoduleStudy_common也是能夠切換分支的，是否是挺方便的。

---

在SubmoduleStudy_common中有個app，這個app有啥用呢？由於咱們把SubmoduleStudy_common拆分紅一個獨立的模塊，這個app天然用來調試common，也能夠用來寫一些測試common的方法。我通常把他的名字改爲xxx-sample。

須要注意的地方

開始我已經說過，這種作法並不必定適合任何項目，正確的作法仍是經過maven去管理該模塊。

你能夠發現SubmoduleStudy_common這個項目下builde.gradle在SubmoduleStudy項目裏面是沒有任何做用的，目前我還不知道是否能夠配置兩個根builde.gradle，個人直覺告訴我應該是不行的。

因此這就致使SubmoduleStudy_common這個項目的一些builde.gradle上的配置須要放到SubmoduleStudy項目上，包括倉庫配置，gradle版本等等。

源碼地址