入職萬表接近兩年，從一入職就進行商城系統全新重構改版，經歷過大半年的封閉式加班，到新商城的重構完成緊接著是新商城的業務完善與擴充。見證了開發團隊一路走來的努力，Android團隊也在自己的想法中向前邁進。
前言
在公司的發展方向上，從以前單一的萬表商城App,延伸到服務類的萬表名匠App、資訊類的萬表世界App等多個還在孵化的專案，讓我察覺到了萬表商城App作為主流量入口，將來一定程度上會集合萬表名匠、萬表世界到主專案中，所以元件化必然是正確的演進方向。在專案gradle升級到3.x後，依賴隔離的新特性更是幫助我對元件化的推進工作。另外不得不吐槽自己對專案的gradle3.x的更新經歷，雖然gradle3.x的升級佈滿著深坑，但是自己竟然在從2.3.3升到3.1.4足足花了4個多月的時間，一方面專案需求任務繁重，每次升級都是在發包後到新一個開發任務的夾縫中進行，然後在gradle3.0.x泥潭上無法自拔，再到gradle3.1.4的release包啟動閃退問題提示一直無法準確定位，終於自己在不斷試錯下在External Libraries翻原始碼發現是某一個第三方的原始碼引起的問題，當成功升級解決問題後，發現自己幾度放棄的問題答案，原來一直躺在轉彎處，心疼自己。
元件化優點
在現在的大環境下元件化的優點相信大家都比較熟悉。
- 高內聚，低耦合，程式碼邊界清晰，每一個元件都可以拆分出來獨立執行
- 功能集中，每一個元件負責屬於自己元件的工作，不受其他元件影響也不影響其他元件功能
- 提高開發效率，每個元件可單獨除錯，保證程式碼質量
- 減少重複造輪子和維護工作量
- 加快編譯速度，最理想的情況是，App工程僅僅是一個空殼，用於載入各個元件
競品對比
對於一個商城專案，我們經常會對競品進行研究。下面我們來看看競品的首頁專案結構。
畢竟這裡只是是首頁的package結構，我們不好推測，但是我們還是能看出不少東西來的。
現狀
在以前的程式碼風格是喜歡封裝一個工具類庫，將非業務性的程式碼放在單獨的庫中管理維護，我司也一樣，同樣有一個內部維護的toolkit庫，但是這種方式不再適用於不斷擴充業務線、建立公司生態圈的，如上面所述，我們的服務類App、資訊類App並不適用商城App所封裝的工具類庫，因此元件化能幫助我們將業務Module與工具Library不斷細化，從而達到我們複用的目的。
另外現在很多專案都是流行MVP模式，我司也一樣。MVP的封裝方向在一定程度上都存在著不少的差異性。下面我們來看看樣例。
我們可以看到舊的MVP寫法是將所有的Activity.class都放在同一個package，這種寫法是因為思想從MVC轉變到MVP中，以前MVC我們或多或少都是這樣幹過，而在不斷的實踐中改進，右邊的MVP模式更為適合我們，我們將用功能模組作為粒度，將每一個模組分開，這就是我們所說的模組化，現在我司專案就是完全按照模組化來開發，每一個功能模組都十分清晰，但是帶來的弊端就是程式碼量會較大。
可能有部分同學對元件化和模組化的理解還是比較模糊。我們通過比喻來理解比較容易區分。元件化它們相互獨立，每一個元件都能單獨抽出來進行執行，而模組化是按照功能模組的搭建，模組化間都存在一定的關係和聯絡。如商城首頁模組和文章模組都有視訊播放的功能，這時的視訊播放就出現來耦合情況，此時元件化就很好處理，我們將視訊播放單獨處理成一個元件，讓首頁模組與文章模組來呼叫同一個視訊播放元件。所以說元件化比模組化的粒度更小。
元件化方案
現在GitHub上面流行著各大家公司開源的路由庫，他們基本採用元件化的方案是
這個是比較通用元件化的一個方式，當然不同廠有著會根據自己的實際情況進行改造流程，但是基本大同小異，我們五花八門討論得最多的是不同業務元件的路由通訊協議封裝，我們將一個個業務元件細化拆分，不可能最後是互相直接依賴使用導致各種混亂和耦合，我們此時需要的是路由，它幫我們管理各業務元件間有序地通訊，路由重點劃一下:事件分發和動態攔截。
在參考前面的競品，結合公司的組織架構，對自己商城App分析定製。我第一期元件化的工作方向是功能模組化與業務元件化相結合。這是因為我們專案是一直遵循著模組化，對功能的整理比較好，我這邊不對每一個業務進行拆分元件化，也就是不採用現很熱門的路由通訊方式，因為如果我將專案弄成完全元件化，是過度封裝了，導致開發成本不協調，然而目前我們首要處理的問題是業務元件複用問題，所以避免我們另外兩款App重複造輪子，我們先將諮詢元件、支付元件、定位元件、網路請求元件、推送元件進行分離，同時優化封裝圖片載入庫、普通工具庫、Banner工具庫、友盟第三方庫、圖片選擇庫、JSBridge庫等非業務性的基礎庫。
總結
元件化的推進工作，從簡單的分離程式碼，裡面幫助我們更好地梳理了陳舊程式碼，及時整理好wiki。到享受程式導向、物件導向、面向介面、面向切面的程式設計樂趣。
展望
到了最後，這次商城元件化構架演進，只是一個開始，就如一開始所說的，將來會有一天多款App會進行整合，我個人推薦的是通過外掛化的方式載入對應的業務模組，在前段時間官方所推出的動態化框架Android App Bundles更適合未來的發展。另外在未來大前端完全介入商城日常開發，架構還會繼續進行調整。以上是我的簡單總結和對模組化的一些嘗試，不足之處還望大家交流指正。
參考資料：
- 蒼王的《Android元件化架構》
- 流利說開源