淘寶 APP 網絡架構演進與弱網破障實踐

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

引言

自 2013 年 ALLIN 無線到今天，已經走過 10 個年頭，淘寶終端統一網絡庫 AWCN (Ali Wireless Connection Network) 從淘內孵化，一路過來伴隨着淘寶業務的發展，經歷集團 IPv6 戰役、協議升級演進等，逐步沉澱爲阿里集團終端網絡通用解決方案，是兼具高性能、多協議、可容災、可觀測的終端網絡基礎統一設施。面對移動互聯網絡下複雜多變的網絡環境，如何提供更穩定可靠的請求性能，保障用戶的加載瀏覽體驗、更好的支撐業務發展，是我們始終探索的命題。

終端架構介紹

MobileSDN 理念

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

SDN（Software Defined Network，軟件定義網絡）是一種將網絡資源抽象到虛擬化系統中的 IT 基礎架構，SDN 將網絡轉發功能與網絡控制功能分開，其目標是創建可集中管理和可編程的網絡，核心理念是希望應用軟件可以參與對網絡的控制管理，滿足上層業務需求，簡化使用和運維成本。有一個較爲形象的類比，如果說現在的網絡系統是功能機，系統和硬件出廠時就被捆綁在一起，那麼 SDN 就是 Android 系統，可以在很多手機設備上安裝 & 升級，同時還能安裝更多更強大的手機 App（SDN 應用層部署）。

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

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 等網絡時延探測診斷、用戶網絡診斷 / 請求抓包等工具建設。

行業分析

縱觀行業內一些與之對標的移動網絡框架，如騰訊維納斯 WNS、微信 Mars、Chromium cronet、Square Okhttp 等，AWCN 和它們在一些思路上可以說是殊途同歸，通過提供更優的 IP 策略調度、多協議連接管理策略及請求超時等控制加速請求，建設網絡診斷、網絡質量監控等手段加強網絡可觀測能力。

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

圖：微信 Mars 基礎架構

規模總覽

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

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

網絡加速體系詳解

前面提到，網絡控制器是作爲整體架構上的大腦，承擔着請求端到端鏈路的調度和優化決策，相當於掌舵手和發動機的角色。一次完整的請求網絡傳輸大致可以分爲以下鏈路，即 DNS-> 建連 -> 發送數據 -> 等待首包響應 -> 接收數據，過程中 IP 策略調度、連接管理、請求管理及廠商全局調度加速子模塊各承擔着不同的作用，筆者將逐一介紹闡述。

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

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

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

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

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

IP 策略調度：減少 DNS 耗時，選擇更優 IP

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

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

• IP 選取及緩存汰換策略

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

服務端下發：根據單元化 / 運營商 / 就近接入 / 網絡協議棧等維度，下發一組可用的 IP 列表。同時具備通過端側跑馬算法，生成最優的策略 IP。

端側動態排序：根據端側 IP 策略使用記錄（成功 & 失敗 & 耗時等維度）進行優先級排序，建連錯誤次數多的策略在排序優先級上進行降權操作，與之相對應的，建連成功率高性能好的策略優先級提高。

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

淘汰機制：同一 IP 在 5min 中連續失敗 xx 次，進入禁用淘汰的情況

更新機制：域名粒度攜帶 TTL（Time To Live）下發，超過 TTL 的域名進行異步更新，同時更新機制按照域名的優先級也擁有不同的模式。

• 新態勢下的挑戰及升級

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 存儲數據遷移

連接管理：更快建連，保障連接高可用

• 連接建立

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

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

圖：熱域名預建

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

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

複合連接思路也因此來源於 IPv6 Happy Eyeballs 算法實現，詳見 RFC 6555[1]。

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.

圖：雙棧複合連接

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

雙棧環境體驗：從 IPv6 和 IPv4 中爲用戶選擇一個最快的鏈接，且保證優先使用 IPv6

減少後端壓力：避免同時對兩地址發起請求，造成網絡破壞；

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

• 連接調度

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

保活連接：需要時刻保證連接存活，隨時可用，適用於上下行推拉結合的場景，如消息；

常規連接：不需要時刻保活，空閒及時回收減少資源佔用，適用於僅主動上行調用的場景，如 RPC。

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

面向保活可用：假連檢測，動態心跳

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

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

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

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

請求管理：彈性超時控制，請求補償恢復

• 動態超時

精細控制：在請求各個鏈路上，具有獨立超時控制，每個階段精細化控制，快速感知超時情況；

動態調配：針對 不同域名請求 / 網絡類型 / 不同質量 的環境下動態超時時長處理。

圖：請求各階段超時控制

• 多路競爭 & 擇優選用

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

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

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

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

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

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

廠商加速：擁抱原生，系統級調度加速

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

• 廠商能力融合的思考與決策

作爲淘寶終端網絡基礎設施，一直以來我們都專精於應用策略及協議上，致力如何更好的調度、管理連接 / 協議讓請求更快。隨着國內廠商的發展，我們發現，脫離廠商的自研之路並不順暢：

1. 一方面，不同廠商的限制和表現異同常讓我們對各廠商做一些 hack 和兼容性的事情；

2. 另一方面，用戶的網絡資源有限，手淘作爲單一應用，能調配和控制的資源有限。如何擴大我們的調度域得以讓我們的應用內請求更好，是我們常在思考的事情。

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

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

圖：廠商加速接入架構

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

手淘弱網破障實踐

指標定義：明確弱網 / 卡頓請求

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

圖：網絡請求 1s 法則

弱網作爲廣義的概念，有多方面的原因，一般來說我們把用戶網絡波動、信號強度弱、時延 RT 大稱之爲弱網環境。對於用戶來說，最大的體感就是各類頁面打開慢、加載久、圖片空窗等問題，請求耗時久 / 異常是直接原因。我們從請求端到端全鏈路進行逐一分析，除了網絡傳輸、後端服務處理耗時，也存在一些業務本地處理 / 回調等執行的耗時。

圖：請求全鏈路階段

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

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

異常報錯：失敗的請求，無論何種原因失敗，網絡超時、服務端未返回等；

耗時長尾：響應超過 xx 秒未返回、沒有結束的請求。

診斷體系：更快識別、定位各類複雜網絡問題

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

1. 爲什麼 WIFI 下訪問慢，切換到 4G 網絡就恢復了？

2. 我的網絡沒問題，爲什麼手淘等淘系應用加載慢，其他 APP 正常？

3. 爲什麼 xx 頁面加載很慢，其他頁面沒問題？

4. ......

其中導致的原因很多，如用戶路由器的配置、淘系域名被營商 IP 封禁、業務調用鏈路超時等，爲了更好的定位 / 分析各類網絡類問題， 我們針對移動互聯網下用戶網絡類體驗問題的複雜性，進一步建設 NPM 診斷技術體系，加強相關技術和數據的應用。

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

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

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

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

弱網技術：複雜網絡下的網絡體驗

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

• 網絡多通道：手淘規模化應用

當請求沒有響應 / 接收慢的情況下，一般會觸發超時機制進行請求重放。但在用戶 WIFI 信號差 & 弱網環境下，我們反而要謹慎重試，一方面重試會加重系統上的負載，另一方面重試會導致請求重新開始，對弱網傳輸慢的情況不友好，反而加劇卡慢的情況。

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

圖：系統官方文檔

規模化方案

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

圖：多通道整體規模化方案

優化數據

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

• 原生 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 的實現是必經之路。

如何支持標準 HTTP/2？

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

1. 標準協議的完整實現，必然要加入人力投入開發，穩定性驗證和上線是一個較長的週期，如何減少支持的成本？考慮引入穩定的能力實現，如 Okhttp。

2. 穩定庫引入必定會增加包大小，這對目前嚴控包大小的現狀有較大沖突，如何解決？需儘可能不增加包大小的情況下支持。

3. 既要考慮成本和穩定性驗證等規模化問題，又要避免給手淘包大小過大的增幅。既要馬兒跑，又要馬兒不喫草。如何實現？

源碼突破

通過對系統源碼的分析，我們發現 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 代碼

爲了規避系統側問題，我們摒棄 okhttp 提供異步調用的 api，改爲同步調用 + 異常捕獲 + 上層轉異步的方式進行處理。

此外，針對不同應用，若存在三方 okhttp 依賴，會自動橋接到三方實現上，體驗高版本 okhttp 的穩定性；對於手淘這種不依賴三方 okhttp 的應用，再橋接到系統版本實現。

優化數據：標準 H2 升級率先在 Feeds 接口域名覆蓋，農場整體輿情月環比下降 23%，請求耗時優化 21.4%，成功率提升 0.3pt。

小結

截至目前，日改善卡頓請求 (網絡錯誤 / 耗時> x 秒) PV 10 億 + ，達成全年目標 10 億 (統計口徑嚴格按照 AB 實驗桶對比計算)，MOTP 請求超時率較去年 4 月優化了近 50%。

後續方向與展望

對於移動網絡體驗的探索是無止境的，今年我們圍繞弱網和體驗加速做了一些工作，有些內容因爲篇幅和側重點考慮所以沒有進一步展開講述，後期再通過另外專題文章進行側重講解。

但即便如此，面對億萬用戶各類複雜多變的環境，仍存在着加載慢、卡頓、空白的聲音，作爲淘寶和集團統一的終端基礎網絡設施，如何讓用戶瀏覽體驗再更上一層樓，我們要做的還很多。

更精準的網絡狀態感知

準確掌握用戶的網絡狀態是一切手段的前提，以往我們圍繞 NPM 搭建診斷體系，對端到端鏈路的連通性和質量進行檢測，在實時性、準確度和可用性仍有提升空間。

結合廠商系統側更精準可靠的網絡質量反饋：依託提供 QoE 網絡質量能力，提供更實時的 WiFi / 蜂窩網絡信號質量和強度反饋;

提供用戶更友好的網絡感知手段：當用戶出現 “潛在” 的網絡問題，我們希望大部分情況用戶可以自行知道哪裏出問題、怎麼解決。

圖：用戶網絡診斷感知

更動態智能的調度加速能力

針對不同網絡類型和質量的環境，我們希望建設更適應性更動態智能的調度能力，基於不同場景做更適合有效的加速能力應用，一成不變，固化的優化策略無法在所有的環境下發揮更優的效果。前面提到，當我們能夠更精準感知，甚至預測用戶網絡的變化，我們能夠做的事情就更多。

圖：預測弱網環境的動態調優

更一致的弱網交互體驗

我們發現淘寶多業務在弱網交互下表現不一，存在着無法刷新重試、空白無提示、阻塞無法操作等問題，因此除了技術側的能力強化，會進一步聯合多方沉澱弱網體驗規範，協同業務優化弱網場景下的表現與體驗、提升交互性和可恢復性，並改善用戶在弱網下的預期和感受。

圖：淘寶弱網交互表現不一

參考資料

[1]RFC 6555: https://www.rfc-editor.org/rfc/rfc6555

團隊介紹

我們是大淘寶終端平臺技術團隊，負責淘寶移動域中間件 / 原生技術挖掘 / 核心技術建設，包括不限於客戶端體驗 / 框架及創新體驗 / 廠商與系統技術 / 用戶增長及移動平臺等，支撐億萬流量的移動網絡接入，若你對我們的工作內容感興趣，歡迎加入挑戰。簡歷投遞郵箱：liangwei.slw@alibaba-inc.com。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/NVhtEoWUJK87ADwjXC5K0w