本系列將圍繞如何構建客戶端效能保障體系，分別從開發週期的各個階段來討論構建完整的效能保障體系；

- 開發階段

靜態分析和程式碼風格一致性

模板程式碼

執行單測

- 測試階段

自動化效能測試

- 線上執行階段

APM 效能監控

效能測試是指收集每次版本迭代的效能差異，暴露程序啟動和執行時方法執行快慢、幀率等和體驗息息相關的指標。有些團隊會定義效能基線，每次迴歸測試時由人工執行一些主要用例。

對於效能測試而言，持續的效能測試是防止效能劣化非常有效的手段，而如何保證持續性，關鍵就是如何實現人工的替換，而儘可能採用自動化的執行方式；

本文將從實操的角度出發，概述如何實現完備的 iOS 自動化效能測試；

Instruments

Instruments 是 Xcode 工具鏈中重要的效能分析工具，能夠揭示大部分效能問題。在 Instruments 10 時迎來了重大重構版本的 Instruments。將介面和分析核心完全解耦，使開發者可以自定義模板，階梯性的定義開發者需要的初級、中級以及高階應用。 Instruments 10 將命令列工具整合到 xcrun xctrace 工具中，基於 xctrace 可以很方便的將分析結果 trace 檔案解析成 xml 讓其他工具鏈讀取。

# 命令列啟動 TimeProfile 並匯出分析結果
xcrun xctrace record --template TimeProfile --launch --output ./output.trace longbridge-ios-app.app
# 將分析結果匯出為 xml 格式
xcrun xctrace export --input ${trace} --toc  --output ${exportXMLName}

將 xcrun 整合到我們的自動化任務中，便可以執行匯出測試資料做進一步分析和展示了。 然 Instruments 生成的資料是類資料庫表的二進位制格式，在 Instrument 10 釋出之前，要解析效能資料可以藉助開源庫 TraceUtility 來實現，而 TraceUtility 是通過逆向工程呼叫了 Instruments 相關的 Framework 來實現的，也僅僅是實現了一部分的資料匯出，如果要完全解析將是一個漫長的逆向過程。 在 Instruments 10 之後，xctrace 提供了匯出的功能，但是匯出的資料是未經符號化的函式呼叫地址，且僅有函式地址，缺少符號化必要的偏移量、基地址等資訊（如果哪位同學知道這些資訊在哪裡請告訴我不勝感激）。 因為無法符號化，所以我不得不放棄使用Instruments TimeProfile 這樣的模板來統計方法呼叫耗時，而是採用了執行時統計。 相比 Instruments 的基於取樣，執行時統計有一定侵入性，統計程式碼本身也可能會影響效能資料，但相比 Instruments 取樣的資料更精確一些。 除了方法耗時無法符號化之外，Instruments 的另外一些模板還是值得使用的，比如獲取啟動耗時、獲取所有網路請求記錄等。

執行時統計方法耗時

所有 OC 方法的呼叫都會走 objc_msgSend 方法，所以理論上通過Hook objc_msgSend 方法 就可以統計所有方法的呼叫及耗時，而且很容易獲取到 Class 、SEL 等符號資訊。

iOS自動化測試

有了上面的獲取耗時的方法，我們還需要自動執行操作，iOS 自動化測試限於平臺限制，各個框架基本都是基於 WebDriveAgent 來實現的，這種方式有一定缺點，第一是比較慢，第二是無法保證測試任務的高可用性，實際測下來總有一些環節會失敗，所以需要增加必要的重試邏輯。 最好的方式是直接在 APP 內注入遠端呼叫控制邏輯，本文受限於開發週期而採用老牌的 Appium 來驅動： 對於測試指令碼，我使用的是 Nodejs，把方法耗時和 appium 結合以後，寫出來的測試程式碼大概是這樣： 最終匯出來的方法耗時效果：

定位到耗時方法後，還可以通過 Git Log 來獲取到修改人，從而通知到相關開發，甚至自動的建立 jira 任務跟蹤修復情況。