我的Github：https://github.com/BzCoder
最近準(zhǔn)備對(duì)Android項(xiàng)目的組件化改造寫一個(gè)系列心得，同時(shí)也對(duì)本輪學(xué)習(xí)的一次記錄，會(huì)盡量寫的細(xì)一點(diǎn)，也是對(duì)知識(shí)的鞏固。
尤其要感謝@JessYan大神的ArmsComponet框架。
在本章中不談具體代碼，只談總體思路。歡迎各位在簡(jiǎn)書下留言。
前言
去年熟悉了一整個(gè)SpringBoot，SpringCloud生態(tài)，說實(shí)在很多后臺(tái)開發(fā)的思想是值得Android開發(fā)借鑒的（AOP，IOC，編程的思想），受益匪淺。
這段時(shí)間公司里提出要將原有APP進(jìn)行組件化改造，以適應(yīng)之后更加豐富的需求以及代碼的解耦和多app的模塊復(fù)用。其實(shí)后臺(tái)模塊化開發(fā)已經(jīng)實(shí)現(xiàn)了很久，加上后臺(tái)開發(fā)有注冊(cè)中心的概念，模塊管理十分靈活。當(dāng)然Android開發(fā)依舊可以借鑒后臺(tái)的開發(fā)模式。我作為公司的老安卓，自然挑起了這個(gè)擔(dān)子，加上外包團(tuán)隊(duì)，一共組成了一個(gè)六人的安卓小團(tuán)隊(duì)，對(duì)APP進(jìn)行組件化重構(gòu)。
本次組件化改造的終極目標(biāo)：
- 分離業(yè)務(wù)模塊，減少不必要的耦合，方便模塊的拆卸增減。
- 獨(dú)立模塊單獨(dú)編譯，無(wú)需每次編譯都全量打包，方便開發(fā)人員的開發(fā)。
- 通過后臺(tái)配置一鍵生成APP（Git + Jenkins持續(xù)集成）。
- 實(shí)現(xiàn)同一個(gè)項(xiàng)目多應(yīng)用差異化打包。
組件化開發(fā)相比原來的All in One模式，要考慮多方面的問題，我主要羅列了以下幾點(diǎn)：
組件化主要需要解決的問題：
- gradle與manifest的管理
- 模塊之間的分層邊界
- 模塊間的通訊與調(diào)用
- 各個(gè)模塊的個(gè)性化配置
- 各個(gè)模塊的生命周期
- 不同模塊的屏幕適配
需要學(xué)習(xí)的第三方框架原理和工具
在接下來的章節(jié)中我們來仔細(xì)分析如何解決這些問題。
項(xiàng)目架構(gòu)
使用的基礎(chǔ)架構(gòu)是基于@JessYan大神的ArmsComponet框架，并在此框架上做出相應(yīng)的優(yōu)化與改造。
總體分層
總體分層基本采用@JessYan的分層方式，大體分為三層。外加CommonService層來統(tǒng)一管理模塊之間調(diào)用。
宿主層
APP殼文件，最后打包層，通過統(tǒng)一配置文件（gradle.properties），決定最后app的包名，定義主界面樣式風(fēng)格，模塊的最終引入。
業(yè)務(wù)層
各個(gè)實(shí)際業(yè)務(wù)，業(yè)務(wù)層根據(jù)實(shí)際邏輯結(jié)構(gòu)繼續(xù)分層，我根據(jù)現(xiàn)有的項(xiàng)目是分了三層。當(dāng)然我們可以根據(jù)業(yè)務(wù)量級(jí)繼續(xù)分層。這個(gè)分層主要是為了方便調(diào)試（Application與Library的切換）。在具體實(shí)際開發(fā)中，有時(shí)候需要對(duì)模塊進(jìn)行單獨(dú)調(diào)整，實(shí)際開發(fā)中，甚至有些模塊是互相循環(huán)調(diào)用的，我們還需要整體調(diào)試。以下僅供參考，實(shí)際情況以開發(fā)為準(zhǔn)。
- 第一層：被APP層直接調(diào)用，較大的模塊，功能較為完整的模塊。
- 第二層：一般為第一層業(yè)務(wù)模塊跳轉(zhuǎn)的頁(yè)面。
- 第三層：底層頁(yè)面，一般為詳情頁(yè)，不會(huì)有下一級(jí)跳轉(zhuǎn)。
每個(gè)業(yè)務(wù)層一般情況下都使用基礎(chǔ)層提供的基礎(chǔ)組件，但是也允許有相應(yīng)的自己的網(wǎng)絡(luò)請(qǐng)求配置，圖片請(qǐng)求框架，甚至基礎(chǔ)控件框架，以做到模塊的解耦以及從別的APP中遷移過來模塊的加入。
基礎(chǔ)層
包含了各種基礎(chǔ)服務(wù)，除了簡(jiǎn)單的工具類，通用自定義組件，一般情況都建議以遠(yuǎn)程調(diào)用模式引入，基礎(chǔ)層（CommonSDK）不要引入過多的東西，有以下幾個(gè)原因：
- 加快工程的編譯速度 。
- 減少基礎(chǔ)層的代碼量 。
- 自定義組件專人維護(hù)，責(zé)任到人，因?yàn)榭偸怯幸恍┤擞X得自己能優(yōu)化別人寫的庫(kù)，于是亂改。。。同時(shí)有利于開源，讓更多的人使用才能優(yōu)化組件。
- 有利于在其他工程中快速?gòu)?fù)用以及在本地Lib的刪減升級(jí)。
Service層
這個(gè)是很關(guān)鍵的一個(gè)層，相當(dāng)于Bridge角色。它定義各個(gè)模塊接口，以實(shí)現(xiàn)模塊之間的互相調(diào)用，每個(gè)模塊對(duì)外暴露的方法，都必須注冊(cè)在Service中。我們盡量保持模塊對(duì)外接的輸入?yún)?shù)的最小化。這樣某一個(gè)模塊從V1升級(jí)至V2，其他模塊保持對(duì)外部接口調(diào)用不變，我們就可以迅速的對(duì)模塊進(jìn)行V1到V2的升級(jí)。做到最大程度的解耦。
資源層
包含了APP的個(gè)性資源文件，包括顏色，字體，圖片資源文件等非共用資源?？梢酝ㄟ^CommonRes來引用，以方便不同APP的Res的文件切換。
項(xiàng)目配置
我們將大多數(shù)的項(xiàng)目配置相關(guān)的屬性都轉(zhuǎn)移到gradle.properties文件當(dāng)中，以完成對(duì)工程的統(tǒng)一管理。其中包含各種廠商Key，各個(gè)模式都是引入的標(biāo)志位，應(yīng)用的包名，應(yīng)用的版本號(hào)。
那么有關(guān)于Android組件化改造的總體架構(gòu)分塊就先介紹到這里，歡迎大家討論。
