萬表商城Android架構演進

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