頻頻卡頓崩潰？移動應用如何跟蹤定位性能問題

百年前，人們獲取信息的方式是通過書籍、報紙；十年前，人們獲取信息的方式是通過PC、互聯網；如今，在移動互聯網高速發展的環境下，人們獲取信息的方式已經全面轉向了小小的手機。短短幾年里，移動互聯網已經與我們的生活形影不離，一部手機走天下不再是夢想。

移動應用的商業價值在互聯網時代發生了變化，越來越多企業通過移動應用為用戶提供服務，應用改變了商業世界。2016年Q1，用戶從iOS和Android應用市場下載的應用數量高達172億個，94%的應用以火箭般的速度進行更新。更新迭代越快，應用存在的性能問題就越突出，性能問題造成業務下降影響已經占到25%甚至更多，應用本身的變革迫在眉睫。

影響用戶體驗的十宗罪

比起用戶流失來說，移動應用性能問題還會給用戶帶來更多的損失，我們看看影響用戶體驗的十宗罪：

當應用出現崩潰、錯誤時，便會引起關鍵業務中斷、收入下降等情況，進一步便會影響到產品生命周期價值；如果應用請求響應時間長，那么便會導致終端用戶體驗緩慢、用戶留存率下降的情況發生；如果是應用交互性能慢的話，那么頁面元素加載就會緩慢進而造成卡頓或是不完整造成的布局錯亂。

據統計，每天有 1400萬 設備發生崩潰，每月累計有高達 1.8 億 的設備遭遇應用崩潰。這些數字都是發生在真實的生產環境中，即使在上線之前進行過大量的測試，在生產環境中依然會發生，而且大部分都是特定機型上會發生莫名奇怪的崩潰問題，導致用戶行為的中斷，影響業務下降。

隨著手機使用量的增加，手機用戶對性能期望也在不斷提高，響應時間超過5秒，有50%用戶會放棄；30%用戶直接卸載；33%用戶會跑到競爭對手那里。企業必須時刻關注用戶使用APP真實感受，為用戶提供良好的體驗，才能實現應用的商業價值。

如何持續提升移動應用的用戶體驗

移動應用的發展與繁榮催生了移動應用性能管理(mAPM)需求爆發，而關注移動應用性能可有效持續提升用戶體驗。透視寶mobile APM正是為此而生，通過端到端一體化全業務流程監控平臺，及時發現和解決移動應用業務運維和運營過程中遇到的性能問題，幫助開發人員進行可持續性研發迭代，降低IT運維成本，減少用戶流失。

透視寶mobile APM 從五個維度解析移動應用性能

移動應用發布上線之后，由于缺少有效的性能監控手段，對于開發和運維來說其架構、應用、程序代碼的執行情況都是一個黑盒，無法感知到用戶使用APP的真實感受，無法預知應用發生了什么樣的問題，看不到業務具體數據到底是怎么執行，更沒辦法準確定位到問題，而APM通過以下五個重要維度能夠幫你把黑盒子打開。

1、 用戶從哪來，網絡接入性能怎么樣？

地域分析可以了解我們的用戶都是從哪些地域使用APP，各地的響應時間是否存在很大差異，耗時較高的地區根據網絡節點調整CDN，優化網站層面的性能問題。

2、 用戶使用的什么設備，不同運營商對網絡響應是否達標？

設備、運營商、APP版本分析可以幫忙了解用戶使用什么品牌的手機訪問APP應用，不同的終端存在不同的差異，據統計iPhone6 使用較為穩定，而華為設備發生崩潰幾率最低，通過這些設備、運營商、APP版本的分析結果可以在新版本迭代中安排重點測試和適配。

3、用戶做了什么操作，在APP中的用戶體驗如何？

用戶行為監控能夠將所有用戶在APP中的點擊操作與性能數據關聯，通過HTTP請求響應耗時，請求錯誤，崩潰等維度分析APP中最影響用戶體驗的用戶行為。并且可分析受到影響的每一位用戶的在APP中行為操作路徑及流程，協助研發人員還原用戶使用場景從而精準定位問題發生的原因。

4、APP中是否發生了崩潰、ANR等問題？

崩潰是APP應用中最影響用戶體驗的問題之一，而且是移動開發者最大的痛點，所以收集崩潰日志、快速定位問題根源是最好的解決辦法。崩潰分析可按APP版本，崩潰趨勢，設備型號，運營商，接入方式，地域崩潰等多個維度分析和統計。

崩潰分析可以解析崩潰堆棧定位發生崩潰的代碼片段和行數，并且通過收集分析用戶發生崩潰的設備，接入方式，內存，CPU使用率以及用戶操作的行為軌跡助研發人員能快速定位問題，還原案發現場。

5、APP前端頁面交互性能和Service端代碼執行效率

APP中的性能問題大體可以分為兩部分：1、前端頁面交互性能 2、后端Service端代碼效率。

前端頁面交互性能主要體現在頁面加載緩慢，請求錯誤異常，卡頓等方面，而目前webview在APP開發中已經非常普遍，對性能的監控需求也越來越強烈。我們提出白屏時間、頁面請求耗時分解、頁面加載資源耗時分解等性能指標，可以對頁面請求耗時診斷慢在哪個環節。

頁面響應時間分解，將整個H5頁面加載的耗時分解到網絡請求的每一個細節上去。如上圖主要包括：重定向起止時間、緩存起止時間、域名解析起止時間、TCP傳輸起止時間、請求起止時間、響應起止時間、Dom加載起止時間、頁面渲染起止時間等。

圖：H5頁面加載的資源時序圖，明確告知每一個資源類型的加載時間

APP端除了前端的性能問題需要關注，Service端的性能問題同樣不容忽視，由于篇幅問題本文不做重點介紹，但是需要介紹mobile端與service的端到端的特性。

端到端事物分析

針對移動端的事務我們可以診斷定位到耗時情況，除了前端頁面的資源加載占用大量資源外，Service代碼造成緩慢的因素同樣需要準確定位，所以透視寶提供了端到端事務分析。

移動端嵌入SDK，Service端部署Smart Agent，通過UUID關聯了APP中所有的請求事務，定位后端的代碼執行最慢的方法，SQL語言，參數等指標。

針對HTTP的網絡數據收集主要分為以下指標：請求時間、網絡吞吐量和網絡錯誤，劫持分析等。

請求時間 是指一個http請求從發起請求到接收到服務端的響應，這期間所經歷的時間。這個指標可以跟蹤后臺接口的響應是否正常，網絡環境是否正常。

網絡錯誤 主要是跟蹤url請求過程中的錯誤，分為http本身的錯誤和因網絡狀況出現的錯誤。

某個客戶的一個杭州用戶在6分鐘內發起了5800多次請求，請求錯誤率高達98%以上。當時他們不相信那是真實的，后來與客戶交流發現該網絡請求接口存在循環調用，請求接口在請求成功之前會一直循環調用，直到請求成功或是斷網，而這正是造成導致循環請求的真正原因。

還是這個客戶，我們通過Smart SDK發現他的很多API報錯是找不到主機，經確認APP開發在版本迭代過程中把很多接口廢棄了，但客戶端還在調用，通過HTTP錯誤和網絡錯誤請求分析就可以幫助客戶清理廢棄的API，保證我們的業務正常服務。

而做到這一切，只需要嵌入透視寶Smart SDK的兩行代碼， 5分鐘輕松實現對APP應用的性能監控，業務運營監控的需求。以往通過用戶投訴和反饋，開發總是最后一個發現問題，而被動的解決問題更是費時費力。使用透視寶后可以提前發現應用性能問題，快速迭代修復問題，避免用戶流失提升用戶體驗。

移動端性能管理技術實現

透視寶Smart SDK自動收集性能數據是不需要埋點的。iOS和And

roid由于平臺的差異性實現方式是不同的。Objective-C語言具有動態運行時的特性，因此iOS平臺使用Hook機制來攔截方法的執行，從而收集性能數據；而Java語言不具備這樣的特性，但能夠對字節碼進行改寫，因此Android平臺使用ASM框架動態注入代碼到相關的方法中收集性能數據。

iOS Smart SDK技術原理

iOS的Hook技術使用Objective-C提供的Method Swizzling機制。Method Swizzling是Objective-C的運行時技術，指的是改變一個已存在的選擇器對應的實現的過程，它依賴于Objectvie-C中方法的調用能夠在運行時進行改變——通過改變類的調度表（dispatch table）中選擇器到最終函數間的映射關系。

原理圖如下：

每一個Selector（選擇器）對應一個IMP（實現體），通過Method Swizzling可以動態改變這種對應關系。Swizzling通常被程序開發認為是一種巫術，容易導致不可預料的行為和結果。但是如果采取下面這些措施，Method Swizzling還是很安全的：

1、Swizzling應該在+load方法中實現。

Objective-C中每個類都有+load和+initialize兩個方法。這兩個方法會被Objective-C運行時系統自動調用，+load是在一個類最開始加載時調用，+initialize是在應用中第一次調用該類或它的實例的方式之前調用。這兩個方法都是可選的，都是只有實現了才會被執行。

因為method swizzling會影響全局，所以減少冒險情況就很重要。+load能夠保證在類初始化的時候就會被加載，這為改變系統行為提供了一些統一性。但+initialize并不能保證在什么時候被調用——事實上也有可能永遠也不會被調用，例如應用程序從未直接的給該類發送消息。

2、Swizzling應該在dispatch_once中實現。還是因為swizzling會改變全局，我們需要在運行時采取所有可用的防范措施。保障原子性就是一個措施，它確保代碼即使在多線程環境下也只會被執行一次。GCD中的diapatch_once就可以提供這些保障。

3、始終調用方法的原始實現。系統提供的 API為輸入和輸出提供規約，但它里面具體的實現其實是個黑匣子，在Method Swizzling過程中不調用它原始的實現可能會破壞一些私有狀態，導致程序運行不穩定。

Android Smart SDK技術原理

首先來看看Android app的打包流程

該圖翻譯成技術語言，如下圖

圖中標明了sdk中代碼的工作位置：

就是在 .class文件轉化成.dex文件的過程中，通過ASM框架改寫代碼的。通過對字節碼的讀寫，找到感興趣的方法，加入收集信息的代碼。原生的網絡請求、用戶行為、頁面加載等方面的性能數據，就是以這樣的方式收集到的。

透視寶端到端技術方案重點不在移動端，而在于后端。移動端只是針對從APP中發出的每一條網絡請求打上標記，后端節點上的Agent接收到該條請求，解析標記，記錄下來，并且打上該節點的標記。最終通過這些標記畫出該條請求所經過的所有節點的拓撲圖，將節點上的應用的性能指標關聯起來。

崩潰信息收集和分析

iOS的崩潰信息收集和分析原理

崩潰信息收集，通過系統提供的異常信息捕獲接口，設置回調函數，捕獲異常信息。通過解析解碼文件，將解碼文件與崩潰信息里的內存地址結合起來，分析出發生崩潰的位置和代碼段

通過設置系統異常信息收集的回調函數到系統相應的接口上，捕獲系統的異常信息。

崩潰信息解析過程：

1、從崩潰日志中獲取代碼行的地址偏移量。（已從前面的崩潰信息中獲取到）

1、 解析符號表文件dSYM, 使用dwarfdump命令從dSYM文件中抽取相關信息。比較常用的兩個命令：

dwarfdump -e --debug-info YourPath/YourApp.dSYM/Contents/Resources/DWARF > info.txt

dwarfdump -e --debug-line YourPath/YourApp.dSYM/Contents/Resources/DWARF > line.txt

其中，info.txt文件中包含類文件的具體信息，比如類名，方法名，方法的內存起止地址等。

如下圖所示：

由圖中可知，只要偏移量在0x000681c0和0x00068454之間的代碼，就對應JKBOverviewVC.m文件的 -[JKBOverviewVC tableView:cellForRowAtIndexPath:]函數。

具體崩潰在該函數的哪一行，通過line.txt文件中的內容得出

line.txt文件中，包含函數中每一行代碼的內存地址對應的相關信息，如下圖所示

崩潰日志中，偏移量在0x000681c0和0x00068454之間的代碼，在這個line.txt文件中就能找到具體的代碼行。至此，iOS的崩潰日志就分析完成了。

Android的崩潰收集原理

1. Java層的崩潰信息收集原理，如下圖所示：

Java 層的堆棧信息收集是通過定義一個Handler類去實現Thread.UncaughtExceptionHandler接口的void uncaughtException(Thread t, Throwable e)方法，然后，通過在Thread.setDefaultUncaughtExceptionHandler方法將我們定義的Handler和APP的線程關聯起來。在uncaughtException方法中去收集APP 沒有捕獲的異常，然后將其堆棧信息收集起來。

2.  Native層的崩潰信息收集原理，如下圖所示：

由于Android 底層使用的是linux內核，所以Native層先通過sigaction()函數去注冊我們需要監視的Crash相關的信號量，同時，修改相關信號量發生的回調函數，在回調函數中我們通過Android的libcorkscrew.so(5.0版本以下) 和 libunwind.so(5.0及以上版本)提供的打印堆棧函數去收集Native層的堆棧信息，然后通過JNI層回調到Java層，從而收集到native的信息和Java層當前的所有線程信息。

H5頁面的性能數據收集方案

H5頁面的性能數據采集通過注入js代碼來實現的。移動端的H5頁面展示過程，主要分為數據請求、數據加載、頁面渲染等。而其中數據加載是將H5頁面的數據從服務端一段一段的load到移動端，JS代碼的注入就是在這個階段完成的。

在數據load階段注入js代碼，待數據load完成之后渲染，這樣做既不會影響客戶代碼的執行，也能保證JS代碼能夠監控H5頁面的整個生命周期中的用戶操作和頁面加載情況。

由于移動端操作系統對webkit進行了高度封裝，開放出來的API還少，以致不能獲取H5頁面的詳細加載情況，只能借助于JS代碼，獲取頁面的performance參數，從而獲取到頁面加載的各個性能指標。

Q1：對于react native 是否也能支持？對于原生應用和這種類型的應用支持的程度是否一致？

A：我們目前沒有對React Native的應用做過測試。網絡請求的支持應該是與原生應用的支持一致的；系統級別的崩潰，支持程度也是一致的；加載H5和用戶行為事件的追蹤，支持程度應該有限。

以上結論，需要測試確定。假如不支持，我們也將經過迭代，解決該兼容問題。

Q2、H5中注入腳本會影響性能么？

A：JS代碼是存在SDK本地的，沒有新的網絡請求產生，JS代碼在H5頁面上工作的時候，并不是現場計算，而是直接取得performance的接口；同時修改系統的click事件冒泡取得標簽值和url，而不是進行click方法的動態bound，所以工作過程中的性能損耗微乎其微。

Q 3、除了UI上帶來的用戶體檢，耗電、網絡流量也是用戶所關注的。不是埋點式的行為數據收集，產生的數據量是怎么控的？

A：1、耗電量可以通過系統接口獲取到 2、網絡流量目前有統計，我們的每一條請求都會統計發送字節和接收字節。3、目前行為數據不支持可配置，只要是有事件發生的行為，都會記錄。下一步會支持用戶行為可配置。接下來我們會支持APP中用戶重點關心的用戶行為配置，而且這個建模過程會更加清晰簡單，只需要操作APP就可以完成這個過程了。

 

 

來自：http://mp.weixin.qq.com/s?__biz=MzAwNzA0NTMzMQ==&mid=2653201857&idx=1&sn=f1084dc107abef0f4e706fa081d26cd9&scene=4#wechat_redirect