模組化和業務元件化
在終端開發中常常會因為專案的複雜度越來越高，而需要不斷對業務做劃分和分組，在Android中稱為模組化，模組化的意義在於不斷對專案做業務和程式碼層面的分離，從而最終做到業務的隔離和程式碼的複用，這種思想在其它平臺也有所體現，例如WEB的前後端分離。在Android中一般來說，最終模組後架構大體如下：
其中上層可以依賴下層，業務模組之前不能相互依賴。這樣做的好處在於：
- 因為業務模組不能依賴，所以業務之間理論上是隔離的，每一個業務只需要少部分人維護即可。
- 新人上手容易，只需要理解當前業務模組即可。
- 出現問題可控，修改程式碼只會影響當前模組。
- 對於大型APP來說，多個部門的APP程式碼可以分成多個git庫管理，各個部門單獨管理自己的程式碼，在打包的時候合併在一起即可。
當然，模組化的構建過程中會遇到一些問題，個人在實踐過程中，遇到的最大的兩個問題：
- 業務的劃分。這是非技術問題，如何對業務做精準的劃分，這涉及到產品層面和公司戰略層面了。總而言之，模組化構建應當是服務於公司業務和部門業務的。
- 模組之間如何通訊。雖然做了業務上的劃分，但是無論無何也會存在業務模組之間進行相互耦合的情況，比如隸屬於賬戶模組的授權系統可能會被其它模組所呼叫，並且返回資料。
第一個問題屬於業務問題，需要專案負責人根據公司現狀去做決策。第二問題在業界其實都有比較好的解決辦法，模組化實踐最好的莫過於微信了，微信Android模組化架構重構實踐這篇文章對於第二個問題有自己的解決辦法（lib的方式）。對於部門隔離要求不那麼嚴格專案來說，這個解決方案也不失為一種好的方式。
上面聊的都是模組化，業務元件化其實是屬於模組化的一種細分，模塊化是從大的業務層級來進行梳理和程式碼隔離的，而業務元件化注重的是UI層面的元件化，但是又比UI元件更加粗粒度，業務元件化就像是搭積木，積木就是這個元件。可以想象也一個頁面由產品列表、購買按鈕組成，其中，產品列表和購買按鈕就是一個元件，購買按鈕不僅僅是一個按鈕，它包含整個購買邏輯：
- 購買產品資訊的輸入和結算
- 購買流程的處理
- 資料的返回和異常情況的處理
本質上來看，對於終端來說，所謂的業務元件化其實就是一個繫結了特定業務的UI元件，這個UI元件可以針對很多類似場景進行資料的輸入和輸出，並處理特定的業務。
這樣做優點是顯而易見的
- 通過預先定好的元件，開發工作量大量減少。
- 可配置性強，甚至可以讓服務端通過下發配置動態生成頁面。
業務元件化的難點
Android業務元件化在技術方面來講，其實和其它專案元件化沒有本質化的不同，其它元件化需要考慮到問題都需要考慮：
- 多業務元件的管理，元件管理器。
- 業務層的管理和定義，業務層。
- 元件間的通訊機制，通訊層。
- 基層UI元件的定義，UI層。
根據上面思路，粗略畫了一個圖
為了防止元件的耦合需要設計一個元件之間的通訊機制，這個通訊模組設計原理和模組化的通訊類似。個人認為這種元件化設計其實是不難的，只需要在設計的時候考慮多複用和易用性即可。
那麼，業務元件化最難的是什麼呢？
個人認為業務元件化，到了編碼階段其實是不難的，真正難的是在於編碼之前的階段：
產品經理如何定義業務元件？
設計師如何規範統一風格業務元件？
這兩個問題，考驗的是整個專案的的統一協調能力，考驗的是整個專案的規劃性和整個公司戰略方向。
產品經理如何定義好一個業務元件？
- 考慮這是一個業務元件嗎？
- 這個後期需要複用或者更改嗎？
- 需要預先定義好哪些可能的變化?
- 整個專案類似的功能能夠保持一致性嗎？
這些問題和技術無關，和產品思路和公司整體戰略有關，非產品和技術負責人不能推動。
設計師如何定義一套風格類似的元件？
- 整個專案有標準的UI規範嗎？
- 如何讓每個設計師能夠設計出風格一致的設計？
- 技術如何能夠遵守這個設計規範，並形成通用型UI元件？
考慮一個登陸授權元件，一般來說可能流程是這樣的：
使用者點選頁面上的某個登陸按鈕-》按鈕跳轉到一個授權登陸頁面-》使用者輸入授權資訊-》根據使用者的授權資訊，通過伺服器去驗證-》返回授權結果。
其中，設計師可能需要考慮：
- 登陸授權按鈕風格是否是固定的，是否需要排除到業務元件外面？
- 授權頁面是否整個專案公用？設計風格是否不同頁面會發生變化？
- 在整個元件進行過程中，異常情況如何提示給使用者？如何做出風格一致的反饋和設計？
產品經理考慮可能：
- 這個授權系統是否需要產品複用？
- 不同使用者型別授權方式是否需要預先留好介面？
- 統一的風格是否符合產品意圖？
- 異常情況下如何處理？
整個過程如果沒有溝通清楚就會導致整個業務元件的定義失敗。登陸授權還是簡單的業務，如果遇到類似於支付寶這種複雜業務的產品，就需要在開發產品前考慮到這些問題。
從技術層面來說，越早定義好業務元件，實現就越簡單，在業務還沒有鋪開、程式碼複雜度越低的時候實現就越簡單。因此，業務元件化應當是一個持續的過程，特別是對於一個快速迭代的專案來說，業務元件化應當貫穿整個產品的所有開發過程。
總結
業務元件化非常難以推行，往往不是因為技術方面的問題，大都是因為產品層面導致的。當然，一個有權威、瞭解產品負責人進行業務元件化跨部門推進也是非常關鍵的，因此，如果你想推行業務元件化，那就先從產品層面梳理專案，並選一個靠譜、有權威的負責人來推進吧！