http://www.infoq.com/cn/articles/suning-android-architecture

摘要

一個電商類APP，對用戶而言，是琳瑯滿目的商品，是層出不窮的優惠，既是社交導購，更是交易售后；而對于開發者來說，用戶行為的背后，或許僅僅是一次次數據的存儲、處理、傳輸和展示。

在蘇寧易購android客戶端不斷發展的過程中，也出現了許多的問題：

• 如何高效、安全的處理數據流向的各個環節？
• 如何規避軟件升級、硬件差異、網絡環境等攜帶的風險？
• 如何合理的解決產品快速迭代和開發應接不暇之間的矛盾？
• 如果最大限度的提高開發效率，降低開發、管理和運營的成本？
• ......

有問題，就有對應的技術方案，就需要合理的架構去支撐。

本文將根據移動發展各個階段的時代特點，結合移動電商app業務的特質，以移動數據交互全景的視角，講述蘇寧易購android客戶端在不同階段出現的問題，采取的技術應對方案，以及如何衍生出最終的android運行架構。

移動青銅時代（2012-2014）

時代特點：

• 移動特征，2G~3G網絡為主，數據傳輸效率低，電商類APP用戶的活躍性低；
• 發布模式，傳統的軟件生命周期，需求收集、評審 → 測試案例生成、評審 → 開發設計、編碼、評審 → 測試 → 發布 → 運營，單團隊單線發布；
• Android生態，Android 2.0~3.0，行業內都處于探索階段，技術交流少，多以系統API為主；開發工具Eclipse。

APP業務特征：

• 業務系統，以PC業務為主，沒有針對移動業務數據的API，需要單獨研發一個數據中轉系統，以保持移動業務的正常運轉；
• 產品邏輯，展示、交互簡潔，業務復雜度低，以商品的搜索、展示、購買等核心流程為主；

移動應用數據交互全景：

研發過程中的問題：

由于業務邏輯簡單，頁面展示、交互的復雜低，通過Android原生的Activity+WebView即可以滿足絕大部分的產品需求；需求、開發、測試、發布、運營都在正常的版本周期內有條不紊的進行著；在Android發展初期，最主要的問題就是：

如何提高開發者的編碼質量。

技術應對方案：

資深人力資源對核心技術進行封裝，高內聚，低耦合；以最精簡的API對外，降低使用復雜度，讓開發人員專心于業務邏輯的研發。

應用架構生成：

采用最基本的軟件設計理念，即分層 + 解耦：

• 分層，數據流轉處理采用責任鏈模式，保證各個環節的邏輯清晰明了；
• 解耦，各層之間添加標準的API代理，確保被依賴層可以正常的維護、升級。

移動白銀時代（2014-2016）

時代特點：

• 移動特征，3G~4G網絡為主，數據傳輸效率高，高效便捷的購物體驗，讓手機購物成為了主流；
• 發布模式，單線已經無法滿足各條產品線的快速迭代，敏捷開發應運而生，多團隊多線發布；
• Android生態，Android 4.0~5.0，移動技術交流百花齊放，插件化、熱修復、APK加固等黑科技如虎添翼；開發工具Eclipse → Android Studio。

APP業務特征：

• 業務系統，以移動業務為主，提供針對移動業務特征的API，廢棄原有的轉接系統，一方面提高移動數據的傳輸、處理速度，一方面降低單一系統異常帶來的移動體驗風險；
• 產品邏輯，除了核心的商品搜索、展示、交易，評價、社交、導購、物流等都開辟出單獨的產品線，以滿足用戶使用過程的各種需求；

移動應用數據交互全景：

研發過程中的問題：

如果說一個產品從出現到成熟，一定要經過一個“戰爭期”的話，我想一定是這個時期了，摘要里列出的大多數問題都爆發在這個階段，

1 軟\硬件差異方面：

• App在Android_x.x上是可以運行的，在Android_y.y就不行
• App在其他手機上都可以跑，就XXX手機不行

2 網絡環境方面：

• App在WIFI正常顯示數據，切到3G顯示異常
• App在運營商1網絡下正常顯示，在運營商2網絡下一片空白
• XX省請求數據超時嚴重，其他地區正常

3 產品運營方面：

• XX需求一定要跟著App版本走么，能不能明天就上，不然活動就過期了
• HTML5體驗太差了，能不能讓開發優化下
• 這個頁面在App已經做好了，讓開發直接用，這個不算開發時間

4 開發測試方面：

• 這個控件能不能抽出來公用，每次都是各自復制代碼
• 頁面跳轉都是寫死的，抽離代碼，都是報錯，改動太多
• 會員數據、手機軟硬件數據能不能提供API，現在都是另起爐灶，代碼冗余太多
• 跑一次工程太慢了，65535是什么情況
• 為啥商品頁面的改動，還需要把會員相關的場景都測試一遍
• 線上不能直接修改已發布APP的bug，每次有問題都要重新發布，嚴重浪費資源

5 APP性能方面：

• 有用戶反饋，點擊XX頁面就閃退
• 用戶又反饋，首頁展示的非常慢
• 還有用戶反饋，瀏覽了幾頁就提示APP未響應

技術應對方案：

雖然出現了很多問題，但是這個階段出現的技術方案，針對性并不強，都是根據生產版本出現的問題，施加的通用手段，具體如下：

完善App的監控機制，對App的奔潰、HTTP、內存、CPU等指標數據，進行全面采集分析，確保問題的快速響應、定位、解決；

完善的用戶反饋機制，讓用戶可以便捷的反饋，讓開發者可以第一時間收到反饋并解決問題；

HTTP加速（MAA），優化請求鏈路，確保各項業務數據的快速響應；

HTTPDNS，降低DNS劫持的風險；

Chromium引擎，使用Chromium引擎的WebView替代原生的Webview，保證HTML5的快速渲染，提升用戶的購物體驗；

熱修復，對已發布APP的問題，進行在線修復，最大程度的減少問題影響；

VR/AR，增加現實、虛擬現實技術的運用，用“神奇”進一步提升促銷推廣的影響力。

Android Studio，伴隨著Android Studio的出現，一方面通過gradle提升編譯速度，另一方面配合MultiDex同步解決Dex容量的問題；

而相比app的性能問題，產品缺陷、開發缺陷以及體驗問題，才是這個階段最主要的問題，所以在這個階段，項目里面的所有人，每天都在看監控、看用戶反饋，發現問題解決問題。

應用架構生成：

而對于客戶端，也在想法設法的在架構上提高開發質量，主要手段如下：

路由、消息機制，用戶模塊間跳轉，去除不同業務模塊之間的耦合，同時也是為了業務的模塊化、插件化做準備；

模塊化、插件化，物理隔離不同性質的業務代碼，一方面滿足產品快速迭代的需求，另一方面減少蝴蝶效應，同時責任明確，促進高效開發；

服務化，通用UI，抽離成高獨立的控件，形成UI服務；對于通用的數據獲取、處理、存儲，按性質抽離成可拓展的數據處理機制，形成數據服務；

移動黃金時代（2016至今）

時代特點：

• 移動特征，4G網絡為主，數據傳輸速度 + 流量已經不在是移動APP的瓶頸，移動設備的物理性能大幅度提高；
• 發布模式，敏捷開發模式運用成熟，多產品線靈活發布，可集成發布、也可獨立發布；
• Android生態，Android 6.0~7.0，插件手段運用成熟，前端頁面渲染更加高效，Weex/ReactNative、微信小程序等成為新趨勢；開發工具Android Studio。

APP業務特征：

• 業務系統，在傳統的業務系統上，系統更加安全、高效、多樣、智能，接入、升級更加靈活；
• 產品邏輯，視頻直播、虛擬現實、人工智能成為主流元素，商品銷售定位更加精細。

移動應用數據交互全景：

研發過程中的問題：

不同于前面的發展階段，這個階段出現問題（或者說是技術需求）針對性都非常強，主要如下：

數據安全方面，APP界面出現廣告；用戶信息被抓包獲取；

HTTP速度方面，有些偏遠地區，移動請求速度長達3~5s，如何解決；

消息推送方面，客服的消息、活動的信息、物流的狀態如何在第一時間告訴用戶；

前端體驗方面，前端頁面滑動卡段、加載慢、交互延遲，如何優化。

產品獨立方面，有些產品功能做大做強，如何快速形成獨立APP。

技術應對方案：

全站HTTPS，加強數據安全，減少內容劫持，保障用戶隱私，促進購物體驗；

HTTP2.0，在統一接入層（域名收斂）的基礎上支持HTTP2.0，減少DNS解析、請求鏈路復用，進一步加快移動APP的數據交互；

云信系統，一方面滿足客服消息、活動信息、物流狀態的推送，另一方面結合大數據、人工智能，實現真正的精準營銷；

Weex + 靜態資源緩存，引入Weex技術，配合Webview的靜態資源緩存技術，讓前端頁面體驗更加原生化。

與此同時，Google在Android Studio上推出Instant Run用來加速gradle的編譯速度，進一步提升開發效率。

應用架構生成：

這個階段的架構調整，針對上述問題5做了很多精細的工作，一方面要顆粒化業務層、服務層、ADK層，另一方面還要調整原有的單向依賴關系，讓應用工程本身容器化，滿足產品線的快速集成、快速獨立，實現APP研發的DIY，主要調整如下：

徹底落實模塊化、插件化，所有產品線開辟獨立工程，業務代碼完全物理隔離，以Android Library（aar） + Plugin（apk）的方式對外提供；

UI控件、數據服務精細化，即保證所有UI控件、數據服務的高度獨立，讓使用方（業務層）自由取舍；

基礎ADK標準化，收集集團所有APP的技術需求，集中優秀人力資源打造超高性能ADK，生成開發文檔并推廣，促進各產業APP高效研發。

后記

5G時代即將到來，有人說那是人工智能的時代，有人說那是物聯網的時代，也有人說那是虛擬現實的時代，技術改變人們生活習慣的同時，也給開發者帶來的各色各樣的問題，時代在變，技術方案在變，支撐技術的架構也在變。

千變萬化的背后，唯一不變的、也是我們鍥而不舍追求的，就是：“在掌握時代特點、業務特征、軟硬件限制的前提下，合理利用各種資源，設計出最高效的開發方案。”

轉載于:https://www.cnblogs.com/davidwang456/articles/8868544.html

總結

以上是生活随笔為你收集整理的苏宁易购Android架构演进史的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。