蘇寧蛙測基于Instruments檢測iOS性能技術
原創【51CTO.com原創稿件】1.背景
在蘇寧智慧零售的戰略中，移動應用占據重要位置，線上應用的用戶體驗對于產品推廣有直接影響，而作為移動兩大重要陣營之一的iOS系統，應用上架前的性能指標顯得尤為重要。在不嵌入代碼的前提下，蛙測平臺需要獲得應用運行時的內存、CPU、FPS、冷啟動時間、熱啟動時間等數據，提供給開發部門，進行上線前優化。
蘇寧現有的iOS應用性能測試數據，基本都是開發人員在Mac環境下用Xcode工具，基于被測應用源碼或者特定簽名下通過原生的Instruments工具來獲取應用冷啟動時間、熱啟動時間、內存消耗、幀率等性能指標。
對于測試人員來說，首先沒有充足的Mac電腦提供，其次，出于代碼的保密性，無法為測試人員開發代碼權限，同時技術門檻也較高，為了讓測試人員也能進行iOS應用性能測試，基于代碼外黑盒方式獲取iOS應用性能數據，使用TraceUtility工具解析數據，在前端頁面用圖表方式為測試人員提供iOS應用性能測試服務。
2.技術選型和實現原理
2.1 Instruments工具組件介紹
Instruments是Xcode的一個工具集，為我們提供了強大的程序性能分析及測試能力。它是以一個獨立的 App 的形式存在的，你可以在 Xcode -> Open Developer Tool -> Instruments 中打開它。打開后功能組件頁面如下圖：
一、Time Profiler使用簡介：
- TimeProfiler見名知意：時間分析工具，它會按照設定的時間間隔(默認1毫秒)來跟蹤每一線程的堆棧信息(stacktrace)，并通過比較時間間隔之間的堆棧狀態，來推算出某個方法執行了多久，給出一個近似值。
二、CPU Activity Log CPU活動日志工具簡介;
- CPU Activity instrument工具給出了一個設備在做什么的記錄。
三、Core Animation動畫渲染使用簡介：
- Core Animation系要注意的一點是必須是真機調試，用于調試離屏渲染，繪圖，動畫，等操作，用于檢測FPS信息。
四、Activity Monitor內存使用情況簡介：
1)Summary(Summary of data) ：Process(進程)使用內存、CPU使用時長等摘要信息：
其中參數的含義如下：
- process id ——進程id
- process name ——進程名
- user name——用戶名
- %CPU——cpu占比
- threads——線程
- real mem——真正使用的內存
- virtual mem——虛擬內存
- architecture——架構
- cpu time——CPU時間
- sudden term——突然項(N/A：不適用)
2)Samples(a list of samples) ----一系列抽樣(即不同時間，CPU使用時間、內存使用情況的樣本值)
參數的含義如下：
- Physical Memory Wired——操作系統占用的內存
- Physical Memory Active——除操作系統外其他進程占用的內存
- Physical Memory Inactive——最近被釋放的內存
- Physical Memory Used——profiling當前進程時使用的總內存
- Physical Memory Free——當前的可用內存
- Total VM Size——虛擬內存的占用量
五、Energy Usage Level 簡介
查看應用的耗電量等級。電量使用level為0-20，1/20：表示運行該App，電池生命會有20個小時;20/20：表示運行該App，電池電量僅有1小時的生命。
2.2 instruments命令行調用方法
instruments命令
- usage: instruments [-t template] [-D document] [-l timeLimit] [-i #] [-w device] [[-p pid] | [application [-e variable value] [argument ...]]]
- -t是指定模板;
- -D 指定生成的.trace文件;
- -l 指定運行時間，此處單位為ms;
- -w 指定設備id(把設備通過usb連接電腦后，設備id可通過system_profiler SPUSBDataType查看);
application 即待測試的App名;
如下示例：
- 在fcbba9b83bf99c97e5d4d56d99a264d083d5e2cd設備上啟動”Time Profiler”模板運行com.suning.XX錄制30000ms的Profiler.trace文件，輸出路徑為/Users/monky/Work
- instruments -l 30000 -w fcbba9b83bf99c97e5d4d56d99a264d083d5e2cd -v -t “Time Profiler“ -D /Users/monky/Work/time Profiler.trace com.suning.XX
自定義多模板.tracetemplate文件
有時候需要同時監控好幾個模板，這個時候可以導出一個自己需要的.tracetemplate文件。
- a.首先打開instruments，在主界面選擇需要測試的模板，如下圖，通過右上角的+添加。
- b.選擇完所有需要的模板后，點擊Instruments -> file -> Save As Template 保存，記錄好保存的位置。
- c.然后就可以用自己的模板進行測試
如下實例：
- Instruments -w fcbba9b83bf99c97e5d4d56d99a264d083d5e2cd -v -t "CustomTemplate" -D templateData.trace com.suning.XX
2.3 instruments數據解析功能實現
我們生成一個自定義的數據模板MyTemplate.tracetemplate，根據instruments工具生成的trace文件，使用TraceUtility對文件進行解析，獲取存儲的信息。
Trace 文檔的基本結構
文檔結構的邏輯能從 Instruments 的交互邏輯看出來，一份文檔有一個目標設備，一個監測的進程和一組 profiling 模版，然后可以使用同一組模版進行多次 profile。而對應到 Instruments 的代碼中，一份文檔就是一個 XR Trace 對象，除了一些元數據，它還包含一個 XR Instrument 對象的數組，其中每一個，又包含了一個 XR Run 的數組。
所以接下去要做的事情就是，找到從不同模版的 XR Instrument 中讀取 XR Run 對象中的數據的方法，然后依次遍歷即可。
XR Instrument對象
數據讀取和保存的代碼主要在 InstrumentsAnalysisCore.framework 這個框架里，存儲格式也用了 SQLite，把各種讀取寫入查詢都抽象了出來，比如用戶在 Instruments 里用鼠標選了一段時間來看這段時間的數據，這樣的過濾操作就不需要在每個模版里單獨實現了。同時，因為數據的結構種類也比較有限，比如調用棧樹，樣本列表。
XRContext
在 Instruments 里，XRContext 就體現在模版列表下面的這個導航條。它是樹結構的，每次選中顯示一個 context，那從根結點到這個 context 就是一條 context path。XRContextContainer(通常是 view controller)保存著 context 的引用，叫做它的 contextRepresentation，而 XRContext 也引用一個真正展示它數據的 XRContextContainer(通常是 view)，叫做它的 container。
不同的模版當然會有不同的 contexts，但是有時候一個模版也會包含多個不同的 contexts，所以在用戶選擇不同的模版查看數據，或者從那個導航條里切換當前模版的不同的數據視圖的時候，當前的 context 就會變化，新的 context 的 -[XRContext display] 方法被調用，然后這個 context 會通過 -[XRContextContainer displayContext:] 傳給相對應的 XRContextContainer，然后這個 container(通常是 view controller)就可以加載數據，刷新視圖了。
也就是說文檔中的大部分數據只有在真正需要顯示的時候才會被讀取，從 Instruments 用戶的角度來看很容易理解，不過對于 TraceUtility 的用戶來說，就是需要知道，如果自己讀取的數據都是 nil，或者空數組之類的，就可以看看是不是忘記調用這個 -[XRContext display]方法了。
每一種XRContextContainer對象存儲的結構層次各有不同，以下給出三種結構解析方法。
TimeProfiler模板解析實例：
CPU Activity Log模板解析實例：
Connections 模板數據解析實例：
Search Paths
雖然說要調用 Instruments 的代碼只需要鏈接上它的 framework 就可以了，不過這里還有幾個值得一提的地方。
首先是編譯器搜索我們要鏈接的 framework 的目錄。參考 Xcode 項目配置的 FRAMEWORK_SEARCH_PATHS 變量。
- /Applications/Xcode.app/Contents/SharedFrameworks
- /Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/Frameworks
如果這個沒有設置對的話，鏈接的時候會報錯，沒法生成可執行程序。
然后是編譯好的程序在啟動過程中搜索這些動態鏈接的 framework 的目錄。參考 Xcode 項目配置的 LD_RUNPATH_SEARCH_PATHS 變量。
- /Applications/Xcode.app/Contents/SharedFrameworks
- /Applications/Xcode.app/Contents/OtherFrameworks
- /Applications/Xcode.app/Contents/Developer/Library/Frameworks
- /Applications/Xcode.app/Contents/Developer/Library/PrivateFrameworks
- /Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/Frameworks
如果這個沒有設置對的話，程序還是可以編譯，但是程序運行的時候會報錯。另外，這里不僅包含上一個配置里的目錄，還多了別的，是因為我們鏈接的 framework 還依賴了別的 framework，這些 framework 也需要在運行的時候由 dyld 一起加載。
最后是 Instruments 自己搜索 Packages 的目錄，這些目錄都在 Instruments.app 的安裝目錄下，而函數 NSString *PFTInstrumentsAppContents() 就是用來獲取這個安裝目錄的。它通過調用 +[NSBundle mainBundle] 來確定當前進程是 Instruments 的主 App 還是附加的命令行工具，然后返回正確的結果。
然而在我們的進程中，+[NSBundle mainBundle] 返回的結果并不能被這個函數正確識別和處理，所以我們需要 hook 這個方法來返回 Instruments.app 所對應的 bundle，從而使得 Instruments 能夠正確找到需要加載的包。
2.3解析后數據
Time Profiler解析出數據如下圖：
CPU Activity Log解析出數據如下圖：
Core Animation解析出數據如下圖：
Activity Monitor內存使用情況解析出數據如下圖：
Energy Usage Level解析出數據如下圖：
Connections解析出數據如下圖：
3.應用效果
蘇寧蛙測平臺將instruments檢測iOS性能技術應用在iOS穩定性測試中，將用戶提測的任務結果收集分析后制作成圖表展示，方便測試人員直接高效的獲得目標測試App在不同系統版本、機型上的性能表現，提高相關人員的產出效率。如下圖測試報告節選截圖：
4.總結
考慮到文章篇幅，本文僅介紹了蘇寧蛙測平臺在移動端性能檢測的冰山一角，有關于移動穩定性測試其他技術點將會在后續文章中進行分享。蛙測平臺會在大促期間力保每一個上線應用安全、穩定、健壯，站好第一班崗，為蘇寧軟件質量保駕護航。同時我們也會不斷成長，提升技術面，將“測試，原來可以如此簡單!”作為自己前進的目標，為蘇寧智慧零售戰略提供堅實保障。
作者：
錢夢奇，蘇寧易購IT總部數據云公司移動SDK工程師，主要從事測試工具與平臺的研發工作。專注于移動App開發、測試流程和測試工具開發，對移動端自動化測試、穩定性測試、性能測試、App開發技術和新理念實踐，積累了比較豐富的經驗。
【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】
