百年前，人們擷取資訊的方式是通過書籍、報紙；十年前，人們擷取資訊的方式是通過PC、網際網路；如今，在移動網際網路高速發展的環境下，人們擷取資訊的方式已經全面轉向了小小的手機。短短幾年裡，移動網際網路已經與我們的生活形影不離，一部手機走天下不再是夢想。
移動應用的商業價值在網際網路時代發生了變化，越來越多企業通過移動應用為使用者提供服務，應用改變了商業世界。2016年Q1，使用者從iOS和Android應用市場下載下傳的應用數量高達172億個，94%的應用以火箭般的速度進行更新。更新疊代越快，應用存在的性能問題就越突出，性能問題造成業務下降影響已經占到25%甚至更多，應用本身的變革迫在眉睫。
透視寶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和Android由于平台的差異性實作方式是不同的。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就可以完成這個過程了。
轉載于:https://my.oschina.net/cloudwise/blog/672384