背景

移動互聯(lián)網(wǎng)時代，移動端極大部分業(yè)務都需要通過App和Server之間的數(shù)據(jù)交互來實現(xiàn)，所以大部分App提供的業(yè)務功能都需要使用網(wǎng)絡請求。如果因為網(wǎng)絡請求慢或者請求失敗，導致用戶無法順暢的使用業(yè)務功能，會對用戶體驗造成極大影響。

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

“阿里巴巴應用研發(fā)平臺 EMAS 是國內(nèi)領先的云原生應用研發(fā)平臺（移動App、H5應用、小程序、Web應用等），基于廣泛的云原生技術（Backend as a Service、Serverless、DevOps、低代碼等），致力于為企業(yè)、開發(fā)者提供一站式的應用研發(fā)管理服務，涵蓋開發(fā)、測試、運維、運營等應用全生命周期。”

問題與挑戰(zhàn)

網(wǎng)絡性能監(jiān)控在端上主要包括數(shù)據(jù)采集和數(shù)據(jù)上報。我們希望能盡可能采集有用的信息來幫助客戶發(fā)現(xiàn)、定位和解決網(wǎng)絡性能問題。我們面臨如下問題和挑戰(zhàn)：

?首先要解決的是網(wǎng)絡請求過程中，哪些階段會影響請求性能，如果發(fā)現(xiàn)網(wǎng)絡性能有問題，需要采集哪些數(shù)據(jù)來幫助用戶去定位和解決問題。

? android上主流的網(wǎng)絡框架有okhttp2、okhttp3、okhttp4、volley、retrofit、httpclient和系統(tǒng)提供的httpurlconnection等，在我們不確定客戶使用哪個網(wǎng)絡庫的哪個版本的情況下，如何盡量采集有用的信息。

? 網(wǎng)絡請求各個階段的數(shù)據(jù)采集都是離散的，如何保證單個請求各個離散的監(jiān)控數(shù)據(jù)能夠串聯(lián)起來，不和其他請求的監(jiān)控數(shù)據(jù)混在一起。

? 由于弱網(wǎng)環(huán)境下的網(wǎng)絡請求日志往往更有價值，需要盡可能將異常的網(wǎng)絡請求日志數(shù)據(jù)上報到服務端。

? 并發(fā)網(wǎng)絡請求時，需要確保在日志上傳時盡量不影響客戶正常業(yè)務。

實現(xiàn)方案

網(wǎng)絡性能監(jiān)控在端上的具體實現(xiàn)主要包含兩大模塊：
? 數(shù)據(jù)采集
? 數(shù)據(jù)上報
其中數(shù)據(jù)采集是整個SDK框架的核心。

整體架構概覽：

接入層：
網(wǎng)絡監(jiān)控屬于高可用產(chǎn)品的一部分，采用高可用統(tǒng)一接入的方式接入。
插件層：
高可用目前框架是通過插件式的方式集成各個業(yè)務，實現(xiàn)networkmonitor plugin集成到APM中，補充APM中網(wǎng)絡監(jiān)控部分。
邏輯層：
主要負責采集控制、數(shù)據(jù)管理、緩存管理和數(shù)據(jù)上報。
攔截器層：
整個網(wǎng)絡監(jiān)控的核心。為了采集更多的信息，我們選擇使用字節(jié)碼注入技術來實現(xiàn)網(wǎng)絡請求監(jiān)控功能。對OkHttp、HttpClient和HttpUrlConnection，分別實現(xiàn)Interceptor去采集不同網(wǎng)絡庫中網(wǎng)絡請求各個階段的數(shù)據(jù)，并在請求結束時完成采集進行上報。此外，通過自定義gradle plugin的方式，為各個網(wǎng)絡庫實現(xiàn)Injector和開關，控制在應用構建階段將Interceptor中各個采集的方法注入到對應網(wǎng)絡庫字節(jié)碼的埋點位置，從而實現(xiàn)在運行時網(wǎng)絡請求各個階段采集需要的數(shù)據(jù)。

數(shù)據(jù)采集

采集哪些數(shù)據(jù)

首先需要確定采集的數(shù)據(jù)范圍來幫助我們及時發(fā)現(xiàn)網(wǎng)絡請求的性能和異常等情況，另一方面也需要有額外的數(shù)據(jù)來輔助排查問題。所以我們采集的數(shù)據(jù)主要包括四個部分：
? 基礎數(shù)據(jù)。
? 性能數(shù)據(jù)。
? 異常信息。
? 事件序列數(shù)據(jù)。

基礎數(shù)據(jù)

?

? 請求url：對請求做聚合運算。
? 目標IP地址：對于多出口IP的客戶，支持IP地址維度的數(shù)據(jù)分析。
? dns解析結果：請求url的域名解析ip列表，用于分析是否存在域名劫持的問題。
? http code：根據(jù)http code確定請求狀態(tài)。
? 上行流量：包括整個請求上行header和body的總的流量，包含重試和重定向的上行流量。用于監(jiān)控上行流量開銷。
? 下行流量：包括整個請求下行header和body的總的流量，包含重試和重定向的下行流量。用于監(jiān)控下行流量開銷。
? 網(wǎng)絡庫類型及版本：對于客戶更換網(wǎng)絡庫或者升級網(wǎng)絡庫版本的情況，可以提供前后的網(wǎng)絡數(shù)據(jù)的差異。

性能數(shù)據(jù)

性能數(shù)據(jù)主要是采集整個網(wǎng)絡請求中各個階段的耗時情況來定位慢請求發(fā)生的階段。下圖列舉了http請求可能出現(xiàn)的各個階段。

所以性能數(shù)據(jù)部分需要采集下述各個階段的耗時數(shù)據(jù)：

• ?整個網(wǎng)絡請求耗時
• • ?dns耗時
• • ?建連耗時
• • • ?TLS建連耗時
• • ?數(shù)據(jù)上行耗時
• • • ?header上行耗時
• • • ?body上行耗時
• • ?數(shù)據(jù)下行耗時
• • • ?header下行耗時
• • • ?body下行耗時

異常信息

異常信息主要是收集網(wǎng)絡請求各階段出現(xiàn)異常時的異常棧的信息。比如常見的java.net.UnknownHostException、java.net.SocketTimeoutException等。

事件序列數(shù)據(jù)

事件序列數(shù)據(jù)主要是收集網(wǎng)絡請求各階段的監(jiān)控事件的信息，另外對于特定網(wǎng)絡庫的一些特殊的事件的監(jiān)控，比如okhttp的連接復用、自動重定向和失敗重試等對網(wǎng)絡耗時有影響的機制。最后將這些事件按時間順序排列。

比如在okhttp上dns被劫持的場景，我們通過基礎數(shù)據(jù)中的目標IP地址去判斷dns劫持情況，這個目標IP地址是在建立連接的時候去采集的。如果第一個請求發(fā)生了dns劫持的情況，那這個請求我們能正常識別的dns劫持已經(jīng)發(fā)生。如果后續(xù)的網(wǎng)絡請求復用了這個連接，因為不會再去建立連接，所以基礎數(shù)據(jù)中沒有目標IP地址，這時候就需要使用事件序列數(shù)據(jù)中的連接復用事件中的連接的url和目標IP地址來判斷是不是被劫持的請求。

如何采集數(shù)據(jù)

字節(jié)碼插樁原理

字節(jié)碼插樁涉及到Android的打包構建流程。首先我們看下Android應用程序的打包流程，如下圖：

從上圖可知，我們只需要在 javac 之后 dex 之前遍歷所有的字節(jié)碼文件，并按照一定的規(guī)則過濾修改就可以實現(xiàn)字節(jié)碼的插樁。

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

Android編譯器中的TaskManager將每個Transform串起來，第一個Transform接收來自javac編譯的結果，以及已經(jīng)拉取到本地的第三方sdk（jar、aar），還有resource資源。這些編譯的中間產(chǎn)物，在Transform組成的鏈條上流動，每個Transform節(jié)點可以對class進行處理再傳遞給下一個Transform。常見的混淆、Desugar等的實現(xiàn)就是封裝在一個個Transform中。而自定義的Tranform會插入到這個Transform鏈條的最前面，所以開啟混淆的情況下通過自定義Transform對字節(jié)碼進行修改也是先修改字節(jié)碼再混淆。

網(wǎng)絡庫調研

除了系統(tǒng)自帶的網(wǎng)絡庫HttpUrlConnection，在android平臺還有很多優(yōu)秀的第三方網(wǎng)絡庫，大部分App開發(fā)會使用第三方的網(wǎng)絡庫來發(fā)起網(wǎng)絡請求。

從上表中主流網(wǎng)絡庫的底層實現(xiàn)來看，我們只要支持OkHttp、HttpUrlConnection和HttpClinet的數(shù)據(jù)采集就能滿足主流網(wǎng)絡庫的性能監(jiān)控需求。

我們對應用市場上Top1000的App進行了分析，按集成數(shù)量排序依次是okhttp3&okhttp4、volley（HttpUrlConnection）、okhttp2和httpclient。其中okhttp網(wǎng)絡庫占比將近80%，所以我們優(yōu)先實現(xiàn)了okhttp網(wǎng)絡庫的監(jiān)控實現(xiàn)。

okhttp網(wǎng)絡庫的監(jiān)控實現(xiàn)

okhttp網(wǎng)絡庫家族主要包括okhttp2、okhttp3和okhttp4。其中okhttp3版本分布眾多，底層實現(xiàn)變化也最多，而okhttp2的底層實現(xiàn)和okhttp3的早期版本相近，okhttp4是okhttp3的kotlin版本的實現(xiàn)。所以我們主要介紹下okhttp3上的監(jiān)控實現(xiàn)。

上圖是okhttp3.12.0版本的實現(xiàn)框架，我們在網(wǎng)絡庫的具體邏輯里注入代碼來采集需要的數(shù)據(jù)。

okhttp3版本眾多，從3.0.0-3.14.9已經(jīng)有超過40個版本，對于每一個代碼注入的位置都需要確保再各個版本上能正常工作。所以實現(xiàn)okhttp3的無痕埋點，版本適配需要耗費大量的工作。

數(shù)據(jù)上報

數(shù)據(jù)上報，除了需要考慮加密、鑒權、壓縮等方面，還需要能確保盡可能少的丟失日志，同時還需要控制資源的占用來降低對上層業(yè)務的影響。具體實現(xiàn)主要包括兩方面：

? 緩存：支持內(nèi)存緩存和磁盤緩存兩級緩存。需要實現(xiàn)業(yè)務隔離，多個業(yè)務使用緩存功能時可以做到互不影響。
? 上報：由于APM產(chǎn)生的日志較多，為了控制并發(fā)數(shù)和內(nèi)存，我們使用了一個業(yè)務共享的線程池和調度隊列。調度隊列最多緩存10條批量日志，如果超出10條會立即將日志放入磁盤緩存。另外在上報前提供了日志預處理的開放接口方便業(yè)務層對日志做處理，比如抽樣、聚合等功能。

后續(xù)計劃

EMAS網(wǎng)絡性能監(jiān)控已經(jīng)對外開放，產(chǎn)品詳情：https://www.aliyun.com/product/emascrash/apm?后續(xù)我們會根據(jù)客戶實際需求去逐步完善功能。下一步計劃實現(xiàn)的需求包括：
? 支持HttpUrlConnection、HttpClient等網(wǎng)絡庫。
? 支持body數(shù)據(jù)的采集上報，讓客戶可以感知、定位和解決在網(wǎng)絡連通性正常，但服務端下發(fā)異常數(shù)據(jù)導致端上業(yè)務出現(xiàn)異常的問題。
? 支持日志數(shù)據(jù)端上預聚合，降低服務端存儲壓力。
? 支持socket請求的監(jiān)控。

歡迎大家積極留言，提出你們的寶貴意見和建議，非常感謝！釘釘搜索35248489，加入阿里云云原生應用研發(fā)平臺EMAS技術交流群，探討最新最熱門的應用研發(fā)技術和實踐。

?

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉載。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的Android网络性能监控方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。