移動(dòng)端監(jiān)控體系之技術(shù)原理剖析

作者：伯樂(lè)專欄/佳樂(lè) 2017-03-02 12:39:04

在這樣一個(gè)注重用戶體驗(yàn)的時(shí)代，APM 技術(shù)快速發(fā)展，國(guó)內(nèi)更是百花齊放，最近對(duì)各個(gè)公司的 APM 產(chǎn)品有一個(gè)調(diào)研，并在此基礎(chǔ)上進(jìn)行了自己的實(shí)踐。這里就從 iOS 的角度出發(fā)，談?wù)勛约簩?duì)移動(dòng)端 APM 的技術(shù)上的理解，并提供相對(duì)應(yīng)的實(shí)例。

[[184536]]

何為 APM

APM 的全稱是Application performance management，即應(yīng)用性能管理，通過(guò)對(duì)應(yīng)用的可靠性、穩(wěn)定性等方面的監(jiān)控，進(jìn)而達(dá)到可以快速修復(fù)問(wèn)題、提高用戶體驗(yàn)的目的。

國(guó)內(nèi)各大公司都有自己的一套監(jiān)控體系，這個(gè)系統(tǒng)可能是自己研發(fā)，也可能是第三方提供，當(dāng)然對(duì)于這個(gè)數(shù)據(jù)為王的時(shí)代，很多有實(shí)力的公司傾向于自主研發(fā)，掌握核心數(shù)據(jù)。比較有代表性的 APM 產(chǎn)品有：聽(tīng)云、阿里百川、騰訊 bugly、NewRelic、OneAPM、網(wǎng)易云捕等

說(shuō)到監(jiān)控，那么指標(biāo)是我們所關(guān)注的呢?如下所示

網(wǎng)絡(luò)請(qǐng)求：成功率、狀態(tài)碼、流量、網(wǎng)絡(luò)響應(yīng)時(shí)間、HTTP與HTTPS的 DNS 解析、TCP握手、SSL握手(HTTP除外)、首包時(shí)間等時(shí)間
界面卡頓、卡頓堆棧
崩潰率、崩潰堆棧
Abort 率：也就是由于內(nèi)存過(guò)高的等原因，被系統(tǒng)殺死的情況
交互監(jiān)控：頁(yè)面加載時(shí)間、頁(yè)面的交互痕跡
維度信息：地域、運(yùn)營(yíng)商、網(wǎng)絡(luò)接入方式、操作系統(tǒng)、應(yīng)用版本等
其他：內(nèi)存、幀率、CPU使用率、啟動(dòng)時(shí)間、電量等

聊聊原理

卡頓檢測(cè)

當(dāng)應(yīng)用發(fā)生卡頓的時(shí)候，一般會(huì)伴隨著掉幀，所以幀率是最容易想到的指標(biāo)來(lái)判斷卡頓。對(duì)于線下的測(cè)試環(huán)境，我們可以使用幀率來(lái)對(duì)開(kāi)發(fā)做一些提示，告訴他們可能發(fā)生了卡頓。但是幀率不穩(wěn)定性較高，所以一般會(huì)采取另一種方式來(lái)做卡頓檢測(cè)。那就是Runloop，對(duì)于細(xì)節(jié)可以查看 Runloop 源碼，會(huì)發(fā)現(xiàn)對(duì)于事件的處理主要就是在kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting狀態(tài)之間,還有kCFRunLoopAfterWaiting之后。那我們就可以對(duì)兩個(gè)狀態(tài)進(jìn)行監(jiān)控，如果消耗時(shí)間太久，就代表著卡頓的發(fā)生。

阿里百川

上圖摘自阿里百川，如圖所示，我們會(huì)對(duì)卡頓次數(shù)做一個(gè)判斷，如果次數(shù)為1，但時(shí)間超時(shí)，則為單次耗時(shí)較長(zhǎng)的卡頓，如果次數(shù)到達(dá)閥值，則證明是連續(xù)短時(shí)間卡頓。

當(dāng)卡頓發(fā)生之后，我們?yōu)榱硕ㄎ唬瑫?huì)收集當(dāng)時(shí)的一個(gè)堆棧情況，在此你可以使用 PLCrashReporter 來(lái)做，也可以自己研發(fā)一個(gè)堆棧收集庫(kù)(可參考http://www.jianshu.com/p/7e4c7b94ca36來(lái)做)

對(duì)于實(shí)例，網(wǎng)上已經(jīng)有很多開(kāi)源的項(xiàng)目，你可以參考https://github.com/suifengqjn/PerformanceMonitor

崩潰檢測(cè)

對(duì)于崩潰的情況，一般是由 Mach異常或 Objective-C 異常(NSException)引起的。我們可以針對(duì)這兩種情況抓取對(duì)應(yīng)的 Crash 事件。

Mach 異常捕獲

如果想要做mach 異常捕獲，需要注冊(cè)一個(gè)異常端口，這個(gè)異常端口會(huì)對(duì)當(dāng)前任務(wù)的所有線程有效，如果想要針對(duì)單個(gè)線程，可以通過(guò) thread_set_exception_ports注冊(cè)自己的異常端口，發(fā)生異常時(shí)，首先會(huì)將異常拋給線程的異常端口，然后嘗試拋給任務(wù)的異常端口，當(dāng)我們捕獲異常時(shí)，就可以做一些自己的工作，比如，當(dāng)前堆棧收集等。

對(duì)于如何注冊(cè)一個(gè)異常端口，這里有示意圖和 PLCrashReporter https://github.com/plausiblelabs/plcrashreporter可以參考

Unix 信號(hào)捕獲

對(duì)于Mach 異常，操作系統(tǒng)會(huì)將其轉(zhuǎn)換為對(duì)應(yīng)的 Unix信號(hào)，所以如果你對(duì)Mach不熟悉的話，也可以通過(guò)注冊(cè)signalHandler的方式來(lái)做信號(hào)異常。對(duì)于實(shí)例，你可以參考https://github.com/xcysuccess/iOSCrashUncaught

signal(SIGHUP, signalHandler); 
 
signal(SIGINT, signalHandler); 
 
signal(SIGQUIT, signalHandler); 
 
  
 
signal(SIGABRT, signalHandler); 
 
signal(SIGILL, signalHandler); 
 
signal(SIGSEGV, signalHandler); 
 
signal(SIGFPE, signalHandler); 
 
signal(SIGBUS, signalHandler); 
 
signal(SIGPIPE, signalHandler);

NSException 捕獲

對(duì)于NSException異常，也比較容易處理，通過(guò)注冊(cè)NSUncaughtExceptionHandler捕獲異常信息即可，將拿到的NSException細(xì)節(jié)寫(xiě)入Crash日志，上傳到后臺(tái)做數(shù)據(jù)分析

// register the uncaught exception handler 
 
SetUncaughtExceptionHandler(&handler);

Abort 率檢測(cè)

目前對(duì)于內(nèi)存過(guò)高被殺死的情況是沒(méi)有辦法直接統(tǒng)計(jì)的，一般通過(guò)排除法來(lái)做百分比的統(tǒng)計(jì)，原理如下

程序啟動(dòng)，設(shè)置標(biāo)志位
程序正常退出，清楚標(biāo)志
程序Crash，清楚標(biāo)志
程序電量過(guò)低導(dǎo)致關(guān)機(jī)，這個(gè)也沒(méi)辦法直接監(jiān)控，可以加入電量檢測(cè)來(lái)輔助判斷
第二次啟動(dòng)，標(biāo)志位如果存在，則代表Abort一次，上傳后臺(tái)做統(tǒng)計(jì)

阿里百川

交互監(jiān)控

對(duì)于頁(yè)面的加載時(shí)間，這個(gè)比較容易實(shí)現(xiàn)，直接通過(guò)Runtime hook對(duì)應(yīng)的生命周期方法即可，比如 viewDidLoad、viewWillAppear等

對(duì)于用戶的交互痕跡，比如點(diǎn)擊了那個(gè)按鈕、跳轉(zhuǎn)到了那個(gè)頁(yè)面，這些信息偏于用戶行為的收集，我們也獨(dú)立研發(fā)了一個(gè)無(wú)埋點(diǎn)的SDK，專門(mén)來(lái)做用戶行為數(shù)據(jù)的收集與分析，核心也是基于 hook AOP的思想。細(xì)節(jié)可以參考我同事的作品

網(wǎng)絡(luò)監(jiān)控

對(duì)于成功率、狀態(tài)碼、流量，以及網(wǎng)絡(luò)的響應(yīng)時(shí)間之類的，我們可以主要可以通過(guò)兩種方式來(lái)做

針對(duì)URLConnection、CFNetwork、NSURLSession三種網(wǎng)絡(luò)做Hook，hook的具體技術(shù)可以是method swizzle 也可以是Proxy、Fishhook之類的
也可以使用 NSURLProtocol 對(duì)網(wǎng)絡(luò)請(qǐng)求的攔截，進(jìn)而得到流量、響應(yīng)時(shí)間等信息，但是NSURLProtocol有自己的局限，比如NSURLProtocol只能攔截NSURLSession，NSURLConnection以及UIWebView，但是對(duì)于CFNetwork則無(wú)能為力

對(duì)于第一種方式可以Hook哪些方法的，可以參考這個(gè)圖

對(duì)于 HTTP與HTTPS 的 DNS 解析、TCP握手、SSL握手(HTTP除外)、首包時(shí)間等時(shí)間的統(tǒng)計(jì)，稍有難度

但是，因?yàn)槲覀兯褂玫腢RLConnection、CFNetwork、NSURLSession底層都是 BSDSocket，所以可以嘗試在socket上動(dòng)手腳來(lái)實(shí)現(xiàn)效果，類似于通過(guò)ViewController的生命周期方法來(lái)統(tǒng)計(jì)頁(yè)面加載時(shí)間的做法，我們Hook socket相關(guān)的方法來(lái)做，比如通過(guò)hook socket連接時(shí)的 connect方法，拿到tcp握手的起始時(shí)間，通過(guò)hook SSLHandshake方法，在SSLHandshake執(zhí)行的時(shí)候拿到 SSL握手的起始時(shí)間等。目前聽(tīng)云已經(jīng)提供了 HTTP 的分段時(shí)間查詢功能，大家去體驗(yàn)下

int connect(int, const struct sockaddr *, socklen_t) __DARWIN_ALIAS_C(connect); 
 
OSStatus SSLHandshake(SSLContextRef ctx)

但是對(duì)于 iOS 9 Apple 加入 ATS 新特性，并要求開(kāi)發(fā)者使用 HTTPS，我在 iOS9、10上對(duì) HTTPS 網(wǎng)絡(luò)請(qǐng)求Hook socket方法時(shí)候，有一些方法hook 失效，猜想應(yīng)該是Apple 進(jìn)行了加固、加密，導(dǎo)致一些系統(tǒng)方法沒(méi)辦法hook，所以在 iOS9、10 上無(wú)法通過(guò)socket來(lái)取得HTTPS網(wǎng)絡(luò)的分段時(shí)間

不過(guò)apple在 iOS 10 推出一個(gè)API，可以在 iOS10 版本以上進(jìn)行網(wǎng)絡(luò)信息的收集

- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task didFinishCollectingMetrics:(NSURLSessionTaskMetrics *)metrics

打印結(jié)果如下

(Fetch Start) 2017-02-24 09:03:06 +0000 
 
(Domain Lookup Start) 2017-02-24 09:03:06 +0000 
 
(Domain Lookup End) 2017-02-24 09:03:06 +0000 
 
(Connect Start) 2017-02-24 09:03:14 +0000 
 
(Secure Connection Start) 2017-02-24 09:03:14 +0000 
 
(Secure Connection End) 2017-02-24 09:03:16 +0000 
 
(Connect End) 2017-02-24 09:03:16 +0000 
 
(Request Start) 2017-02-24 09:03:16 +0000 
 
(Request End) 2017-02-24 09:03:16 +0000 
 
(Response Start) 2017-02-24 09:03:16 +0000 
 
(Response End) 2017-02-24 09:03:16 +0000