組件化

當(dāng)下安卓的組件化方案可謂是五彩斑斕，為多人大規(guī)模并行開發(fā)帶來的極大的便利，優(yōu)點有以下幾點：
1，最大程度實現(xiàn)代碼復(fù)用；
2，代碼層次清晰，工程結(jié)構(gòu)有條理；
3，提高多人協(xié)作開發(fā)效率；
4，易擴(kuò)展，降低耦合；
但是要實現(xiàn)組件化基本有以下要求：
1，代碼解耦，將一個大工程進(jìn)行合理拆分成一個個獨立的組件；
2，組件的單獨運行與調(diào)試，每一個組件都可以做到單獨運行和調(diào)試；
3，組件通信，組件之間的數(shù)據(jù)通信，UI跳轉(zhuǎn)等；
4，代碼和資源的隔離，將每個組件中的邏輯功能實現(xiàn)代碼和資源進(jìn)行完全隔離開；

代碼解耦

要實現(xiàn)代碼解耦，需要對現(xiàn)有業(yè)務(wù)有一個完成的輪廓，現(xiàn)有組件化方案基本都會把結(jié)構(gòu)大致分為幾個大的層次：app殼，業(yè)務(wù)組件，功能組件。
app殼：該層主要對組件進(jìn)行組合打包apk等邏輯；
業(yè)務(wù)組件（縱向）：該層主要是對應(yīng)和應(yīng)用強(qiáng)相關(guān)的一些業(yè)務(wù)邏輯實現(xiàn)和處理，比如一些登錄組件，消息組件，訂單組件，個人信息組件等等，是和應(yīng)用具有強(qiáng)依賴關(guān)系的組件；
功能組件（橫向）：該層次基本都是一些脫離具體業(yè)務(wù)，側(cè)重某一向功能的組件，比如網(wǎng)絡(luò)，日志打點，消息推送，分享，支付等等，都是一個通用的功能組件，不限于某一個app，強(qiáng)調(diào)的是實現(xiàn)某一功能；
所以，從以上可以看出，功能組件是基礎(chǔ)，如果一個公司具備完善的功能組件，那么它就會有快速構(gòu)建app的能力，業(yè)務(wù)組件基本都是依賴于需求的，脫離了需求，業(yè)務(wù)組件的價值就得不到體現(xiàn)，但是具體該怎樣拆分，還需要對整個業(yè)務(wù)非常熟悉；app殼屬于最上層，對業(yè)務(wù)組件進(jìn)行選擇性打包，具體是否需要某一個業(yè)務(wù)組件取決于當(dāng)前的公司需求是否需要。當(dāng)然功能組件基本都會有許多開源的框架可供選擇，并不需要我們從零開始，但是，對于一個更成熟的公司，要高瞻遠(yuǎn)矚，因為技術(shù)在不斷更新，就拿網(wǎng)絡(luò)庫來說，從android-async-http，volley,okhttp,retrofit,同樣是網(wǎng)絡(luò)庫，可能公司不同部門會選用不同的網(wǎng)絡(luò)庫，如果某一天需要將多個app打造成聚合app，進(jìn)行合并，那將是非常痛苦的，所以，最好的方式是公司實現(xiàn)一套自己的一套網(wǎng)絡(luò)接口功能組件，具體實現(xiàn)對外屏蔽，只暴露接口，這樣，可以方便的進(jìn)行管理，也為后期解除的后患。

組件的單獨運行與調(diào)試

拆分的組件如果不能單獨的運行和調(diào)試，豈不是很痛苦，所以，讓每個組件可以單獨運行和調(diào)試非常重要，當(dāng)然現(xiàn)有的一些組件化方案已經(jīng)給了很好的實現(xiàn)方案，不必多說。但是組件的調(diào)試又分為組件內(nèi)部調(diào)試，和組件之間聯(lián)調(diào)，內(nèi)部調(diào)試更好處理一些，我們只要能夠處理好組件從application到libray的轉(zhuǎn)換即可，當(dāng)然調(diào)試的時候我們會需要自己的啟動入口Activity，application等，或者是一些調(diào)試的類，一個更好的處理方式是我們可以借助微信pins工程的思想，將我們需要調(diào)試的代碼和資源單獨出來，通過sourceset去動態(tài)設(shè)置是否需要將調(diào)試代碼和資源進(jìn)行編譯；當(dāng)組件作為library時我們又可以將調(diào)試的代碼和資源隔離開；組件之間聯(lián)調(diào)可能會顯得比較麻煩一些，一個可行的辦法就是借助app殼工程，將必要的組件進(jìn)行打包，但是一個組件的運行可能還會涉及到登錄態(tài)等一些限制，所以這些都需要提前準(zhǔn)備好。

組件通信

為了實現(xiàn)組件之間的通信，現(xiàn)在基本都會采取路由的方式實現(xiàn)UI的跳轉(zhuǎn)，不管哪種路由，適用自己就好，組件之間的數(shù)據(jù)通信，也有很多通用的消息通信框架，或者是接口+數(shù)據(jù)結(jié)構(gòu)，但是這里有一個問題就是，比如組件A依賴組件B的服務(wù)，依賴B的某個類，通常都是將接口或數(shù)據(jù)結(jié)構(gòu)下沉到基礎(chǔ)庫或者公共庫里面，到后期必然會造成基礎(chǔ)庫爆炸式增長，許多類過度集中到基礎(chǔ)庫中的問題會越來越嚴(yán)重，那么如何才能夠避免這種情況，讓基礎(chǔ)庫去中心化呢？Android組件化方案及組件消息總線modular-event實戰(zhàn)給了一個比較好的實現(xiàn)方案，每個業(yè)務(wù)組件都劃分成了Export Module+Implement Module的模式，將接口和實現(xiàn)完全隔離開，感覺思路很不錯，當(dāng)然如果你覺得這種做法比較隔離級別比較重，那么我們也可以通過微信p工程一樣去進(jìn)行隔離，我們發(fā)布兩個版本，一個是Export版本，對外提供接口和數(shù)據(jù)結(jié)構(gòu)讓別人可以依賴，在發(fā)布一個Implement 版本，進(jìn)行具體的實現(xiàn)邏輯。當(dāng)然我們也可以借助ServiceLoader的思想將所有接口和實現(xiàn)類進(jìn)行配置，為了降低所依賴的數(shù)據(jù)結(jié)構(gòu)類的數(shù)量，最好的方式是我們可以使用android特有的message，bundle或者是一些集合類等進(jìn)行一些簡單參數(shù)數(shù)據(jù)的傳遞。

代碼和資源的隔離

在對基礎(chǔ)庫中去中心化的過程中，我們通過只依賴其他的接口和數(shù)據(jù)結(jié)構(gòu)已經(jīng)很好的隔離了代碼，但是對于資源來說還有一些問題就是資源沖突，為了規(guī)避資源沖突，我們可以在命名上進(jìn)行一些約定，比如所有資源文件以module名開頭