鍵盤男的部落格地址：

http://www.jianshu.com/users/0ef3dc77079c

2

為什麼要元件化、模組化

專案存在問題

• 程式碼量大，耦合嚴重

• 編譯慢，效率低

• 業務開發分工不明確，開發人員要關心非業務的程式碼

• 改程式碼時，可能會影響其他業務，牽一髮動全身

優點

• 架構更清晰，解耦

• 加快編譯速度

• 業務分工明確，開發人員僅專注與自己的業務

• 提高開發效率

• 元件、業務獨立更新版本，可回滾，持續整合

元件化與模組化

元件、模組，中文字面意思相近，在英文上都可以翻譯為"Module"，加上Android Studio上，library被稱為"Module"，這就不難解釋為什麼我們談到“元件化”、“模組化”，兩者之間的區別相當的模糊。

元件

App工程上所說的 元件，應該翻譯為“Component”，意思是元件、部件、元件。在電子電路中，電子元件是電子電路中的基本元素。在App工程上，元件是構成業務或者功能模組的基本單位。原則上，元件與元件之間互不依賴。

例如，圖片上傳功能，應該叫“圖片上傳元件”，而不是“圖片上傳模組”。因為圖片上傳從功能、業務上，已經不能往下拆了。

圖片上傳可能使用七牛sdk，或者又拍雲sdk。無論圖片上傳元件用七牛sdk，還是又拍雲sdk，都不會影響這個元件的功能，因此元件具有可替換性；同時，圖片上傳元件可以被多個業務使用，因此元件具有可複用性。由於sdk只是技術細節，它跟業務並沒有關係。在業務架構圖上，也不會出現“xx sdk”，因此我們說圖片上傳元件不能拆分了。

同理，日誌功能，叫“日誌元件”，不叫“日誌模組”。

模組

模組翻譯為“Module”，字面意思。模組由多個元件構成，它可以實現一個獨立的功能，甚至業務。

例如，大眾點評的美食功能，是一個業務，可以叫“美食模組”，習慣上叫“美食業務”。它可以拆分更小的模組：搜尋、簽到、評論等。

兩者關係

從上面的闡述可以得出，一個工程，由多個模組組成，每個模組由多個元件構成。但很多時候，兩者界限還是相當模糊。例如“日誌元件”稱為“日誌模組”，也沒有違和感。

• 元件從業務角度上不能繼續拆分，可替換，可複用；

• 模組的定義比較籠統，可以是一個Business業務，可以是技術架構中一個業務，也可以是幾個元件構成的小功能。

無論是元件化還是模組化，目標都是把臃腫的工程，拆分為更小的部分，解耦各種複雜的邏輯，便於程式碼管理。

業務劃分

一個產品的業務，其實是在規劃產品功能，或者做產品原型時，已經定好了（如果連產品或者老闆都沒這概念的話，我們還是算了）；如果後端牛逼的話，他們也會做業務劃分，每個業務部署到獨立的容器、虛擬機器、伺服器。所以，我們做業務劃分時，可以諮詢後端，也可以諮詢產品經理。

例如，大眾點評，首頁已經展示了好多個業務：美食、電影、酒店、休閒娛樂、外賣、機票/火車票..... 這種多業務APP，通常會把業務儘量展示在首頁，這種APP大的業務很好劃分。美食、電影這類看起來完全不同的業務，筆者稱為Business業務。

但並不是這樣劃分就OK了，好像大眾點評這種超級APP，每個Business業務都能分成很多基礎業務。例如，美食業務，可以搜尋商鋪、預約、使用優惠券、點評、簽到等；同時，電影業務也有搜尋、優惠券、點評等。所以，搜尋商鋪、優惠券、點評這種基礎業務，可以獨立出來，被多個Business業務使用。

元件與業務

上文提過，多個元件構成一個模組，當模組相當於業務時，就是說該業務由多個元件組合而成。

還是拿大眾點評做例子，點評基礎業務，釋出點評需要上傳圖片、網路提交、記錄本地日誌等，那麼需要呼叫上傳圖片元件、網路元件、日誌元件等。

不僅僅點評業務呼叫，所有業務都會呼叫這些元件。於是，業務架構如下：

Business業務 -> 基礎業務 -> 各種元件

業務與業務

情景1

場景：在大眾點評訂了酒店，入住之後，開啟該酒店詳情頁，大眾在“推薦列表”給你推薦若干大保健......

情況1：

前端H（負責酒店業務H）：後端D，麻煩給酒店業務單獨做個推薦大保健的api。
後端D（負責大保健業務D）：大保健業務有api D，你呼叫api D吧

前端在酒店業務Module，寫了呼叫api D，功能上線。

=============================================================
過了一段時間，大保健業務做了調整，資料變動、改域名等。

後端D：前端H，api調整了，麻煩呼叫api D改為呼叫api D1。
前端H：現在好忙，我加班搞吧。

於是前端H加班改程式碼，還要做單元測試等一系列工作。

=============================================================
又過了一段時間，大保健業務再次資料變動。

後端D：前端H，api D1改成api D2。
前端H：怎麼又改.....

本來前端H是做酒店業務的，為了大保健的推薦列表，不得不因為大保健業務調整，而加班加點。再延伸一下，如果酒店業務H還需要呼叫電影院列表、美食列表.....每個業務的改動，前端H就呵呵了。

情景2：

當然了，要前端不改動，後端保持原來api D也可以的。只不過，會引發下面對話：

前端H：後端D，不過你一直提供api D給其他業務使用，當資料調整時，api D做好相容我們就不用改了。
後端D：你傻逼啊，相容多麻煩，我們很忙的，你們不就改一點程式碼嗎？我們還要#&^@&#$"@*#......

維護相容/對外開放介面確實是一種解決方法，只不過會加重後端開發、運維的工作量，長期來看並不科學。

情景3：

如果在前端業務與業務在獨立的情況下，也可以相互呼叫，那就簡單多了：

前端H：前端D，麻煩寫一個介面，讓其他前端業務可以請求大保健推薦列表。
前端D（負責大保健業務D），沒問題，你呼叫D類getHealthCare()，就會請求大保健推薦列表，並返回你要的資料了。

=============================================================
過了段時間，大保健資料變動。前端D在前端大保健業務D做了api D->api D1改動，並對D類getHealthCare()做了資料相容，前端H不需要額外改程式碼。

從上面3個情景看，情景3是最優的做法，前端H並不需要跟後端D對接，大保健業務D改動，後端D不需要通知前端H，只需要跟前端D對接即可。而前端的相容工作，比後端相容工作要簡單得多。

業務之間跳轉

業務之間跳轉，這個話題老生常談了。無論是Android、iOS，都是URL Schame跳轉這種解決方案。原因是url不需要任何依賴，而且可傳遞引數。

業務資料互動

無論前端、後端，業務之間資料互動，都是很重要的環節，選用何種合適的方案，就體驗架構師的水平了。

未做業務拆分時，直接呼叫其他業務的程式碼即可：

-資料直接互動，強耦合-

但業務拆分後，就不能直接呼叫程式碼了。兩個業務相互獨立，程式碼互不依賴，必須用某種協議（常用json）用資料。

-間接互動，服務中心做資料中轉-

如果其他業務需要獲取大保健資料，首先大保健業務要註冊大保健服務到服務中心，其他業務才可以通過協議呼叫這個服務。

-業務相互呼叫-服務中心-

如何註冊服務，Android和iOS都有不同的做法，而且方法不止一種。本文僅提供思路，技術細節，會在之後的文章闡述。

其實元件與元件之間，也存在相互呼叫的情況，可參考這種做法。

小結

元件化、拆分業務後：

• 單一職責：開發人員專注於自己的業務

• 依賴倒置：上層業務依賴下層業務，業務依賴元件，業務之間、元件之間不相互依賴

• 介面隔離：業務之間呼叫資料，通過統一的協議與服務中心互動，不呼叫業務實際程式碼

程式碼質量與規範程度明顯提高，高內聚、低耦合。業務職責分明，單元測試也更好寫。如果業務拆分做得好，可以一個業務一個單獨工程編譯，不僅大幅提高編譯速度，而且業務程式碼還可以回滾、版本釋出等。

一切為了更清晰的架構、更乾淨的程式碼^_^