天天看點

Android網絡性能監控方案背景問題與挑戰實作方案

阿裡雲 雲原生應用研發平台EMAS 劉寶文(木睿)

背景

移動網際網路時代,移動端極大部分業務都需要通過App和Server之間的資料互動來實作,是以大部分App提供的業務功能都需要使用網絡請求。如果因為網絡請求慢或者請求失敗,導緻使用者無法順暢的使用業務功能,會對使用者體驗造成極大影響。

此外,EMAS對外提供的APM之前并不包括網絡監控功能,而網絡性能監控作為移動端性能監控的重要組成部分,我們急需補全這部分能力來完善APM的産品功能,進一步滿足客戶的需求。

“阿裡巴巴應用研發平台 EMAS 是國内領先的雲原生應用研發平台(移動App、H5應用、小程式、Web應用等),基于廣泛的雲原生技術(Backend as a Service、Serverless、DevOps、低代碼等),緻力于為企業、開發者提供一站式的應用研發管理服務,涵蓋開發、測試、運維、營運等應用全生命周期。”

問題與挑戰

網絡性能監控在端上主要包括資料采集和資料上報。我們希望能盡可能采集有用的資訊來幫助客戶發現、定位和解決網絡性能問題。我們面臨如下問題和挑戰:

•首先要解決的是網絡請求過程中,哪些階段會影響請求性能,如果發現網絡性能有問題,需要采集哪些資料來幫助使用者去定位和解決問題。

• android上主流的網絡架構有okhttp2、okhttp3、okhttp4、volley、retrofit、httpclient和系統提供的httpurlconnection等,在我們不确定客戶使用哪個網絡庫的哪個版本的情況下,如何盡量采集有用的資訊。

• 網絡請求各個階段的資料采集都是離散的,如何保證單個請求各個離散的監控資料能夠串聯起來,不和其他請求的監控資料混在一起。

• 由于弱網環境下的網絡請求日志往往更有價值,需要盡可能将異常的網絡請求日志資料上報到服務端。

• 并發網絡請求時,需要確定在日志上傳時盡量不影響客戶正常業務。

實作方案

網絡性能監控在端上的具體實作主要包含兩大子產品:

• 資料采集

• 資料上報

其中資料采集是整個SDK架構的核心。

整體架構概覽:

Android網絡性能監控方案背景問題與挑戰實作方案

接入層:

網絡監控屬于高可用産品的一部分,采用高可用統一接入的方式接入。

插件層:

高可用目前架構是通過插件式的方式內建各個業務,實作networkmonitor plugin內建到APM中,補充APM中網絡監控部分。

邏輯層:

主要負責采集控制、資料管理、緩存管理和資料上報。

攔截器層:

整個網絡監控的核心。為了采集更多的資訊,我們選擇使用位元組碼注入技術來實作網絡請求監控功能。對OkHttp、HttpClient和HttpUrlConnection,分别實作Interceptor去采集不同網絡庫中網絡請求各個階段的資料,并在請求結束時完成采集進行上報。此外,通過自定義gradle plugin的方式,為各個網絡庫實作Injector和開關,控制在應用建構階段将Interceptor中各個采集的方法注入到對應網絡庫位元組碼的埋點位置,進而實作在運作時網絡請求各個階段采集需要的資料。

資料采集

采集哪些資料

首先需要确定采集的資料範圍來幫助我們及時發現網絡請求的性能和異常等情況,另一方面也需要有額外的資料來輔助排查問題。是以我們采集的資料主要包括四個部分:

• 基礎資料。

• 性能資料。

• 異常資訊。

• 事件序列資料。

基礎資料

Android網絡性能監控方案背景問題與挑戰實作方案

• 請求url:對請求做聚合運算。

• 目标IP位址:對于多出口IP的客戶,支援IP位址次元的資料分析。

• dns解析結果:請求url的域名解析ip清單,用于分析是否存在域名劫持的問題。

• http code:根據http code确定請求狀态。

• 上行流量:包括整個請求上行header和body的總的流量,包含重試和重定向的上行流量。用于監控上行流量開銷。

• 下行流量:包括整個請求下行header和body的總的流量,包含重試和重定向的下行流量。用于監控下行流量開銷。

• 網絡庫類型及版本:對于客戶更換網絡庫或者更新網絡庫版本的情況,可以提供前後的網絡資料的差異。

性能資料

性能資料主要是采集整個網絡請求中各個階段的耗時情況來定位慢請求發生的階段。下圖列舉了http請求可能出現的各個階段。

Android網絡性能監控方案背景問題與挑戰實作方案

是以性能資料部分需要采集下述各個階段的耗時資料:

  • •整個網絡請求耗時
    • •dns耗時
    • •建連耗時
      • •TLS建連耗時
    • •資料上行耗時
      • •header上行耗時
      • •body上行耗時
    • •資料下行耗時
      • •header下行耗時
      • •body下行耗時

異常資訊

異常資訊主要是收集網絡請求各階段出現異常時的異常棧的資訊。比如常見的java.net.UnknownHostException、java.net.SocketTimeoutException等。

事件序列資料

事件序列資料主要是收集網絡請求各階段的監控事件的資訊,另外對于特定網絡庫的一些特殊的事件的監控,比如okhttp的連接配接複用、自動重定向和失敗重試等對網絡耗時有影響的機制。最後将這些事件按時間順序排列。

比如在okhttp上dns被劫持的場景,我們通過基礎資料中的目标IP位址去判斷dns劫持情況,這個目标IP位址是在建立連接配接的時候去采集的。如果第一個請求發生了dns劫持的情況,那這個請求我們能正常識别的dns劫持已經發生。如果後續的網絡請求複用了這個連接配接,因為不會再去建立連接配接,是以基礎資料中沒有目标IP位址,這時候就需要使用事件序列資料中的連接配接複用事件中的連接配接的url和目标IP位址來判斷是不是被劫持的請求。

如何采集資料

位元組碼插樁原理

位元組碼插樁涉及到Android的打包建構流程。首先我們看下Android應用程式的打包流程,如下圖:

Android網絡性能監控方案背景問題與挑戰實作方案

從上圖可知,我們隻需要在 javac 之後 dex 之前周遊所有的位元組碼檔案,并按照一定的規則過濾修改就可以實作位元組碼的插樁。

從Android Gradle 1.5.0 開始,Google官方提供了Transform API。通過Transform API,允許第三方以插件的形式,在Android應用程式打包成dex檔案之前的編譯過程中操作.class檔案。

Android網絡性能監控方案背景問題與挑戰實作方案

Android編譯器中的TaskManager将每個Transform串起來,第一個Transform接收來自javac編譯的結果,以及已經拉取到本地的第三方sdk(jar、aar),還有resource資源。這些編譯的中間産物,在Transform組成的鍊條上流動,每個Transform節點可以對class進行處理再傳遞給下一個Transform。常見的混淆、Desugar等的實作就是封裝在一個個Transform中。而自定義的Tranform會插入到這個Transform鍊條的最前面,是以開啟混淆的情況下通過自定義Transform對位元組碼進行修改也是先修改位元組碼再混淆。

網絡庫調研

除了系統自帶的網絡庫HttpUrlConnection,在android平台還有很多優秀的第三方網絡庫,大部分App開發會使用第三方的網絡庫來發起網絡請求。

Android網絡性能監控方案背景問題與挑戰實作方案

從上表中主流網絡庫的底層實作來看,我們隻要支援OkHttp、HttpUrlConnection和HttpClinet的資料采集就能滿足主流網絡庫的性能監控需求。

Android網絡性能監控方案背景問題與挑戰實作方案

我們對應用市場上Top1000的App進行了分析,按內建數量排序依次是okhttp3&okhttp4、volley(HttpUrlConnection)、okhttp2和httpclient。其中okhttp網絡庫占比将近80%,是以我們優先實作了okhttp網絡庫的監控實作。

okhttp網絡庫的監控實作

okhttp網絡庫家族主要包括okhttp2、okhttp3和okhttp4。其中okhttp3版本分布衆多,底層實作變化也最多,而okhttp2的底層實作和okhttp3的早期版本相近,okhttp4是okhttp3的kotlin版本的實作。是以我們主要介紹下okhttp3上的監控實作。

Android網絡性能監控方案背景問題與挑戰實作方案

上圖是okhttp3.12.0版本的實作架構,我們在網絡庫的具體邏輯裡注入代碼來采集需要的資料。

okhttp3版本衆多,從3.0.0-3.14.9已經有超過40個版本,對于每一個代碼注入的位置都需要確定再各個版本上能正常工作。是以實作okhttp3的無痕埋點,版本适配需要耗費大量的工作。

資料上報

資料上報,除了需要考慮加密、鑒權、壓縮等方面,還需要能確定盡可能少的丢失日志,同時還需要控制資源的占用來降低對上層業務的影響。具體實作主要包括兩方面:

• 緩存:支援記憶體緩存和磁盤緩存兩級緩存。需要實作業務隔離,多個業務使用緩存功能時可以做到互不影響。

• 上報:由于APM産生的日志較多,為了控制并發數和記憶體,我們使用了一個業務共享的線程池和排程隊列。排程隊列最多緩存10條批量日志,如果超出10條會立即将日志放入磁盤緩存。另外在上報前提供了日志預處理的開放接口友善業務層對日志做處理,比如抽樣、聚合等功能。

後續計劃

EMAS網絡性能監控已經對外開放,産品詳情:

https://www.aliyun.com/product/emascrash/apm

後續我們會根據客戶實際需求去逐漸完善功能。下一步計劃實作的需求包括:

• 支援HttpUrlConnection、HttpClient等網絡庫。

• 支援body資料的采集上報,讓客戶可以感覺、定位和解決在網絡連通性正常,但服務端下發異常資料導緻端上業務出現異常的問題。

• 支援日志資料端上預聚合,降低服務端存儲壓力。

• 支援socket請求的監控。

歡迎大家積極留言,提出你們的寶貴意見和建議,非常感謝!釘釘搜尋35248489,加入阿裡雲雲原生應用研發平台EMAS技術交流群,探讨最新最熱門的應用研發技術和實踐。

繼續閱讀