在 iOS 生態逐漸向 Swift 靠攏的同時，Objective-C（OC）依舊是大量成熟大型 App 的主力語言。 尤其在企業級項目、歷史項目、框架庫、原生組件中，OC 的穩定性與可控性仍舊不可替代。 因此，構建一套 適用於 OC 項目、覆蓋功能、性能、系統日誌與跨端場景的測試體系，對許多團隊來説依然非常重要。

本文將從工程實戰角度出發，圍繞 OC 測試的常見場景，結合 XCTest、OCMock、Instruments、克魔（KeyMob）、PerfDog、Charles、Safari Inspector、MetricKit、Xcode 調試工具 等多工具構成一套可落地的測試體系。

文章風格保持工程化、不含廣告化語氣、不依賴網絡搜索，基於開發者實際工作場景編寫。

---

一、為什麼 OC 項目需要更完善的測試體系？

OC 項目通常具有以下特點：

1. 歷史代碼多，缺乏單測

許多業務邏輯仍依賴面向對象、運行時特性，測試難度比 Swift 更高。

2. 容易出現運行時錯誤

如：

• unrecognized selector
• KVC/KVO 崩潰
• NSException

3. 複雜的 UI 邏輯

OC 項目多數 UI 架構較老，性能問題更容易在 UI 層暴露。

4. 與 Hybrid、C++、底層框架兼容

意味着測試不僅包括 OC 邏輯，還包含底層組件行為。

5. 老項目更需要性能和穩定性保證

因此，OC 測試必須覆蓋功能 + 性能 + 系統日誌 + 文件數據 + 跨端行為多個維度。

---

二、XCTest：OC 單元測試的核心基礎

XCTest 是蘋果官方單元測試框架，對 OC 項目非常成熟。

1. 單元測試（Unit Test）

用於驗證 OC 模塊內部邏輯，例如：

- (void)testCalculateTotalPrice {
    OrderManager *m = [OrderManager new];
    XCTAssertEqual([m totalPrice], 0);
}

適合測試：

• Model
• 工具類
• 業務計算邏輯
• 數據解析

2. UI 測試（XCUITest）

用於流程自動化，例如：

• 啓動 App
• 自動點擊按鈕
• 輸入內容
• 驗證 UI 狀態

這對 OC 項目的迴歸測試非常重要。

---

三、OCMock：Objective-C 測試中的“Mock 利器”

OCMock 是很多 OC 工程師仍在使用的 Mock 框架，可用於：

1. Mock 對象方法

模擬接口返回、邏輯分支：

OCMockObject *mock = OCMClassMock([UserService class]);
OCMStub([mock fetchUser]).andReturn(mockUser);

2. Mock Delegate / Block 回調

3. 驗證方法是否被調用

OCMVerify([mock trackEvent:@"open"]);

在業務依賴較深、運行時行為較複雜的 OC 項目中，OCMock 對提升測試覆蓋率非常關鍵。

---

四、Instruments：OC 性能測試的“顯微鏡”

無論 OC 還是 Swift，底層性能測試統一依賴 Instruments。

在 OC 項目中尤其需要關注：

1. Time Profiler

用來查：

• 主線程阻塞（OC 中更常見）
• 無意的同步調用
• 高耗時方法

2. Leaks / Allocations

OC 的內存管理更復雜，容易出現：

• 循環引用（block/self）
• 未釋放對象
• 自動釋放池濫用

3. Core Animation

OC 項目往往 UI 結構更重，更容易出現渲染問題：

• 重繪過多
• 離屏渲染
• 佈局過於複雜

Instruments 是 OC 性能調試的核心工具。

---

五、克魔（KeyMob）：系統日誌 + 性能監控 + 文件調試（OC 項目的非常高適配度）

OC 項目因歷史原因或系統層依賴更容易產生：

• KVO 異常
• 內存壓力導致 jetsam
• UI 卡頓導致 watchdog
• NSException 崩潰
• WebKit/WebView 崩潰
• Sandbox 文件解析需求

KeyMob 能補足 Xcode 的能力，包括：

1. 實時性能監控

可監控：

• CPU
• GPU
• 內存
• FPS
• 網絡
• 温度、能耗

非常適合驗證 OC 項目常見的性能迴歸問題。

2. 系統日誌（Device Logs）捕獲

OC 項目最容易出現的系統錯誤包括：

EXC_BAD_ACCESS
jetSam (Memory highwater)
KVO crash
watchdog (main thread hang)

Xcode 很難完整捕獲，但 KeyMob 可以完整展示。

3. App 文件與數據管理

用於查看：

• plist 配置
• 緩存文件
• OC 底層序列化文件
• 用户數據目錄
• 崩潰日誌

對調試 OC 項目中的 Sandbox 邏輯非常有效。

---

六、PerfDog：OC 視圖結構下的 FPS/CPU/GPU 關鍵診斷

OC 項目往往使用更傳統、更復雜的視圖結構，例如：

• UITableView + 大量 cell
• 手寫 UI 佈局
• 大量 CALayer
• 混合 CoreAnimation 與 UIKit
• 異步繪製不足

PerfDog 能精準分析：

• FPS 掉幀點
• 多次交互後的性能退化
• CPU 峯值與 UI 更新關係
• GPU 渲染壓力

尤其適用於 OC 項目中常見的“越滑越卡”“頁面切換卡頓”。

---

七、Safari Inspector：Hybrid、H5、OC 容器混合場景測試

許多歷史 OC 項目使用：

• UIWebView（老項目）
• WKWebView（新項目）
• Hybrid（OC + JSBridge）
• uni-app 容器

Safari Inspector 可以：

• 查看 JS 性能
• 分析 DOM 結構
• 驗證 JSBridge 延遲
• 找出 Hybrid 阻塞 UI 的行為

OC 項目中經常出現 WebView 卡頓問題，Safari Inspector 是必選項。

---

八、Charles / Proxyman：OC 網絡層測試工具

OC 時代許多項目仍使用：

• AFNetworking
• NSURLSession + 手寫網絡層

Charles 用於測試：

• 網絡異常
• 重定向
• Cache-Control 是否正確
• 弱網行為
• 接口鏈路延遲

是 OC 應用網絡層迴歸測試的標配工具。

---

九、MetricKit + Firebase：OC 線上性能監控體系

OC 項目一般運行在用户量龐大的應用中，線上監控尤為重要。

MetricKit 可收集：

• CPU 時間
• 內存峯值
• 熱力狀態
• 崩潰類型
• 啓動性能
• 每日性能趨勢

Firebase 可收集：

• 頁面渲染時間
• 啓動性能
• 網絡耗時
• ANR 事件

兩者結合可構成 OC 應用的線上穩定性監控體系。

---

十、構建 Objective-C 測試的完整工程化工具鏈

測試類型	工具組合	用途
單元測試	XCTest + OCMock	測試 OC 方法邏輯
UI 自動化	XCUITest	完整流程測試
性能測試	Instruments + PerfDog + KeyMob	CPU/GPU/FPS/內存分析
網絡測試	Charles	請求調試 & 弱網
WebView/Hybrid	Safari Inspector	JS/DOM 性能
系統級行為	KeyMob + Console.app	jetsam/watchdog/KVO
上線監控	MetricKit + Firebase	用户真實性能趨勢

這套工具鏈適合絕大多數 OC 項目。

---

十一、實戰案例：OC 首頁卡頓的定位過程

某 OC 老項目首頁滑動卡頓明顯。

PerfDog

FPS 在快速滑動時下降到 30–40。

KeyMob

CPU 峯值突然升高至 90%。

Instruments（Time Profiler）

發現某 cell 的圖片解碼與富文本渲染在主線程執行。

Safari Inspector（該項目含 Hybrid）

Hybrid 部分存在 DOM 節點過多問題。

優化方案：

• 使用異步圖片解碼
• 重繪邏輯移到後台線程
• Hybrid 列表啓用虛擬渲染

最終 FPS 穩定在 58–60。

---

OC 測試的關鍵在於“多工具協同”

OC 項目測試不是“寫幾行單測”，而是構建一套體系：

邏輯測試 UI 測試 性能測試 系統日誌 網絡鏈路 Hybrid 性能 線上數據驗證

而實現這一點，必須依賴：

• XCTest + OCMock（功能）
• Instruments（CPU/GPU/內存）
• KeyMob（系統日誌 + 實時性能）
• PerfDog（FPS 精準採樣）
• Safari Inspector（Hybrid）
• Charles（網絡）
• MetricKit + Firebase（線上表現）

只有當這些工具協同工作，OC 應用的質量才能穩步提升。