個人自用總結的Android模組化架構模板
模板專案連結
如果大家覺得有什麼問題或者建議，歡迎提issue，這個工程我也會不斷改進，雖然比不上大公司、大牛的那些NB架構，但自己不斷學習改進也是一種進步吧。
宣告一下：這個工程只是提供一種架構設計思想，並不像能那些NB框架一樣開箱即用。
Android應用模組化開發說明
1. 元件化與模組化
對於元件化和模組化，我的理解是：
- 元件 ：指的是單一的功能元件，如地圖元件（MapSDK）、支付元件（AnjukePay）、路由元件（Router）等等；
- 模組 ：指的是獨立的業務模組，如新房模組（NewHouseModule）、二手房模組（SecondHouseModule）、即時通訊模組（InstantMessagingModule）等等；模組相對於元件來說粒度更大。
模組化的好處：
- 多團隊並行開發測試；
- 模組間解耦、重用；
- 可單獨編譯打包某一模組，提升開發效率。
本工程採用我認為的"模組化開發"
題外話：我看了很多Android模組化和元件化的文章，還是感覺傻傻分不清楚，我覺得大多數author寫的都差不多是我文中這種結構,所以大多數技術部落格上的模組化和元件化之間並沒有什麼界限。
2. 總體架構圖
架構圖
總體分為三層
- 最底層為BasicLibrary,職責是為上層提供基礎庫支援，基礎庫包含第三方開源庫、元件、自定義的庫和UI控制元件等。
- 中間層為Provider，職責是傳遞給上層基礎庫支援，也為上層的業務模組提供路由引數，公共常量等。
- 最頂層為Business Module，職責是App業務的具體實現，可根據應用的功能模組拆分成若干業務Module。
3. 業務Module分層
業務Module分層
每個業務Module採用MVP分層模式開發，如果業務量小，也可以不採用,直接原始的MVC開發方式也可以。但我覺得如果BaseLibrary的基礎資料請求工具支援的話，每個業務Module隨便用MVC,MVP,MVVM都行，反正Module之間不影響，每個分工人員也可以保留自己的“偏愛”。
3.1 mvp分層具體實現模板
例UserCenterModule（使用者中心模組）
UserCenterModule
mvp
4. 開發模式切換
例如當前工程包含三個業務Module，即UserCenterModule、OneModule和TwoModule
4.1 debug模式
debug模式下，業務module可以單獨編譯為獨立app,相當於一個子工程，與其它業務module解耦，便於專注於業務開發，利於開發人員分工合作，大大加快除錯時程式碼編譯速度。可在工程根目錄的gradle.properties配置，debugXXX=true
org.gradle.jvmargs=-Xmx1536m # UserCenterModule 是否為debug模式 debugUserCenterModule = true #debugUserCenterModule = false # ModuleOne 是否為debug模式 #debugModuleOne = true debugModuleOne = false # ModuleTwo 是否為debug模式 #debugModuleTwo = true debugModuleTwo = false
debug模式
此時OneModule,TwoModule和UserCenterModule都是獨立android application型別module
4.2 release模式
release模式下，業務module會成為library module，為app 殼module提供依賴，所以app殼Module會把需要的業務module集合起來編譯成一個完整的apk
可在工程根目錄的gradle.properties配置，debugXXX=false
org.gradle.jvmargs=-Xmx1536m # UserCenterModule 是否為debug模式 #debugUserCenterModule = true debugUserCenterModule = false # Module1 是否為debug模式 #debugModule1 = true debugModule1 = false # Module2 是否為debug模式 #debugModule2 = true debugModule2 = false
release模式
此時module1,module2和usercenter都是android library型別module,release模式一般在最後整合多業務時聯合除錯時或者要釋出應用時用到。
5. 業務模組間介面跳轉
由於業務模組間已完全解耦，業務模組可獨立開發，所以模組間的介面跳轉不能時直接引用介面類跳轉，需要採用間接跳轉。
Android SDK中intent的間接跳轉API不好用,故採用alibaba的ARouter路由框架。Arouter用法請參考 ARouter
這裡所說的跳轉一般是Activity跳轉，如果是業務Module裡的介面類都是Fragment,那麼可以這樣：
- 業務Module debug模式下，可用一個臨時的Activity用來顯示fragment
- 業務Module release模式，那麼App Module肯定有裝業務Module Fragment的Activity殼，通過Arouter間接獲取到業務Module的Fragment，然後在動態顯示在Activity殼裡。
注意：從debug模式切換到release模式時編譯，ARouter的註解處理器可能一時不會生效（註冊不了路由），請clean一下工程，再編譯。
6. 業務模組間事件通訊
統一採用RxBus事件匯流排方案
7. 依賴庫版本統一處理
專案所用的所有庫及版本號（除測試庫）統一在根目錄下的version.gradle中定義，各module按需對其引用。
例如：BaseLibrary裡的
...
compileSdkVersion build_versions.target_sdk
buildToolsVersion build_versions.build_tools
defaultConfig {
minSdkVersion build_versions.min_sdk
targetSdkVersion build_versions.target_sdk
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
...
dependencies {
...
//rxJava
api deps.rxjava2
api deps.rx_android
api deps.rx_lifecycle
api deps.rx_lifecycle_components
api deps.rx_relay
// net
api deps.retrofit
api deps.okhttp3
api deps.okhttp3_interceptor
api deps.retrofit_converter_gson
api deps.retrofti_adapter_rxjava
...
一些版本號設定
build_versions.min_sdk = 19 build_versions.target_sdk = 28 build_versions.build_tools = "28.0.3"
8. 系統適配
暫時支援設定支援Android系統最低為19（Android4.4）,目標系統版本為28（Android 9.0)
還有很多方面的適配方案就不在這裡介紹了。
9. 編碼規範
具體可以參考 編碼規範 ,下面只是列了幾個重要的。
- 遵循Alibaba編碼規範（可配置阿里編碼規約外掛檢查）
- 類註釋，方法註釋，成員註釋，都要寫上，註釋格式遵循javaDoc
- 編輯完 .java、.xml 等檔案後一定要格式化
- 刪除多餘的 import，減少警告出現，可利用 AS 的 Optimize Imports（Settings -> Keymap -> Optimize Imports）快捷鍵；
命名規範：
UpperCamelCase
10 其他
- 使用此模組的開源專案 ：個人正在完善...
11 改進計劃
- 1 目前業務層網路請求方案是用的RxJava+Retrofit+RxLifeCycle+VP，後期想換個官方的LiveData+Retrofit+ViewModel試試。
12 目前的問題
- 移植不夠高：比如BaseLibrary這個Module，還不夠靈活，如果移植新專案，還是要匯入Module原始碼定製下一些配置後，才能打包成aar為好。
- aar包引入問題，library Module導了自己編譯的aar檔案時,對應的application Module也要導改檔案，除非aar換成遠端依賴導application Module才不用導。對於沒有私人Nexus的使用者來說，很不方便。