蘇寧易購Android架構演進史

互聯網後端架構 https://mp.weixin.qq.com/s/5lDXjMh6ghQNi4E7qQIEEg

互聯網後端架構 10月9日

摘要

移動青銅時代（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未響應

技術應對方案：

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

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

2. 完善的用戶反饋機制，讓用戶能夠便捷的反饋，讓開發者能夠第一時間收到反饋並解決問題；

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

4. HTTPDNS，下降DNS劫持的風險；

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

6. 熱修復，對已發佈APP的問題，進行在線修復，最大程度的減小問題影響；

7. VR/AR，增長現實、虛擬現實技術的運用，用「神奇」進一步提高促銷推廣的影響力。

8. Android Studio，伴隨着Android Studio的出現，一方面經過gradle提高編譯速度，另外一方面配合MultiDex同步解決Dex容量的問題；

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

應用架構生成：

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

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

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

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

 

移動黃金時代（2016至今）

時代特色：

• 移動特徵，4G網絡爲主，數據傳輸速度 + 流量已經不在是移動APP的瓶頸，移動設備的物理性能大幅度提升；

• 發佈模式，敏捷開發模式運用成熟，多產品線靈活發佈，可集成發佈、也可獨立發佈；

• Android生態，Android 6.0~7.0，插件手段運用成熟，前端頁面渲染更加高效，Weex/ReactNative、微信小程序等成爲新趨勢；開發工具Android Studio。

APP業務特徵：

• 業務系統，在傳統的業務系統上，系統更加安全、高效、多樣、智能，接入、升級更加靈活；

• 產品邏輯，視頻直播、虛擬現實、人工智能成爲主流元素，商品銷售定位更加精細。

移動應用數據交互全景：

 

研發過程當中的問題：

不一樣於前面的發展階段，這個階段出現問題（或者說是技術需求）針對性都很是強，主要以下：

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

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

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

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

5. 產品獨立方面，有些產品功能作大作強，如何快速造成獨立APP。

技術應對方案：

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

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

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

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

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

應用架構生成：

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

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

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

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

    

後記

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