優秀框架源碼分析系列（一）讓解耦更輕鬆！多進程組件化框架-ModularizationArchitecture

寫在前面

今天開始，我將陸續推出一系列的Android相關的優秀開源項目源碼分析系列文章，每一期選取一個框架來進行分析解構。幫助你們更好的瞭解優秀框架的設計思想。分析的方式會選擇從源碼自己進行討論，學習其設計思想，取長補短，每個設計都有它值得學習的地方，你們各取所需，我相信，不管是成功的經驗，仍是失敗的教訓，都是同樣有價值的。

ModularizationArchitecture概述

ModularizationArchitecture是一套Android完全組件化框架。它主要提供瞭如下幾個功能：

• 進程間，進程內組件間的路由通訊機制
• 進程間，進程內組件行爲功能的封裝機制
• 組件的加載（初始化）、卸載機制
• 提供組件化核心基類

工程結構

• macore：組件化核心庫
• maindemo：主程序（Host）
• musicdemo：播放器組件
• picdemo：圖片組件
• webdemo：網頁組件

組件的框架

每一個獨立進程的組件，均需包含以下幾個部分：

• Logic：組件的生命週期抽象模板，至關於組件的Application類
• Provider：一組組件行爲的抽象，其內部包含一組Action。
• Action：組件行爲，即對外提供的服務項（或稱爲最小粒度的功能點）
• RouterConnectService：多進程時，組件的守護服務

若是是非獨立進程的組件，則只需包含以下幾個部分：

• Logic：同上
• Provider：同上
• Action：同上

組件化內核之macore

macore提供了框架基礎，爲組件化提供基礎功能。

組件間通訊機制

組件間通訊採用了C/S架構，跨進程通訊採用了Binder調用。其核心是經過LocalRouter和WideRouter兩個類來實現。

路由器（LocalRouter、WideRouter）

本地組件間通訊經過LocalRouter來完成，進程間組件通訊是經過WideRouter來完成。若是是跨進程模式，WideRouter則獨自運行在一個路由進程中。查看macore中的MaApplication.java中的startWideRouter()方法和AndroidManifest.xml不難發現，macore運行後會建立一個com.spiny.ma.widerouter的進程。

這裏分別給出LocalRouter和WideRouter中route方法的邏輯圖，以便更好的理解。

LocalRouter.route()

WideRouter.route()

路由器守護服務（LocalRouterConnectService、WideRouterConnectService）

路由器守護服務用來實現LocalRouter和WideRouter的雙向互聯。

LocalRouter做爲組件的路由，既負責向WideRouter發送組件內部的跨進程調用，又負責接收來自WideRouter的跨進程調用。當其負責接收外部調用時，是做爲C/S架構中的Service存在的，因此這個服務經過LocalRouterConnectService來提供。WideRouter經過LocalRouterConnectService向該組件發送請求，它是組件向外界提供能力的橋樑。

正如剛纔說到的，WideRouter自己提供的對外功能就是爲各個組件中轉請求，實際上，它提供的就是一種路由服務，從這個層面上來說，它也是一個組件。因此它也須要一個Service向外提供服務，即WideRouterConnectService，其它的LocalRouter經過鏈接到這個服務，與WideRouter創建通訊通道。

在多應用多產品開發場景日益廣泛的今天，在多個應用內同時引入ma框架，由多個WideRouter組成更大的組件化網絡，也不失爲一種策略。尤爲是當咱們要對產品進行平臺化演進時，將衆多的基礎功能服務以一個App的形式提供出去，暴露多種服務供其餘應用調用的時候，組件化思想會爲多模塊，多應用並行開發提供可能。

組件生命週期

組件生命週期管理器（BaseApplicationLogic）

設計了一個包含相似Application同樣的生命週期管理類，每個組件都實現一個這樣的生命週期管理類，負責處理組件自己的初始化和去初始化動做。使用組件時，將這個生命週期類與應用的Application類進行綁定，這樣組件的生命週期就和應用的生命週期綁定了。

組件其餘輔助類

Wrapper

• PriorityLogicWrapper：在多組件的生命週期管理上，組件的加載可能須要維護必定的順序以保證邏輯的正確性。PriorityLogicWrapper對管理器進行了包裝，增長了一個優先級屬性，這樣，程序員只須要在最開始指定好優先級，就不用擔憂在後續的維護過程當中因過失而使初始化失序。

• ConnectServiceWrapper：承載繼承自LocalRouterConnectService的類。全部組件中實現的LocalRouterConnectService擴展類，都將在macore組件中被ConnectServiceWrapper包裝起來。可能就是爲了寫起來方便吧。

Action、Provider

• MaAction：全部Action的基類。組件能夠經過繼承它實現本身對外提供的服務。
• MaProvider：全部Provider的基類。
• MaActionResult：服務調用在組件間傳遞的返回的結果類。
• ErrorAction：當請求的服務不存在或不可用時，默認返回的錯誤。

RouterRequest、RouterResponse

• RouterRequest：由調用方建立的，服務調用的請求封裝類。其內部實現了相似消息池同樣的數組。以保證對象建立更高效。
• RouterResponse：對調用結果的包裝類，承載了調用的返回狀況。其中包含了字符串化的MaActionResult。

MaApplication

擴展自Application的類，將組件化框架的基礎組件初始化框架封裝在其中。這樣，框架的使用者無需關心框架的初始化細節，而只須要關注組件自己的生命週期便可。

主程序（Host）實現

Host是整個應用的Application實現部分，其餘組件都是以Library的方式存在的。Host負責對其餘組件進行註冊，並將應用的生命週期和macore進行綁定。這些都在MyApplication中實現。

@Override
public void initializeAllProcessRouter() {
     WideRouter.registerLocalRouter("com.spinytech.maindemo",MainRouterConnectService.class);
        WideRouter.registerLocalRouter("com.spinytech.maindemo:music",MusicRouterConnectService.class);
        WideRouter.registerLocalRouter("com.spinytech.maindemo:pic",PicRouterConnectService.class);
}

@Override
protected void initializeLogic() {
        registerApplicationLogic("com.spinytech.maindemo",999, MainApplicationLogic.class);
        registerApplicationLogic("com.spinytech.maindemo",998, WebApplicationLogic.class);
        registerApplicationLogic("com.spinytech.maindemo:music",999, MusicApplicationLogic.class);
        registerApplicationLogic("com.spinytech.maindemo:pic",999, PicApplicationLogic.class);
}

@Override
public boolean needMultipleProcess() {
    return true;
}
複製代碼

Host同時也是一個組件，其對外也一樣提供服務。因此，它也對應實現了Logic,Provider以及一系列Action。因爲開啓了多進程模式，因此也實現了RouterConnectService，它擴展自LocalRouterConnectService。

其餘組件

工程下還包含了其餘幾個示例組件：musicdemo、picdemo、webdemo。

其中musicdemo和picdemo均爲單獨運行在一個進程中的組件，而webdemo與maindemo運行在一個進程中。當咱們須要新開發某個組件的時候，只須要按組件的實際功能實現Action、Provider以及Logic便可。若是是跨進程組件，還須要擴展實現LocalRouterConnectService。

總結

組件化提出已經好久了，它能夠從不少方面解決咱們實際項目開發中的問題，不管是技術上的實現問題，仍是人員組織結構和項目分工上，都提供了很好的方式。換句話說，由於在架構上解決了耦合問題，使得項目開發的組織上也能夠很輕鬆的實現解耦，不失爲一箭雙鵰。在此，咱們再重複一下組件化框架解決的幾大問題：

• 代碼解耦
• 代碼隔離（可見性）
• 組件（功能模塊）單獨調試
• 集成調試
• 組件（功能模塊）生命週期管理
• 組件間數據通訊

源碼地址

下面是項目的源碼地址：

ModularizationArchitecture源碼

我讀了一遍後，作了些簡單的Bug修復，下面這個是我fork後的地址：

修改後的ModularizationArchitecture

最後，感謝Spiny Wang的優秀開源框架

題目徵集

你們有想了解的優秀框架，也能夠私信我。我會篩選關注度高的框架進行解讀。感謝你們的關注和支持！

小銘出品，必屬精品

歡迎關注xNPE技術論壇，更多原創乾貨每日推送。