阿里百川碼力APP監控 來了！

阿里百川碼力APP監控  來了！
這個APP監控 和手淘一塊兒成長
歷經千錘百煉 走過千BUG萬坑
現在百川起產品   爲了讓你的APP更好 用戶更爽！

 

在移動互聯網時代，一款應用是否成功，用戶體驗是一個關鍵的因素。APM的發展使得用戶體驗愈來愈完善，本文經過90年代互聯產品性能優化的發展過程到今天移動互聯網時代下的APM可用性監控體系，如何去解決日漸複雜的業務致使功能不斷迭代所突發的致命bug，以及日益增加的用戶和膨脹的數據致使流量過大所出現的一些問題。

 

 

在《黑客帝國》電影中較爲經典的一幕是讓Neo在紅藥丸和藍藥丸中作出選擇。紅藥丸做爲一個跟蹤程序，幫助Neo定位物理身體位置，不管在哪裏，出現任何問題都可以第一時間定位並解決。而開發者基本都知道，想解決大部分的功能性問題的難點基本就在定位上，而電影裏面出現的一些人工智能、機器學習、虛擬現實的技術，也只可以在科幻電影中才能看到。

季度活躍設備增加趨勢

今天，在移動終端爆發以及用戶需求的推進下，移動應用的「數量」和「體量」急速擴大，APP性能數據在優化產品上變得愈來愈重要，國內大批APM廠商彷彿一晚上間遍地開花，整個監控體系也從服務端到APP端再到H5端不斷的增強和改變策略來適應不一樣的場景需求，使得監控和優化的本質上已經發生了變化。

APM的雛形發展

在1996年時，Tivo與HP公司就從應用程序層面出發，他們認爲網絡無疑就是應用的速度。直至1998年，面向以組件爲中心基礎建設監控的APM產品出現，直到2011年，移動設備的普及和APP應用市場的爆發，讓你們對移動端的性能體驗要求也愈來愈苛刻。

在這個時候，國外的APM行業New Relic和AppDynamics已經在APM領域拔得頭籌，國內一些APM廠商看準移動的這個趨勢，APM彷彿一晚上之間遍地開花，直至今日，做爲國內比較具備表明性的APM廠商有：聽雲、OneAPM、雲智慧、博睿等，當前BAT領域也躋身這一領域，阿里百川碼力APM（簡稱「碼力APM」）也在雲棲大會中發佈公測。開發者無需從零開始構建性能探針、數據平臺和控制檯，就能夠經過可視化、可運維的方式長期監控應用性能、及時解決應用中存在的問題。 

▲ APM 業務與 IT 發展關係變遷

APM可用性度量體系

現在，國內APM業務競爭愈來愈激烈，你們紛紛在可用性、用戶體驗上發力。好比，你們用手機淘寶，明顯感受穩定性和流暢度比國內其餘電商APP好不少，這不只僅是由於他們有一堆優秀的開發工程師，更關鍵是其背後那一套完善的性能監控度量體系。

經過性能監控體系，app上發生的性能指標都會被實時上報，而碼力APM服務端會基於這些指標進行聚類和分析，聚合出問題和性能瓶頸，同時完善的日誌信息也將支持開發工程師及時修復和優化。

阿里技術專家陳武認爲，在性能優化方面，以往的度量是經過APP的打開率來進行對比，不少都是很是主觀。而度量體系裏面面臨的一個很大的問題是常態化。那麼，應該如何創建起這一套可視化的性能度量的體系呢？

阿里百川將影響用戶使用的性能指標分爲可用性度量和體驗度量。

一、 可用性度量

可用性包含app可用性和服務可用性。app可用性問題中最多見的就是crash，而用戶遇到crash以後，大部分會選擇直接卸載app；服務可用性問題則包含網絡鏈接和服務端錯誤，這類問題每每可能形成用戶購買、訂閱等關鍵操做不可用，從而致使資損，而這類問題若長期未能解決，也會致使用戶流失。

這類問題須要第一時間被修復，越早修復，止損的效果就越好。

這須要客戶端探針具備強大的採集能力。探針SDK將負責採集用戶因爲線程異常、內存溢出、手機殺進程等各類緣由致使的崩潰，並捕獲到儘可能全面的環境信息，和用戶操做軌跡來幫助開發者還原用戶操做，定位問題。同時，對網絡請求部分也是一樣，探針SDK須要支持自動採集網絡性能指標，並捕獲錯誤網絡請求的日誌，來輔助開發工程師解決問題。

可是探針在用戶app端採集的均是單一的事件，如有1000個用戶出現可用性問題，那麼服務端接收到的可能就是1000份日誌。讓開發工程師在海量的日誌中排查問題，顯然可行性不高。這就須要APM服務端實時對這些日誌進行語義分析以及高效的聚類，好比，將1000條用戶日誌聚合爲3個問題，經過控制檯反饋給開發者。這將大大提高開發工程師排查和解決問題的效率。

二、 APP體驗度量

APP體驗是影響用戶留存和活躍的關鍵，你們對APP使用過程當中「如絲般順滑」都具備自然的好感。可是目前市場大部分APP的體驗依舊很是差，用戶常會面對卡頓、圖片加載失敗、頁面長時間等待等各類不良體驗。這個時候，很是須要有一個系統體系化的去陳列和度量這些體驗類問題。

APM控制檯對卡頓的處理方式和崩潰相似，同類型的卡頓將被聚類在一塊兒，發生該卡頓的用戶詳細日誌也聚合在一塊兒能夠翻頁查閱。而對圖片加載失敗等，頁面元素沒法正常顯示的問題，則能夠關注該圖片所在靜態資源的服務主機是否異常（單分鐘請求量過多、圖片過大等）。若該靜態資源服務正常，則能夠關注請求該圖片的URL的錯誤率，能夠反推是否爲圖片自己的問題。

在性能優化的量化方面，如何幫助企業去作定製？陳武認爲，應該串聯關鍵路徑所須要的所有URL，從關鍵路徑總體來看服務的健康度指標，而非關注所有的URL。好比經過網絡性能監控，開發者無需對全部的URL進行關注，不一樣的開發者關注的核心業務不一樣，你們關注的URL也不同。好比，在電商的場景，一個關鍵的路徑是用戶經過登陸，打開商品，進入詳情，而後下單到支付，經過把對應的關鍵路徑全部的URL整合在一塊兒，保障這條關鍵鏈路的性能，纔可以強化核心業務的服務以及穩定性。

APM的可用性檢測方式

▲ 阿里百川碼力APM的監控體系

對於增強應用的可用性，APM通常都採起應用監控結合服務監控的形式，使得開發者實現端到端的全鏈路性能管理。在碼力APM監控體系中，阿里巴巴技術專家熊奇介紹了碼力APM在監控體系裏面的應用監控、服務監控、數據庫以及消息推送等性能監控，主要經過如下方式來完成：

★ 在應用監控上，採集了iOS、Android應用的內存、CPU、崩潰、網絡等方面的性能數據；

★ 在服務監控上，支持Tomcat、Jetty、JBoss容器和Spring、Struts等框架的性能檢測；

★ 支持MySQL等SQL數據庫和Redis、Mem cache等NoSQL數據庫的性能檢測；

★ 碼力APM還提供了支持淘寶消息服務TMC、分佈式框架Dubbo、淘寶API調用的性能檢測。

對於數據採集以後會統一進入能夠承載海量數據的存儲系統和日誌系統，統計系統會利用落地的數據完成數據的計算處理、生成報表，幫助開發者長期跟蹤應用和服務的性能，而告警系統則會根據規則在問題發生時發出短信、郵件等即時告警，從而幫助開發者及時解決問題，下降損失。

可用性的度量檢測方式-性能

在應用開發時，程序錯誤、主線程卡頓和資源使用超過系統限制致使的崩潰，是最嚴重、也是須要首先解決的問題。

一般開發者會藉助模擬器、Instrument或者自動化測試發現一部分問題，可是測試每每難以覆蓋用戶使用場景下的設備、網絡等環境。若是藉助於社交媒體或者郵件反饋渠道，雖然能夠有限地拿到真實的用戶反饋，可是用戶每每不能清楚的描述出復現問題所需的信息，往復溝通成本極高。因此，在客戶端上，碼力APM經過如下檢測方式來收集應用崩潰信息。

碼力APM在信號捕獲方式中，經過sigaction設置信號中斷時的回調，這樣，就能夠在回調中根據程序運行狀態生成對應的崩潰日誌。此外，對於SIGARBT(abnormal termination)，咱們還須要經過NSSetUncaughtExceptionHandler來獲取未捕獲異常的堆棧，來補全崩潰信息。

然後，把崩潰日誌上報到碼力APM，會依據崩潰日誌的堆棧信息，聚合同一類型的崩潰後寫入數據存儲。同時，告警系統能夠依據崩潰次數、崩潰率等規則，即時發出告警。

此外，碼力Apm提供了dSYM上報腳本，在Xcode的build phrase中添加腳本，就能夠在編譯成功後自動上報dSYM文件。經過對dSYM文件的解析，從新聚合後寫入數據存儲，聚合能夠減小高達90%數據庫行數；同時，也實現了崩潰日誌符號化。不依賴mac環境符號化，更好地利用雲計算平臺服務更多開發者。

第二種技術是卡頓檢測，卡頓檢測的基礎是RunLoop，經過RunLoop Observer監聽主線程RunLoop狀態的變動。在這裏，把RunLoop看成在操場上跑圈的運動員，把Before Sources當作每圈的起點，同時另外開啓一條線程做爲計時員，每5秒判斷一次RunLoop是否跑過一圈。若是5秒內RunLoop沒有完成一次RunLoop，則視爲主線程卡頓。在發現主線程卡頓後，會生成卡頓日誌，若是是復現的卡頓，能夠選擇不重複上報。

此外，針對設備不一樣的運行時期，如啓動階段、後臺階段、空閒階段，咱們會動態調整閾值，下降檢測的開銷。

對於沒法經過信號捕獲、卡頓檢測的崩潰，碼力APM引入了應用停止檢測，停止檢測雖然不能還原崩潰現場，可是能夠揭示問題的存在。在應用進入active狀態時，碼力APM在持久存儲上設立一個標誌位，表示程序在正常運行。在應用退出active狀態或檢測到崩潰時，碼力APM就清除持久存儲上的標誌位，表示程序在已知的狀況下退出。這樣，在下一次應用啓動時，若是持久存儲上的標誌位爲真，則說明應用上一次運行在未知狀況下退出，這種狀況碼力APM就計爲應用非正常停止上報。

同時，爲了過濾由於電量耗盡致使的關機，碼力APM還增長了電量檢測，在低電量時，清除標誌位，避免停止誤報。

可用性的度量檢測方式-網絡

請求錯誤、流量開銷高、被運營商劫持等網絡問題是應用開發時另外一類棘手的問題。固然咱們也能夠藉助模擬器、Instrument或者自動化測試發現簡單的網絡問題，可是測試難以覆蓋複雜的用戶網絡環境，也難以導出網絡性能數據進行長期比對監控。若是使用手工埋點的方式記錄網絡性能，一方面，咱們須要應對多種系統網絡接口，另外一方面，咱們須要同步應用網絡代碼和埋點代碼，維護成本將會居高不下。

爲了監控應用在真實網絡環境中的性能，碼力APM中引入了無痕埋點的網絡性能監控，在網絡檢測中引入三種注入技術，幫助開發者長期監控應用的網絡性能，優化產品用戶體驗。

第一種是Method Swizzling。每個NSObject類都包含一個isa指針，指向objc_class結構體，而每個objc_class結構體又包含一個methodLists指針，指向objc_method_list結構體數組，在objc_method_list裏又包含一個objc_method結構體成員，且每個objc_method包含一個method_imp指針，指向方法實現。

所以，只要能修改method_imp的值，咱們就能替換原有的實現。在<objc/runtime>中，經過class_getClassMethod和class_getInstanceMethod取得objc_method結構體指針，然後經過method_getImplementation取得方法的原始實現地址originIMP，以後在imp_implementationWithBlock生成新實現imp的參數block裏，調用原始實現，就能夠原有行爲先後加入網絡性能埋點行爲。最後調用method_setImplementation替換方法實現。這樣，任何調用都將使用新的實現。

第二種技術是Proxy。在Objective-C裏，NSProxy是除NSObject外惟一的根類。NSProxy是一個實現了NSObject協議的抽象類，它的正常運做須要子類override -methodSignatureForSelector:方法爲sel提供方法簽名，以及-forwardInvocation:方法來完成調用的轉發。

使用Proxy來注入NSURLConnection、NSURLSession等對delegate的回調。具體來講，在delegate proxy收到消息時，若是不是目標協議方法，則經過消息轉發機制，轉發給原delegate；若是是目標協議方法，則直接調用proxy實現，在proxy實現中委託調用原delegate；此外，多數協議和協議方法都是可選的，所以，在proxy的實現中須要實現-conformsToProtocol:和-respondsToSelector:方法來聲明proxy額外加入的協議和方法。這樣，咱們就能在不影響原有回調的同時，增長網絡性能埋點邏輯。

第三種技術是fishhook。使用fishhook來替換動態連接庫中的C函數實現，具體來講是CFNetwork和CoreFoundation中的相關函數。這裏，以開車的模型來解釋動態連接。設想一名新手司機開車從巴黎到羅馬，由於他不知道路線，因而他先去諮詢老司機；老司機告訴他正確的線路，這一次他可能還會繞點路，但下一次，他就會按照老司機的建議直接開到羅馬。

相應的，在程序運行時，動態連接的C函數dynamic(...)地址記錄在__DATA segment下的__la_symbol_ptr中；初始時，程序只知道dynamic函數的符號名而不知道函數的實現地址；首次調用時，程序經過__TEXT segment中的__stub_helper取得綁定信息，經過dyld_stub_binder來更新__la_symbol_ptr中的符號實現地址；這樣，再次調用時，就能夠經過__la_symbol_ptr直接找到dynamic函數的實現；若是咱們須要替換dynamic函數的實現，只須要修改__la_symbol_ptr便可。具體的實現方式，能夠參閱Facebook的開源框架fishhook。

增強可用性的優化手段

經過以上兩種檢測方式，基本可以大部分的性能和網絡需求，使得開發者可以知足現在移動互聯網下用戶的苛刻的需求，那麼，創建起來的度量體系後，瞭解的具體的問題後，咱們應該如何去解決這些問題來提高可用性呢？

一、網絡安全

運營商、DNS被劫持問題是應用開發時一類棘手的問題， 解決方案也比較多。51信用卡技術總監汪睿認爲，51信用卡做爲金融屬性的產品，基於安全考慮會放在第一位。解決方案主要是基於全棧HTTPS的方案來處理，但會帶來一些成本和性能上的損耗。甚至能夠像FaceBook、google等一些解決方案，使用HTTP2.0方式，這取決於公司和開發者自身去評估實現的成本。汪睿還介紹了早起的一個過渡方案，那就是HTTP的DNS方式，經過獲取一個IP表經過IP來直接鏈接，能夠避免HTTP劫持的問題。

而網絡是一個端到端的技術，阿里高級技術專家陳武認爲，從電商的場景看，首先要保證服務端的穩定性，服務端能夠有反刷，限流，單元化，異地容災，服務降級等策略保證鏈接的穩定性。另外，客戶端的角度主要看鏈接鏈路和數據量。鏈路裏面資源能夠作多CDN的備份，經過HTTP DNS或者HTTPS，HTTP2.0來反劫持。在鏈路穩定的基礎上，接着去保證傳輸的效率，這裏面能夠經過就近接入，鏈接複用，提高壓縮率，使用二進制協議等技術來減小包大小。固然，這裏面最重要的是端到端的網絡監控體系，這樣在網絡服務治理上會更有抓手。

二、系統降級

降級的解決方案，是系統性能保障的最後一道防線，從性能優化的角度上說，沒有100%完善的設計，總會有一些意料突發的狀況致使性能惡化。因此，在系統設計時，必須作好降級設計。

餓了麼移動首席架構師王朝成認爲，在餓了麼517大促活動上，服務器端承受很是大的壓力，這個時候會經過降級部分服務的方式，來確保大促秒殺這種場景得以正常運行。可是，在用戶端上，以及APP，還在不斷積極的發送用戶請求和數據，反而增長服務器集羣的壓力。這個時候，王朝成表示，他們會考慮把一部分的SDK或者APP上的服務也進行降級，來減小服務端在分析數據上的壓力。

降級分爲手動降級和智能降級，在策略上分爲流量降級、效果降級、功能性降級。流量降級主要表如今經過主動拒絕處理部分流量早餐部分用戶服務不可用。而效果降級和功能性降級都表現爲服務質量的降級，一個是經過在流量高峯時期用相對低質量、低延時的服務來保障全部用戶的服務可用性，另一個是經過減小功能的方式來提升用戶的服務可用性。

三、網絡性能

從數據結構上，須要根據不一樣的業務場景來選擇合適的數據結構，在數據流量較少的狀況可能客戶端上表現不出什麼區別，當在數據流量過大，且數據結構複雜的時候極可能就是直接影響到APP的性能。

相似餐飲領域「餓了麼」這樣的應用，數據發送的頻率使得據量會很是大，對用戶來講可能沒有什麼感知，可是商家接收大量的訂單，數據量影響很大，感知比較明顯。王朝成認爲，能夠考慮一些新的協議（Protobuf, Flatbuf）來優化數據量，好比HTTP2.0能夠壓縮http協議的header，使用encoder來減小須要傳輸的header大小，經過通信雙方各自cache一份header fields表，對於相同的數據再也不經過每次請求和響應發送，又減小了須要傳輸的大小。再一個是採起二進制的協議，只認0和1的組合，經過把原來http1.x的header和body部分用frame從新封裝，實現方便且健壯。經過內容壓縮與併發傳輸機制，在低速、不穩定的無線條件下，較少其http body的發送大小，改善用戶體驗和資源效率。

▲ http1.x和http2.0協議關係

同時，阿里高級技術專家陳武也表示，若是在鏈路沒有問題的狀況下，那麼必須在整個網絡傳輸層要儘可能快，否則很容易出現timeout。因此，第一要從協議層，在協議層裏面經過http2.0來減小包頭的壓縮，同時支持服務端push消息，且經過雙統統道，對通道複用更快。第二是從數據層，數據能夠經過二進制壓縮。在整個網絡連通率較低的時候，將打包拆成小包，達到很好的傳輸效果。

四、動態熱修復

所謂熱修復，就是使用熱補丁動態修復技術，經過向用戶發送Patch，在用戶無感知的狀況下完成一些致命bug的修復。51信用卡客戶端負責人汪睿認爲，在移動客戶端上最大的一個問題是發版，對於iOS的用戶來講，整個修復流程比較漫長。須要提交審覈，可是在這段時間有可能已經錯過不少用戶。他認爲，熱修復技術可以很快並及時的在線進行修復，一般在使用的過程當中就完成的修復過程。

在熱修復技術上，Android經常使用的是基於Android dex分包方案，而iOS能夠利用JSPatch，它可使得你用JavaScript書寫原生iOS APP，只須要在項目中引入極小的引擎，就能夠用JavaScript調用任何的Objective-C的原生接口。

總結

以上所談到的性能優化手段基本是爲了解決三種狀況所形成的問題：1. 日漸複雜的業務致使功能不斷迭代所突發的致命bug修復方式，2. 日益增加的用戶和膨脹的數據致使流量過大，3.網絡安全和內存開銷的問題。

本文經過不一樣的場景來分析移動性能優化的模式，能夠經過肯定場景下解決某一類型的問題。固然，咱們不能僅僅經過了解性能優化所解決的問題以及手段，更重要的是須要清楚該問題所發生的場景、緣由須要的成本。

做者 51CTO 林師授