前言：

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

需求背景：

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

現狀分析：

只有知道自己問題出在了哪裡？才好尋找解決問題的辦法，我們先來看下目前大部分app的單一專案結構原型。大致如下圖所示：

一眼望去這結構不是挺清晰的麼？每個業務都放在單獨的包名下，網路庫、圖片載入庫等第三方庫與上層業務都完美的剝離了，我們再來看下他們的直接的依賴關係圖：

雖然上面的依賴關係舉例有點太過於極端，但是真實場景中是存在的。各個業務之間程式碼互相引用，所以這種結構也是架構整改的根本動機，也是當務之急應該考慮的事情。為了更好的滿足各個業務的迭代而彼此不受影響，更好的解決上面這種讓人頭疼的依賴關係，開始著手app架構整改。

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

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

業務元件化方向：

APP業務元件化架構整改的方向就是告別結構臃腫的時代，讓各個業務變得相對獨立。模組工程和類庫工程之間遵循向下依賴關係，各個模組之間的遵循平級依賴關係。先看下整改後的各個獨立業務模組與類庫工程之間的向下依賴關係圖：

整改的方向由一個專案工程拆分成若干個模組工程，由app殼工程提供統一的入口，每個業務獨立的模組module共享專案的依賴庫。由殼工程整合需要引入的業務模組，至於各個獨立的業務模組之間的呼叫依賴關係，我們藉助一箇中間層充當路由功能，這個路由我們放在各個業務模組共同引用的依賴庫那一層。由路由統一排程他們之間的依賴關係，路由排程解決平級依賴問題示意圖：

業務元件化大致需要解決以下幾個問題。
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)加快編譯速度，提高開發效率

總結：

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