入職萬表接近兩年，從一入職就進行商城系統全新重構改版，經曆過大半年的封閉式加班，到新商城的重構完成緊接着是新商城的業務完善與拓展。見證了開發團隊一路走來的努力，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元件化架構》
- 流利說開源