Android項目架構之業務組件化

標籤：技術   運行   而且   sdn   使用   android   blog   包名   通訊   

前言：

從個人經曆來說的話，從事APP開發這麼多年來，所接觸的APP的體積變得越來越大，業務的也變得越來越複雜，總來來說只有一句話：這是一個APP臃腫的時代！所以為了告別APP臃腫的時代，讓我們進入一個隨身碟時代，每個業務模組都是一個具備獨立啟動並執行盤，插在哪裡都可以完美運行，這就是推進業務組件的初衷也是一個美好的願景。

需求背景：

隨著公司的快速發展，版本不斷的迭代，業務變得也越來越複雜，業務模組的數量有可能還會繼續增加，而且每個模組的代碼也會越來越多，這樣下去勢必影響開發效率，增加項目的維護成本，每個工程師都要熟悉如此之多的代碼，而且每次編譯如此之多的代碼，電腦卡死了有木有？慢的像蝸牛先生有木有？這樣以來估計工程師直接瘋掉了！然後跳樓Go die 了！所以推進公司業務組件化迫在眉睫，這也是實現業務組件化的大背景。

現狀分析：

只有知道自己問題出在了哪裡？才好尋找解決問題的辦法，我們先來看下目前大部分app的單一項目結構原型。大致如所示： 
 
一眼望去這結構不是挺清晰的嗎？每個業務都放在單獨的包名下，網路程式庫、圖片載入庫等第三方庫與上層業務都完美的剝離了，我們再來看下他們的直接的依賴關係圖： 
 
雖然上面的依賴關係舉例有點太過於極端，但是真實情境中是存在的。各個業務之間代碼互相引用，所以這種結構也是架構整改的根本動機，也是當務之急應該考慮的事情。為了更好的滿足各個業務的迭代而彼此不受影響，更好的解決上面這種讓人頭疼的依賴關係，開始著手app架構整改。

從上面的分析我們可以得出適合業務組件化的幾種情況：

(1)業務較多、而且複雜 
(2)業務之間的依賴需要解耦 
(3)團隊成員較多，需要各自開發相對獨立的業務

業務組件化方向：

APP業務組件化架構整改的方向就是告別結構臃腫的時代，讓各個業務變得相對獨立。模組工程和類庫工程之間遵循向下依賴關係，各個模組之間的遵循平級依賴關係。先看下整改後的各個獨立業務模組與類庫工程之間的向下依賴關係圖： 
 
整改的方向由一個項目工程拆分成若干個模組工程，由app殼工程提供統一的入口，每個業務獨立的模組module共用項目的依賴庫。由殼工程整合需要引入的業務模組，至於各個獨立的業務模組之間的調用依賴關係，我們藉助一個中介層充當路由功能，這個路由我們放在各個業務模組共同引用的依賴庫那一層。由路由統一調度他們之間的依賴關係，路由調度解決平級依賴問題： 
 
通過APP殼工程提供的路由功能，各個模組之間調用不再採用傳統的顯示調用，而是採用隱式調用的方式。從而使各個模組之間不再存在依賴關係。 
APP業務組件化架構整改技術方案：

業務組件化大致需要解決以下幾個問題。 
1.）業務組件的生命週期

按照理想狀態的來看待的話，各個業務組件之間沒有任何依賴關係，這時我們可以把每個獨立的業務組件看成一個可啟動並執行app，所以業務組件的生命週期和應與獨立的app保持一致。 
2.）業務組件之間通訊

在各個單獨業務組件內，基本上保持原來的調用方式，組件之間通訊採用URL Schema方式實現頁面跳轉，格式為 schema://host/action?param1=value1?m2=value2 。關於schema映射表維護由上面提到的Router（路由）這麼一個角色來維護，

schema解析由系統Framework來維護。其中schema映射表可以做成後台設定檔形式。也可以代碼維護，不過組件需要預先註冊。以上說的對於傳遞基本參數是沒啥問題的。如果要傳遞對象的話，轉成Json 字串就可以了。

關於schema可以參考我的這篇部落格：Android業務組件化之URL Schema使用

APP 業務組件化架構整改帶來的好處：

如此規模大的架構整改需要付出更高的成本，還會涉及一些潛在的風險，那麼整改後的架構能夠帶來哪些好處呢？

(1)加快迭代速度，各個業務模組組件更加獨立，不再因為業務耦合情況，在發版時候，由於互相等待而遲遲不能發布版本。

(2)穩定的公用模組採用依賴庫方式，提供給各個業務線使用，減少重複開發和維護工作量。

(3)迭代頻繁的業務模組採用組件方式，各業務線研發可以互不干擾、提升協作效率，並控制產品品質。

(4)為新業務隨時整合提供了基礎，所有業務可上可下，靈活多變。

(5)降低團隊成員熟悉項目的成本，降低項目的維護難度。

(6)加快編譯速度，提高開發效率

總結：

本篇主要來分析為何要實現業務組件化、組件化的方向、組件化的技術方案簡單探討、組件化帶來的好處，由於目前還處於實施初期，很多觀點有可能是錯誤的，很多技術坑還沒涉及，後續會跟進更多相關實現方案。

Android項目架構之業務組件化