【51CTO.com原創(chuàng)稿件】1.背景

在蘇寧智慧零售的戰(zhàn)略中，移動(dòng)應(yīng)用占據(jù)重要位置，線上應(yīng)用的用戶體驗(yàn)對(duì)于產(chǎn)品推廣有直接影響，而作為移動(dòng)兩大重要陣營之一的iOS系統(tǒng)，應(yīng)用上架前的性能指標(biāo)顯得尤為重要。在不嵌入代碼的前提下，蛙測(cè)平臺(tái)需要獲得應(yīng)用運(yùn)行時(shí)的內(nèi)存、CPU、FPS、冷啟動(dòng)時(shí)間、熱啟動(dòng)時(shí)間等數(shù)據(jù)，提供給開發(fā)部門，進(jìn)行上線前優(yōu)化。

蘇寧現(xiàn)有的iOS應(yīng)用性能測(cè)試數(shù)據(jù)，基本都是開發(fā)人員在Mac環(huán)境下用Xcode工具，基于被測(cè)應(yīng)用源碼或者特定簽名下通過原生的Instruments工具來獲取應(yīng)用冷啟動(dòng)時(shí)間、熱啟動(dòng)時(shí)間、內(nèi)存消耗、幀率等性能指標(biāo)。

對(duì)于測(cè)試人員來說，首先沒有充足的Mac電腦提供，其次，出于代碼的保密性，無法為測(cè)試人員開發(fā)代碼權(quán)限，同時(shí)技術(shù)門檻也較高，為了讓測(cè)試人員也能進(jìn)行iOS應(yīng)用性能測(cè)試，基于代碼外黑盒方式獲取iOS應(yīng)用性能數(shù)據(jù)，使用TraceUtility工具解析數(shù)據(jù)，在前端頁面用圖表方式為測(cè)試人員提供iOS應(yīng)用性能測(cè)試服務(wù)。

2.技術(shù)選型和實(shí)現(xiàn)原理

2.1 Instruments工具組件介紹

Instruments是Xcode的一個(gè)工具集，為我們提供了強(qiáng)大的程序性能分析及測(cè)試能力。它是以一個(gè)獨(dú)立的 App 的形式存在的，你可以在 Xcode -> Open Developer Tool -> Instruments 中打開它。打開后功能組件頁面如下圖：

一、Time Profiler使用簡(jiǎn)介：

• TimeProfiler見名知意：時(shí)間分析工具，它會(huì)按照設(shè)定的時(shí)間間隔(默認(rèn)1毫秒)來跟蹤每一線程的堆棧信息(stacktrace)，并通過比較時(shí)間間隔之間的堆棧狀態(tài)，來推算出某個(gè)方法執(zhí)行了多久，給出一個(gè)近似值。

二、CPU Activity Log CPU活動(dòng)日志工具簡(jiǎn)介;

• CPU Activity instrument工具給出了一個(gè)設(shè)備在做什么的記錄。

三、Core Animation動(dòng)畫渲染使用簡(jiǎn)介：

• Core Animation系要注意的一點(diǎn)是必須是真機(jī)調(diào)試，用于調(diào)試離屏渲染，繪圖，動(dòng)畫，等操作，用于檢測(cè)FPS信息。

四、Activity Monitor內(nèi)存使用情況簡(jiǎn)介：

1)Summary(Summary of data) ：Process(進(jìn)程)使用內(nèi)存、CPU使用時(shí)長(zhǎng)等摘要信息：

其中參數(shù)的含義如下：

• process id ——進(jìn)程id
• process name ——進(jìn)程名
• user name——用戶名
• %CPU——cpu占比
• threads——線程
• real mem——真正使用的內(nèi)存
• virtual mem——虛擬內(nèi)存
• architecture——架構(gòu)
• cpu time——CPU時(shí)間
• sudden term——突然項(xiàng)(N/A：不適用)

2)Samples(a list of samples) ----一系列抽樣(即不同時(shí)間，CPU使用時(shí)間、內(nèi)存使用情況的樣本值)

參數(shù)的含義如下：

• Physical Memory Wired——操作系統(tǒng)占用的內(nèi)存
• Physical Memory Active——除操作系統(tǒng)外其他進(jìn)程占用的內(nèi)存
• Physical Memory Inactive——最近被釋放的內(nèi)存
• Physical Memory Used——profiling當(dāng)前進(jìn)程時(shí)使用的總內(nèi)存
• Physical Memory Free——當(dāng)前的可用內(nèi)存
• Total VM Size——虛擬內(nèi)存的占用量

五、Energy Usage Level 簡(jiǎn)介

查看應(yīng)用的耗電量等級(jí)。電量使用level為0-20，1/20：表示運(yùn)行該App，電池生命會(huì)有20個(gè)小時(shí);20/20：表示運(yùn)行該App，電池電量?jī)H有1小時(shí)的生命。

2.2 instruments命令行調(diào)用方法

instruments命令

usage: instruments [-t template] [-D document] [-l timeLimit] [-i #] [-w device] [[-p pid] | [application [-e variable value] [argument ...]]] 

• -t是指定模板;
• -D 指定生成的.trace文件;
• -l 指定運(yùn)行時(shí)間，此處單位為ms;
• -w 指定設(shè)備id(把設(shè)備通過usb連接電腦后，設(shè)備id可通過system_profiler SPUSBDataType查看);

application 即待測(cè)試的App名;

如下示例：

在fcbba9b83bf99c97e5d4d56d99a264d083d5e2cd設(shè)備上啟動(dòng)”Time Profiler”模板運(yùn)行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文件

有時(shí)候需要同時(shí)監(jiān)控好幾個(gè)模板，這個(gè)時(shí)候可以導(dǎo)出一個(gè)自己需要的.tracetemplate文件。

• a.首先打開instruments，在主界面選擇需要測(cè)試的模板，如下圖，通過右上角的+添加。



• b.選擇完所有需要的模板后，點(diǎn)擊Instruments -> file -> Save As Template 保存，記錄好保存的位置。
• c.然后就可以用自己的模板進(jìn)行測(cè)試

如下實(shí)例：

Instruments -w fcbba9b83bf99c97e5d4d56d99a264d083d5e2cd -v -t "CustomTemplate" -D templateData.trace com.suning.XX 

2.3 instruments數(shù)據(jù)解析功能實(shí)現(xiàn)

我們生成一個(gè)自定義的數(shù)據(jù)模板MyTemplate.tracetemplate，根據(jù)instruments工具生成的trace文件，使用TraceUtility對(duì)文件進(jìn)行解析，獲取存儲(chǔ)的信息。

Trace 文檔的基本結(jié)構(gòu)

文檔結(jié)構(gòu)的邏輯能從 Instruments 的交互邏輯看出來，一份文檔有一個(gè)目標(biāo)設(shè)備，一個(gè)監(jiān)測(cè)的進(jìn)程和一組 profiling 模版，然后可以使用同一組模版進(jìn)行多次 profile。而對(duì)應(yīng)到 Instruments 的代碼中，一份文檔就是一個(gè) XR Trace 對(duì)象，除了一些元數(shù)據(jù)，它還包含一個(gè) XR Instrument 對(duì)象的數(shù)組，其中每一個(gè)，又包含了一個(gè) XR Run 的數(shù)組。

所以接下去要做的事情就是，找到從不同模版的 XR Instrument 中讀取 XR Run 對(duì)象中的數(shù)據(jù)的方法，然后依次遍歷即可。

XR Instrument對(duì)象

數(shù)據(jù)讀取和保存的代碼主要在 InstrumentsAnalysisCore.framework 這個(gè)框架里，存儲(chǔ)格式也用了 SQLite，把各種讀取寫入查詢都抽象了出來，比如用戶在 Instruments 里用鼠標(biāo)選了一段時(shí)間來看這段時(shí)間的數(shù)據(jù)，這樣的過濾操作就不需要在每個(gè)模版里單獨(dú)實(shí)現(xiàn)了。同時(shí)，因?yàn)閿?shù)據(jù)的結(jié)構(gòu)種類也比較有限，比如調(diào)用棧樹，樣本列表。

XRContext

在 Instruments 里，XRContext 就體現(xiàn)在模版列表下面的這個(gè)導(dǎo)航條。它是樹結(jié)構(gòu)的，每次選中顯示一個(gè) context，那從根結(jié)點(diǎn)到這個(gè) context 就是一條 context path。XRContextContainer(通常是 view controller)保存著 context 的引用，叫做它的 contextRepresentation，而 XRContext 也引用一個(gè)真正展示它數(shù)據(jù)的 XRContextContainer(通常是 view)，叫做它的 container。

不同的模版當(dāng)然會(huì)有不同的 contexts，但是有時(shí)候一個(gè)模版也會(huì)包含多個(gè)不同的 contexts，所以在用戶選擇不同的模版查看數(shù)據(jù)，或者從那個(gè)導(dǎo)航條里切換當(dāng)前模版的不同的數(shù)據(jù)視圖的時(shí)候，當(dāng)前的 context 就會(huì)變化，新的 context 的 -[XRContext display] 方法被調(diào)用，然后這個(gè) context 會(huì)通過 -[XRContextContainer displayContext:] 傳給相對(duì)應(yīng)的 XRContextContainer，然后這個(gè) container(通常是 view controller)就可以加載數(shù)據(jù)，刷新視圖了。

也就是說文檔中的大部分?jǐn)?shù)據(jù)只有在真正需要顯示的時(shí)候才會(huì)被讀取，從 Instruments 用戶的角度來看很容易理解，不過對(duì)于 TraceUtility 的用戶來說，就是需要知道，如果自己讀取的數(shù)據(jù)都是 nil，或者空數(shù)組之類的，就可以看看是不是忘記調(diào)用這個(gè) -[XRContext display]方法了。

每一種XRContextContainer對(duì)象存儲(chǔ)的結(jié)構(gòu)層次各有不同，以下給出三種結(jié)構(gòu)解析方法。

TimeProfiler模板解析實(shí)例：

CPU Activity Log模板解析實(shí)例：

Connections 模板數(shù)據(jù)解析實(shí)例：

Search Paths

雖然說要調(diào)用 Instruments 的代碼只需要鏈接上它的 framework 就可以了，不過這里還有幾個(gè)值得一提的地方。

首先是編譯器搜索我們要鏈接的 framework 的目錄。參考 Xcode 項(xiàng)目配置的 FRAMEWORK_SEARCH_PATHS 變量。

/Applications/Xcode.app/Contents/SharedFrameworks  
/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/Frameworks 

如果這個(gè)沒有設(shè)置對(duì)的話，鏈接的時(shí)候會(huì)報(bào)錯(cuò)，沒法生成可執(zhí)行程序。

然后是編譯好的程序在啟動(dòng)過程中搜索這些動(dòng)態(tài)鏈接的 framework 的目錄。參考 Xcode 項(xiàng)目配置的 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 

如果這個(gè)沒有設(shè)置對(duì)的話，程序還是可以編譯，但是程序運(yùn)行的時(shí)候會(huì)報(bào)錯(cuò)。另外，這里不僅包含上一個(gè)配置里的目錄，還多了別的，是因?yàn)槲覀冩溄拥?framework 還依賴了別的 framework，這些 framework 也需要在運(yùn)行的時(shí)候由 dyld 一起加載。

最后是 Instruments 自己搜索 Packages 的目錄，這些目錄都在 Instruments.app 的安裝目錄下，而函數(shù) NSString *PFTInstrumentsAppContents() 就是用來獲取這個(gè)安裝目錄的。它通過調(diào)用 +[NSBundle mainBundle] 來確定當(dāng)前進(jìn)程是 Instruments 的主 App 還是附加的命令行工具，然后返回正確的結(jié)果。

然而在我們的進(jìn)程中，+[NSBundle mainBundle] 返回的結(jié)果并不能被這個(gè)函數(shù)正確識(shí)別和處理，所以我們需要 hook 這個(gè)方法來返回 Instruments.app 所對(duì)應(yīng)的 bundle，從而使得 Instruments 能夠正確找到需要加載的包。

2.3解析后數(shù)據(jù)

Time Profiler解析出數(shù)據(jù)如下圖：

CPU Activity Log解析出數(shù)據(jù)如下圖：

Core Animation解析出數(shù)據(jù)如下圖：

Activity Monitor內(nèi)存使用情況解析出數(shù)據(jù)如下圖：

Energy Usage Level解析出數(shù)據(jù)如下圖：

Connections解析出數(shù)據(jù)如下圖：

3.應(yīng)用效果

蘇寧蛙測(cè)平臺(tái)將instruments檢測(cè)iOS性能技術(shù)應(yīng)用在iOS穩(wěn)定性測(cè)試中，將用戶提測(cè)的任務(wù)結(jié)果收集分析后制作成圖表展示，方便測(cè)試人員直接高效的獲得目標(biāo)測(cè)試App在不同系統(tǒng)版本、機(jī)型上的性能表現(xiàn)，提高相關(guān)人員的產(chǎn)出效率。如下圖測(cè)試報(bào)告節(jié)選截圖：

4.總結(jié)

考慮到文章篇幅，本文僅介紹了蘇寧蛙測(cè)平臺(tái)在移動(dòng)端性能檢測(cè)的冰山一角，有關(guān)于移動(dòng)穩(wěn)定性測(cè)試其他技術(shù)點(diǎn)將會(huì)在后續(xù)文章中進(jìn)行分享。蛙測(cè)平臺(tái)會(huì)在大促期間力保每一個(gè)上線應(yīng)用安全、穩(wěn)定、健壯，站好第一班崗，為蘇寧軟件質(zhì)量保駕護(hù)航。同時(shí)我們也會(huì)不斷成長(zhǎng)，提升技術(shù)面，將“測(cè)試，原來可以如此簡(jiǎn)單!”作為自己前進(jìn)的目標(biāo)，為蘇寧智慧零售戰(zhàn)略提供堅(jiān)實(shí)保障。

作者：

錢夢(mèng)奇，蘇寧易購IT總部數(shù)據(jù)云公司移動(dòng)SDK工程師，主要從事測(cè)試工具與平臺(tái)的研發(fā)工作。專注于移動(dòng)App開發(fā)、測(cè)試流程和測(cè)試工具開發(fā)，對(duì)移動(dòng)端自動(dòng)化測(cè)試、穩(wěn)定性測(cè)試、性能測(cè)試、App開發(fā)技術(shù)和新理念實(shí)踐，積累了比較豐富的經(jīng)驗(yàn)。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】