淘寶移動端統一網絡庫的架構演進和弱網優化技術實踐

Posted on 2023-10-19 14:10 Jack Jiang 閱讀(149) 評論(0) 編輯收藏

本文由大淘寶終端平臺技術團隊沈良煒(沛軒)分享，本文有修訂和改動。

1、引言

自 2013 年 ALLIN 無線到今天，已經走過 10 個年頭，淘寶終端統一網絡庫 AWCN (Ali Wireless Connection Network) 從淘內孵化，一路過來伴隨著淘寶業務的發展，經歷集團 IPv6 戰役、協議升級演進等，逐步沉淀為阿里集團終端網絡通用解決方案，是兼具高性能、多協議、可容災、可觀測的終端網絡基礎統一設施。

面對移動互聯網絡下復雜多變的網絡環境，如何提供更穩定可靠的請求性能，保障用戶的加載瀏覽體驗、更好的支撐業務發展，是我們始終探索的命題。

本文將介紹淘寶 APP 統一網絡庫演進的過程，講述如何圍繞體驗持續構建南北向從監測到加速一體化的終端網絡架構，通過構建 NPM 弱網診斷感知能力，落地原生多通道技術/多協議擇優調度手段，貼合廠商附能網絡請求加速，實現去 SPDY 及規模化 IPv6/H3 協議簇的平滑過渡，為用戶提供弱網更好、好網更優的 APP 加載瀏覽體驗，支撐業務創造更多的可能性。

* 推薦閱讀：《百度統一socket長連接組件從0到1的技術實踐》。

技術交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4470-1-1.html）

2、本文作者

本文由大淘寶終端平臺技術團隊沈良煒（沛軒）分享。

大淘寶終端平臺技術團隊，主要負責淘寶移動域中間件/原生技術挖掘/核心技術建設，包括不限于客戶端體驗/框架及創新體驗/廠商與系統技術/用戶增長及移動平臺等，支撐億萬流量的移動網絡接入。

3、MobileSDN 理念

在介紹 AWCN 之前，筆者想先這里普及下 SDN 架構的概念。

SDN（Software Defined Network，軟件定義網絡）是一種將網絡資源抽象到虛擬化系統中的 IT 基礎架構，SDN 將網絡轉發功能與網絡控制功能分開，其目標是創建可集中管理和可編程的網絡，核心理念是希望應用軟件可以參與對網絡的控制管理，滿足上層業務需求，簡化使用和運維成本。

有一個較為形象的類比，如果說現在的網絡系統是功能機，系統和硬件出廠時就被捆綁在一起，那么 SDN 就是 Android 系統，可以在很多手機設備上安裝&升級，同時還能安裝更多更強大的手機 App（SDN 應用層部署）。

回到移動應用領域，我們的目標是搭建統一的終端網絡解決方案，上層業務不需要關心內部的協議如何轉發、請求超時降級等復雜邏輯，做到好用、易用、可觀測、體驗好。顯然，這與傳統 SDN 架構理念不謀而合。

4、AWCN 終端網絡架構

因此，圍繞以上理念和目標，我們進一步構建起南北向從監測到加速一體化的 MobileSDN 架構，以減少業務的接入/運維成本，提升用戶的瀏覽體驗。

AWCN Mobile-SDN 架構：

從 MobileSDN 架構展開來，接下來簡要介紹下各分層模塊承擔的角色與其中作用。

1）網絡應用：面向多種應用場景衍生出的網絡組件，如統一 RPC 網關（MTOP）、消息 PUSH 通道（ACCS）、上傳（AUS）、下載（TBDownloader）、圖片加載（Phenix）、遠程配置（Orange）等能力。

2）網絡北向接口：上層調用和內部實現的橋梁，提供統一同步/異步對外 API 接口和無痕 Hook 方式，用于上層網絡應用/業務場景接入調用網絡基礎能力。

3）網絡控制器：請求策略管控中心，架構大腦，負責請求端到端鏈路的調度和優化決策，有著舉足輕重的作用，控制器提供完備的網絡加速能力，從節點調度/連接選擇/請求管理多個環節進行網絡請求加速。

4）網絡南向接口：控制面與基礎協議轉發的橋梁，對協議及數據進行了通用抽象，以應對不同系統框架/不同協議的統一處理。

5）網絡協議轉發：多個基礎協議和網絡框架的統一適配實現，兼容各類請求場景下的最優選擇調度，支持標準 HTTP/1.1、HTTP/2、HTTP/3，以及集團自研的 HTTP/2+SSSL 和 H3-XQUIC 協議。

6）網絡性能管理：網絡數據及性能觀測中心，NPM（Network Performance Management），負責設備網絡狀態/質量/信號強度的感知、業務請求數據的統計上報、PING/TRACE/NSLookup 等網絡時延探測診斷、用戶網絡診斷/請求抓包等工具建設。

5、市面上的同類方案分析

縱觀行業內一些與之對標的移動網絡框架，如騰訊維納斯 WNS、微信 Mars（《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》）、Chromium cronet、Square Okhttp 等，AWCN 和它們在一些思路上可以說是殊途同歸，通過提供更優的 IP 策略調度、多協議連接管理策略及請求超時等控制加速請求，建設網絡診斷、網絡質量監控等手段加強網絡可觀測能力。

微信 Mars：STN 負責請求任務管理/IP 排序/網絡策略等能力優化請求體驗，SDT 為網絡診斷模塊，一定程度上與 AWCN 中網絡控制器、網絡性能管理兩塊部分承擔角色相近。

微信 Mars 基礎架構：

（圖片引用自《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》）

6、淘寶統一網絡庫的應用情況

淘寶統一網絡庫作為基礎組件在集團內被廣泛應用，集團內涵蓋千級以上規模應用支撐，包含且不限于：手淘、閑魚、優酷、天貓、Lazada、高德、UC瀏覽器、餓了么等 APP，同時通過阿里云 EMAS、友盟對三方應用開放接入，如海底撈/杭州銀行等企業應用。

作為移動網絡解決方案，網絡請求的體驗是重中之重。

因此，筆者將重點講述網絡控制器如何圍繞請求構建完整鏈路上的加速技術，介紹如何從節點調度/連接選擇/請求管理/系統調度進行業務網絡體驗優化，確保請求在各類復雜網絡狀況下高可用。

7、網絡加速體系概覽

前面提到：網絡控制器是作為整體架構上的大腦，承擔著請求端到端鏈路的調度和優化決策，相當于掌舵手和發動機的角色。

一次完整的請求網絡傳輸大致可以分為以下鏈路：即DNS->建連->發送數據->等待首包響應->接收數據。過程中 IP 策略調度、連接管理、請求管理及廠商全局調度加速子模塊各承擔著不同的作用，筆者將逐一介紹闡述。

各模塊在一次調用過程的作用域：

具體解讀就是：

1）IP 策略調度：負責 IP/節點的選擇和調度，職責是選擇最優的 IP 策略，減少 DNS 帶來的耗時，同時具備切流容災的能力；

2）連接及協議管理：負責連接池生命周期的管理和各類協議的選擇，職責是連接擇優且高可用；

3）請求管理：負責請求的調度，涵蓋超時、降級、重試恢復等流程控制，職責是讓請求更快的被執行；

4）廠商加速：負責對接各大廠商系統側的網絡能力，結合系統賦予的網絡加速能力（如更精準的網絡質量狀態/雙頻 WiFi 聚合加速/流加速等），進一步優化復雜網絡下請求調度的策略決策，是自研與廠商原生網絡能力之間的溝通樞紐。

8、網絡加速體系之IP策略調度

8.1 概述

IP策略調度的目的是減少 DNS 耗時，選擇更優 IP。

眾所周知：傳統的 LocalDNS 方式存在各類隱患問題，如：解析慢/失敗率高、更新不及時、域名劫持、缺少精準流量調度及容災能力，AMDC（Ali Mobile Dispatch Center）是阿里自建的無線域名解析調度服務，在淘寶和集團絕大多數應用中廣泛應用。

PS：關于HttpDNS的技術文章可詳讀：

《全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》

《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》

依托 HTTPDNS 實現無線調度功能就夠了嗎？遠沒有那么理想化，如何在端側處理好 IP 策略的選取/容災/安全性/服務 QPS 壓力等環節，都至關重要。

8.2 IP 選取及緩存汰換策略

IP 選擇機制上（基于服務下發+端側動態排序的機制運行）：

1）服務端下發：根據單元化/運營商/就近接入/網絡協議棧等維度，下發一組可用的 IP 列表。同時具備通過端側跑馬算法，生成最優的策略 IP；
2）端側動態排序：根據端側 IP 策略使用記錄（成功&失敗&耗時等維度）進行優先級排序，建連錯誤次數多的策略在排序優先級上進行降權操作，與之相對應的，建連成功率高性能好的策略優先級提高。

緩存和汰換機制上（考慮到頻繁 AMDC 調度帶來服務壓力、異步請求 AMDC 帶來的生效率問題，端側對策略進行了緩存，根據用戶網絡粒度進行獨立存儲，應用啟動和網絡事件切換情況下加載所需的策略記錄；根據前面所提及的建連記錄動態排序能力，自然也產生了對應的淘汰替換機制）：

1）淘汰機制：同一 IP 在 5min 中連續失敗 xx 次，進入禁用淘汰的情況；
2）更新機制：域名粒度攜帶 TTL（Time To Live）下發，超過 TTL 的域名進行異步更新，同時更新機制按照域名的優先級也擁有不同的模式。

8.3 新態勢下的挑戰及升級

CASE 1：高版本設備對于 WiFi 網絡唯一標識的獲取限制：

前面提及的端側緩存策略基于用戶網絡粒度做獨立存儲，對于 WiFi 網絡環境 BSSID 是端側的標識主鍵，但隨著系統升級帶來的一系列用戶權限收斂。

具體是：

1）Android 8 及以上版本開始，需要用戶授權定位等權限，才可以拿到 Wi-Fi SSID/BSSID 等相關信息，否則返回 02:00:00:00:00:00 默認值；
2）iOS 14 起，必須接入 network extension，否則無論通過任何手段都無法獲取到 wifi 相關信息，對接 NE 成本太高。

這意味著現有網絡存儲結構不再具備唯一標識用戶網絡的能力，無法正常獲取 BSSID 信息的這些設備上存在著策略混用，甚至跨運營商的問題，從而導致請求性能變慢/出現異常，線上約有 20%+的用戶受潛在影響。

因此，對于端側無法直接獲取 BSSID 的設備，引入新的存儲主 key，即用戶無線接入點 AccessPoint 信息，流程涉及 AMDC 端到端協同升級，大致流程如下圖所示。

WIFI 存儲升級改造流程：

數據上，圖片等 CDN 類請求平均耗時優化4.439%，耗時分位 P90 優化1.932%，P99 優化2.230%，P999 優化2.668%。

CASE 2: 應對更復雜協議/更精細化調度訴求下的協議演進：

當現有協議結構無法滿足日益復雜和精細的調度訴求，且無法在現有模型上持續長期迭代時，就需要對協議進行重構升級。

我們在移動網絡虛擬化項目中切實遇到如上的問題，協議重構對于端上來說，是對整個存儲數據模型的改變，這意味著升級新協議的用戶可能無法繼續使用舊版本存儲策略，直接丟棄老協議存儲是最簡單有效的手段，但這會導致升級后一段時間內用戶出現降級 LocalDNS 的問題，這對我們不能容忍。

重新實現一個協議不難，難的是如何確保新老協議平穩升級過渡，避免請求出現 LocalDNS 降級。

因此，方案的關鍵在于如何對新老協議做數據遷移，其中涉及升級鏈路和降級鏈路（如穩定性問題功能回退場景）。

AMDC 存儲數據遷移：

9、網絡加速體系之連接管理

連接管理的目的是更快建連，保障連接高可用。

9.1 連接建立

除了常規的串行建連和并發建連方式，我們提供了熱域名預建和復合連接的方式，應對各種復雜的場景。

熱域名預建機制（啟動場景下的關鍵請求加速）：

復合連接機制（IPv6 規模化背景下的體驗保障）：

當淘寶作為 IPv6 示范性應用跑在最前面時，我們發現國內存在部分雙棧網絡 IPv6 質量差甚至不通的情況，Android 的輿情反饋尤為突出，原因在于 iOS 系統側實現了 Happy Eyeballs 機制確保快速 rollback 回 IPv4 鏈路，而 Android 設備沒有。

復合連接思路也因此來源于 IPv6 Happy Eyeballs 算法實現，詳見RFC 6555。

When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual-stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm.

雙棧復合連接：

復合連接的兩個核心目標：

1）雙棧環境體驗：從 IPv6 和 IPv4 中為用戶選擇一個最快的鏈接，且保證優先使用 IPv6；
2）減少后端壓力：避免同時對兩地址發起請求，造成網絡破壞。

數據上：針對 MTOP 和圖片請求，雙棧情況下其建連性能平均耗時降低 22.12%，99 分位性能降低60.19%，請求數據平均耗時降低1.23%，P99 分位耗時降低6.077%。

9.2 連接調度

按照不同的通道應用場景，連接可以區分為兩種形態，保活連接與常規連接。

具體是：

1）保活連接：需要時刻保證連接存活，隨時可用，適用于上下行推拉結合的場景，如消息；
2）常規連接：不需要時刻保活，空閑及時回收減少資源占用，適用于僅主動上行調用的場景，如 RPC。

針對建立好的連接，不同形態的維護管理方式也不同。

面向保活可用：

1）假連檢測；
2）動態心跳。

動態心跳具體是指：通過對連接的多場景可用性檢測，增強連接質量的感知，當出現連接異常時能夠快速的恢復重建。

檢測的手段基本為：心跳 PING 包方式，分位定時心跳（前后臺間隔不同）、分場景心跳（切換前臺、業務上行超時等）。

面向空閑回收：閑時狀態檢查，及時關閉。

對于不需要主動下行推送的場景，建連時刻保持對于用戶帶寬和功耗存在一定影響，因此針對此類連接增加了空閑狀態的檢查，當發現建連超過一定時間沒有數據包傳輸時會進行連接的關閉回收，以減少資源占用，釋放有限帶寬。

PS：之前分享很多有關IM長接的心跳技術文章，技術原理都差不多，可以一并閱讀：

《一文讀懂即時通訊應用中的網絡心跳包機制：作用、原理、實現思路等》

《微信團隊原創分享：Android版微信后臺保活實戰分享(網絡保活篇)》

《移動端IM實踐：實現Android版微信的智能心跳機制》

《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》

《融云技術分享：融云安卓端IM產品的網絡鏈路保活技術實踐》

《一種Android端IM智能心跳算法的設計與實現探討（含樣例代碼）》

《跟著源碼學IM(五)：正確理解IM長連接、心跳及重連機制，并動手實現》

《萬字長文：手把手教你實現一套高效的IM長連接自適應心跳保活機制》

10、網絡加速體系之請求管理

請求管理的目的是彈性超時控制，請求補償恢復。

10.1 動態超時

具體是：

1）精細控制：在請求各個鏈路上，具有獨立超時控制，每個階段精細化控制，快速感知超時情況；
2）動態調配：針對不同域名請求/網絡類型/不同質量的環境下動態超時時長處理。

請求各階段超時控制：

10.2 多路競爭 & 擇優選用

對于請求超時或慢的場景，AWCN 會通過多種方式進行擇優選用和請求補償，確保鏈路最優，保障體驗。

具體做法是：

1）傳輸協議：運營商對于 HTTP/3（UDP）的網絡質量保證遠不及 TCP，常常遇到各類 UDP 穿透性、請求超時等問題，因此必要時需快速決策，切回 HTTP/2、HTTP/1.1 的 TCP 傳輸鏈路；

2）底層框架：自研傳輸庫(TNET)帶來的好處是協議的自建和調優，但也因此導致協議非標(如 HTTP/2+SSSL 私有加密協議)，運營商攔截丟包、端到端鏈路穩定性等問題，必要時決策回退至系統原生庫；

3）網絡通道：以往對于用戶網絡不通導致的問題，優化的手段有限，但隨著系統開放多通道選擇的能力之后，上層也擁有了切換網絡通道的能力，當檢測 WiFi 不通環境下，會將請求切換至蜂窩網絡通道恢復。

以傳輸協議擇優選用為例，對于 H3 協議在手淘的規模化過程用戶體驗不受損，AWCN 網絡庫建立起完善的擇優選用和補償兜底機制。

H3 規模化過程中的體驗保障：

11、網絡加速體系之廠商加速

廠商加速的目的是擁抱原生，系統級調度加速。

近年來，國內幾家廠商前后對上層應用開放了系統級的網絡優化能力，包括網絡帶寬調度、數據流加速、QoE 狀態反饋、弱網預測、雙 WiFi 聚合能力等，從系統側調度提升請求性能。

以下是廠商能力融合的思考與決策。

作為淘寶終端網絡基礎設施，一直以來我們都專精于應用策略及協議上，致力如何更好的調度、管理連接/協議讓請求更快。

隨著國內廠商的發展，我們發現，脫離廠商的自研之路并不順暢：

1）一方面，不同廠商的限制和表現異同常讓我們對各廠商做一些 hack 和兼容性的事情；
2）另一面，用戶的網絡資源有限，手淘作為單一應用，能調配和控制的資源有限。

如何擴大我們的調度域得以讓我們的應用內請求更好，是我們常在思考的事情。

因此我們選擇擁抱廠商，通過系統賦予的調度加速能力，深度合作，為應用提供更好的網絡體驗。

為了屏蔽不同廠商之間的能力差異和接入方式不同，AWCN 提供廠商加速模塊的通用能力抽象，通過運行期對不同設備和廠商能力的解決，動態組織支持的系統能力列表。

廠商加速接入架構：

目前，我們已經和 OPPO 完成接入和上線工作，協同廠商側緊鑼密鼓的放量驗證中。

12、弱網優化指標定義

弱網優化指標定義的目的是明確弱網/卡頓請求。

過往我們基于網絡請求 1s 法則作為優化的指標衡量，目前業務請求秒出率超過 95%，當網絡體驗進入深水區，弱網/長尾等卡頓負向請求成為我們關注和突破重點。

網絡請求 1s 法則：

弱網作為廣義的概念，有多方面的原因。

一般來說我們把用戶網絡波動、信號強度弱、時延 RT 大稱之為弱網環境。

對于用戶來說，最大的體感就是各類頁面打開慢、加載久、圖片空窗等問題，請求耗時久/異常是直接原因。

我們從請求端到端全鏈路進行逐一分析，除了網絡傳輸、后端服務處理耗時，也存在一些業務本地處理/回調等執行的耗時。

請求全鏈路階段：

通過梳理完整請求的調用鏈路，我們在思考如何通過指標化的方式衡量出這部分對業務/用戶體驗有損的請求，在明確目前線上相關負向卡頓請求的規模的前提下，再進行進一步的優化及效果觀測。

因此，基于用戶/業務視角，將請求全鏈路階段內出現異常報錯、耗時長尾定義為卡頓請求。

具體是：

1）異常報錯：失敗的請求，無論何種原因失敗，網絡超時、服務端未返回等；
2）耗時長尾：響應超過 xx 秒未返回、沒有結束的請求。

PS：關于弱網的技術文章可以深入詳讀：

《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》

《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》

《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》

《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》

《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》

《愛奇藝移動端網絡優化實踐分享：網絡請求成功率優化篇》

《美團點評的移動端網絡優化實踐：大幅提升連接成功率、速度等》

《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》

13、弱網優化診斷體系

弱網優化診斷體系的目的是更快識別、定位各類復雜網絡問題。

經常有一些線上用戶反饋網絡類的輿情：

1）為什么 WIFI 下訪問慢，切換到 4G 網絡就恢復了？
2）我的網絡沒問題，為什么手淘等淘系應用加載慢，其他 APP 正常？
3）為什么 xx 頁面加載很慢，其他頁面沒問題？
4）......

其中導致的原因很多，如用戶路由器的配置、淘系域名被營商 IP 封禁、業務調用鏈路超時等。

為了更好的定位/分析各類網絡類問題，我們針對移動互聯網下用戶網絡類體驗問題的復雜性，進一步建設 NPM 診斷技術體系，加強相關技術和數據的應用。

比如：

1）領域模型：用戶體驗問題的技術面窮舉拆解、沉淀；

2）能力構建：診斷原子能力及工具鏈，運維提效；

3）規模應用：多維用戶網絡數據，IPv6/MTU/UDP 大盤。

多場景網絡體驗類問題診斷體系：

14、弱網優化技術實踐

針對移動復雜網絡環境，除了前面網絡加速體系所提到的相關能力之外，這里筆者將重點對典型弱網靶向性優化技術展開。

14.1 網絡多通道

當請求沒有響應/接收慢的情況下，一般會觸發超時機制進行請求重放。

但在用戶 WIFI 信號差&弱網環境下，我們反而要謹慎重試，一方面重試會加重系統上的負載，另一方面重試會導致請求重新開始，對弱網傳輸慢的情況不友好，反而加劇卡慢的情況。

因此：在尋求更友好的方式上，我們發現系統提供了一種多通道傳輸的能力，即允許設備在 WIFI 環境下將請求切換蜂窩網卡的能力，網絡應用層可以利用該技術，減少請求的超時等一類錯誤，提升請求的成功率。

系統官方文檔：

14.2 規模化方案

除了常規的技術應用，因為涉及到用戶在 WIFI 網絡下的流量損耗，我們遵從用戶隱私等合規前提下，提供多通道能力生效的用戶提示和功能授權。

多通道整體規模化方案：

14.3 優化數據

目前多通道技術在手淘核心瀏覽鏈路上已規模化應用，嚴格按照AB 實驗得出數據，雙十一期間雙端日對請求超時率減少 30%以上。

14.4 原生 HTTP/2：突破系統限制，實現 H2 協議支持

相對于 HTTP/1.1 協議，HTTP/2、HTTP/3 的協議性能優勢不言而喻，HTTP/2 協議在手淘和集團內早已支持多年，HTTP/3 協議同樣在持續規模擴量中，但目前淘寶內仍然存有 10%左右 HTTP1.1 流量。

通過分析，主要有以下原因導致：

1）HTTP/2 協議非標準化實現，加密方式為私有 slight-ssl，域名支持需服務端部署，未明確知曉是否支持的域名只能走 HTTP/1.1 協議；
2）鑒于非標的影響，請求鏈路上需要強依賴 AMDC，必須通過 AMDC 配置明確支持 h2+sssl 方式的域名下發后才能支持；
3）非標協議的兼容性存在小概率問題，個別運營商針對非標協議會進行劫持處理導致請求失敗降級到短連。

過往很多業務反饋，為什么域名在 chrome 瀏覽器上訪問支持 HTTP/2，而手淘里是仍然是 HTTP/1.1 的原因就在于此。

那么，如何在不需要服務端部署、不強依賴 AMDC 的前提下，讓請求實現長連加速？標準 HTTP2 的實現是必經之路。

14.5 如何支持標準 HTTP/2？

iOS 通過升級 URLSession 系統調用方式，可低成本的遷移到 H2/H3 協議上，但對于 Android 來說，系統側提供的 HttpUrlconnection 僅支持到 HTTP/1.1 協議。

因此，靈魂三問：

1）標準協議的完整實現，必然要加入人力投入開發，穩定性驗證和上線是一個較長的周期，如何減少支持的成本？考慮引入穩定的能力實現，如 Okhttp；
2）穩定庫引入必定會增加包大小，這對目前嚴控包大小的現狀有較大沖突，如何解決？需盡可能不增加包大小的情況下支持；
3）既要考慮成本和穩定性驗證等規模化問題，又要避免給手淘包大小過大的增幅。既要馬兒跑，又要馬兒不吃草。如何實現？

14.6 源碼突破

通過對系統源碼的分析，我們發現 Android 系統 5.0 之后，系統 API HttpUrlconnection 底層已經通過 okhttp 進行托管實現，也就是說 Android 系統本身支持通過 okhttp 訪問不需要額外引入三方庫進行，只要找到可以 hook 的點。

Android 網絡托管 Okhttp 代理：

進一步分析源代碼，我們找到了 okhttp 在 android 系統側的位置和包名，即com.android.okhttp下。

Android Okhttp 源碼實現：

雖然是隱藏 API，仍可以通過反射的方式進行，為了更友好的編碼實現，在編譯期通過空實現依賴的方式進行顯式的調用，同時確保在使用前對設備 okhttp 的環境及兼容性做好檢查。

Android Okhttp crash：

灰度過程我們發現一些因為 Okhttp 導致的 IndexOutOfBoundsException 穩定性問題，bug 來源于特定場景下沒有拿到證書列表且未對容器判空導致，詳細記錄在：https://github.com/square/okhttp/issues/4208。官方在版本 3.12.2+上修復，但 android 源碼仍使用 2.x 版本導致無法修復。

okhttp 導致 IndexOutOfBoundsException 代碼：