透視寶是云智慧的新一代應用性能管理(APM)平臺，面向業務提供全棧性能監控、分析與管理的云端解決方案。對于移動應用的性能問題，透視寶是通過嵌入SDK來實現真實用戶體驗跟蹤的，支持Native、H5以及混合開發模式的應用監控，幫助開發人員實時發現與定位應用崩潰、加載緩慢等各種故障與性能問題。
透視寶在移動端嵌入的SDK被稱為Smart SDK，它是如何實現對不同移動應用用戶行為與體驗數據智能采集的呢，又有哪些實際應用呢，云智慧高級開發攻城獅Alvin將為您逐一解讀。
Smart SDK能干嘛?
總結一句話就是Smart SDK能夠解決開發者的痛點，給業務人員出決策參考意見。移動開發者的痛點就是各種Bug：卡頓、閃退、頁面加載慢、網絡連接超時，網絡被劫持;而業務人員的正確決策需要關注真實用戶的體驗。把這些需求歸結為技術實現，主要有3部分：網絡監控、事務監控、Crash信息收集。
詳細功能圖如下圖所示：
Smart SDK功能圖
針對HTTP的網絡數據收集主要分為以下指標：請求時間、網絡吞吐量和網絡錯誤，劫持分析等。
l 請求時間是指一個http請求從發起請求到接收到服務端的響應，這期間所經歷的時間。這個指標可以跟蹤后臺接口的響應是否正常，網絡環境是否正常。
l 網絡吞吐量是指單位時間內某一個url請求的次數。這個指標可以跟蹤后臺接口是否能夠響應大規模的請求。因為單位時間內某個接口的響應次數是100和10000，不管是技術層面還是業務層面，都會做出不同的響應。某個接口有大規模的請求，技術上就要做壓力評估，業務上則應該加大跟蹤和投入了。
l 網絡錯誤主要是跟蹤url請求過程中的錯誤，分為http本身的錯誤和因網絡狀況出現的錯誤。
針對Socket的網絡數據收集，主要包括Socket建立連接的耗時、DNS解析耗時、連接異常、數據讀寫異常的。
事務監控里面的用戶行為監控，能夠將所有的性能數據串起來，就可以滿足開發者和業務人員的需求，也就是我們常說的基于業務的性能監控。事務監控可以分為很多類，有用戶的操作，頁面的加載，圖片的渲染，線程操作，數據解析等。
l 用戶操作主要是監控APP里的點擊事件;
l 頁面加載要監控頁面加載周期的各個接口，除了用戶的操作外，APP的所有業務邏輯都是在頁面的生命周期函數中做的;
l 圖片加載也是影響APP性能的罪魁禍首之一，美工切的一張簡單的圖，在APP里渲染、顯示出來，會消耗不少的資源，因此將它作為一個性能消耗點來監控;
l 線程操作是導致主線程卡頓的主因;
l 數據解析雖然可以在子線程里做，但都是同步的，會導致頁面加載變慢。
APP崩潰一直是移動開發者最大的痛點，所以收集崩潰日志，快速定位問題根源，是最好的解決辦法。
而用戶信息收集可以將APP的性能數據和真實用戶對應起來，在發現APP性能問題后，第一時間與真實用戶建立聯系，溝通解決。
上面這些就是Smart SDK所能實現的功能。
Smart SDK實現原理
下面先以iOS應用為例說一下透視寶Smart SDK是如何實現應用性能監控的。iOS平臺的原生開發語言是Objective-C，具有動態運行時的特點，Cocoa框架提供了很多動態運行時接口可以對OC接口進行hook，也就是方法攔截。
通過方法攔截，就可以獲取到方法的參數值，方法執行開始、結束的時間戳。。。方法執行的性能數據就出來。
OC方法攔截原理圖
OC有一個很好用的語法，叫Category。通過Category，可以給原有的類(系統類，自己的類)添加一個新的接口，OC中叫selector(方法選擇器)，每一個方法，對應一個實現體(IMP)，類似函數入口地址。
通過Category新增一個SelectorN方法，使用動態運行時函數交換SelectorC與SelectorN的實現體，就實現了兩個方法的交換。SelectorC與SelectorN除了名字不一樣 ，其他的都一樣(參數和返回值)。開發者在調用SelectorC時，就會調用到SelectorN。我們的目的就達到了。
APP啟動，在類文件加載進內存時，系統會調用每一個類的load類函數(Swift工程里的Swift類沒有load函數，就調用initialize函數)，方法交換就是在這里面做的。
說完了iOS，再說說Android。Android的原生開發語言是Java，Java沒有提供動態運行時的接口來hook方法，但提供了字節碼改寫的方法。
先來看看經典的Android APP打包流程圖。
Android APP打包流程圖
所有資源文件(xml，png之類)、源代碼文件等都會經過java編譯器編譯成 .class的字節碼文件。再與其他庫文件一起，由Android sdk提供的dex工具，轉換成Android平臺的.dex文件，再通過apk打包工具打成apk包等等。
這一打包流程圖，翻譯一下，就是下面這張圖。
我標出了關鍵部位，沒有打馬賽克，對，這就是Smart SDK，在.class 文件準備轉換成.dex文件之前起的作用。
通過代理，在dex工具的接口中，使用ASM框架，把進入dex里面所有的.class文件讀出來，找到我們感興趣的方法，改寫(加些數據收集代碼)，再讓打包流程繼續，最終生成的apk包里，就有了我們的收集性能數據的代碼。
客戶案例分析
目前我們接觸次數最多的是百程旅行網，他們使用SDK已經有3個月時間了。下圖是他們最新版APP的性能情況，從數據上來看，他們的APP的性能真有待提高。
崩潰率確實有點高，優秀的APP崩潰率是千分之一到千分之二，所以他們亟需我們的SDK定位崩潰根源。通過抓取的崩潰信息，可以給他們進行初步參考，因為上傳到APP Store的APP產生的崩潰日志，需要對應的解碼文件才能查看具體崩潰在哪個文件的哪一行代碼上。
這里發現他們另外一個問題是網絡請求時間太長，在跟他們技術交流之后，初步判斷網絡請求時間長的有一部分原因，是因為線上數據混入了測試數據造成的結果。
一個杭州的用戶在6分鐘內發起了5800多次請求，請求錯誤率高達98%以上。當時他們不相信那是真實的，其實我也不太相信。后來再次跟開發人員交流，問那個網絡請求接口是否循環調用了，他回答是：請求接口在請求成功之前會一直循環調用，直到請求成功或是斷網。就是因為杭州這個用戶在一個時間點訪問的api有問題，導致循環請求。
還有一點，我們通過Smart SDK發現好些API報錯是找不到主機，客戶端的開發說是因為很多接口廢棄了，但客戶端還在調用，他們內部也明確說明要清理一遍廢棄的api。
目前，百程旅行網用Smart SDK已經找出了應用崩潰的根源，以及API慢、不可用的原因，每周會根據我們統計的數據做一次性能優化。
（新聞稿 2016-01-08）
