背景

對蘋果開發者而言，由於平臺審核周期較長，客戶端代碼導致的線上問題影響時間往往比較久。如果在開發、測試階段能夠提前暴露問題，就有助於避免線上事故的發生。代碼覆蓋率檢測正是幫助開發、測試同學提前發現問題，保證代碼質量的好幫手。

對於開發者而言，代碼覆蓋率可以反饋兩方面信息：

1. 自測的充分程度。

2. 代碼設計的冗余程度。

盡管代碼覆蓋率對代碼質量有著上述好處，但在 iOS 開發中卻使用的不多。我們調研了市場上常用的 iOS 覆蓋率檢測工具，這些工具主要存在以下四個問題：

1. 第三方工具有時生成的檢測報告文件會出錯甚至會失敗，開發者對覆蓋率生成原理不了解，遇到這類問題容易棄用工具。

2. 第三方工具每次展示全量的覆蓋率報告，會分散開發者的很多精力在未修改部分。而在絕大多數情況下，開發者的關註重點在本次新增和修改的部分。

3. Xcode 自帶的覆蓋率檢測只適用於單元測試場景，由於需求變更頻繁，業務團隊開發單元測試的成本很高。

4. 已有工具很難和現有開發流程結合起來，需要額外進行測試，運行覆蓋率腳本才能獲取報告文件。

為了解決上述問題，我們深入調研了覆蓋率報告的生成邏輯，並結合團隊的開發流程，開發了一套嵌入在代碼提交流程中、基於單次代碼提交（git commit）生成報告、對開發者透明的增量代碼測試覆蓋率工具。開發者只需要正常開發，通過模擬器測試開發代碼，commit 本次代碼（commit 和測試順序可交換），推送（git push）到遠端，就可以在本地看到這次提交代碼的詳細覆蓋率報告了。

本文分為兩部分，先從介紹通用覆蓋率檢測的原理出發，讓讀者對覆蓋率的收集、解析有直觀的認識。之後介紹我們增量代碼測試覆蓋率工具的實現。

覆蓋率檢測原理

生成覆蓋率報告，首先需要在 Xcode 中配置編譯選項，編譯後會為每個可執行文件生成對應的 .gcno 文件；之後在代碼中調用覆蓋率分發函數，會生成對應的 .gcda 文件。

其中，.gcno 包含了代碼計數器和源碼的映射關系， .gcda 記錄了每段代碼具體的執行次數。覆蓋率解析工具需要結合這兩個文件給出最後的檢測報表。接下來先看看 .gcno 的生成邏輯。

.gcno

利用 Clang 分別生成源文件的 AST 和 IR 文件，對比發現，AST 中不存在計數指令，而 IR 中存在用來記錄執行次數的代碼。搜索 LLVM 源碼可以找到覆蓋率映射關系生成源碼。覆蓋率映射關系生成源碼是 LLVM 的一個 Pass，（下文簡稱 GCOVPass）用來向 IR 中插入計數代碼並生成 .gcno 文件（關聯計數指令和源文件）。

下面分別介紹IR插樁邏輯和 .gcno 文件結構。

IR 插樁邏輯

代碼行是否執行到，需要在運行中統計，這就需要對代碼本身做一些修改，LLVM 通過修改 IR 插入了計數代碼，因此我們不需要改動任何源文件，僅需在編譯階段增加編譯器選項，就能實現覆蓋率檢測了。

從編譯器角度看，基本塊（Basic Block，下文簡稱 BB）是代碼執行的基本單元，LLVM 基於 BB 進行覆蓋率計數指令的插入，BB 的特點是：

1. 只有一個入口。

2. 只有一個出口。

3. 只要基本塊中第一條指令被執行，那麽基本塊內所有指令都會順序執行一次。

分支、循環結構對應著基本塊之間的跳轉。LLVM 基於 BB 進行覆蓋率計數指令的插入。

覆蓋率計數指令的插入會進行兩次循環，外層循環遍歷編譯單元中的函數，內層循環遍歷函數的基本塊。函數遍歷僅用來向 .gcno 中寫入函數位置信息，這裏不再贅述。

一個函數中基本塊的插樁方法如下：

1. 統計所有 BB 的後繼數 n，創建和後繼數大小相同的數組 ctr[n]。

2. 以後繼數編號為序號將執行次數依次記錄在 ctr[i] 位置，對於多後繼情況根據條件判斷插入。

舉個例子，下面是一段猜數字的遊戲代碼，當玩家猜中了我們預設的數字10的時候會輸出Bingo，否則輸出You guessed wrong!。這段代碼的控制流程圖如圖1所示。

- (void)guessNumberGame:(NSInteger)guessNumber
{
 NSLog(@"Welcome to the game");
 if (guessNumber == 10) {
 NSLog(@"Bingo!");
 } else {
 NSLog(@"You guess is wrong!");
 }
}

例1 猜數字遊戲

這段代碼如果開啟了覆蓋率檢測，會生成一個長度為 6 的 64 位數組，對照插樁位置，方括號中標記了樁點序號，圖 1 中代碼前數字為所在行數。

圖 1 樁點位置

.gcno計數符號和文件位置關聯

.gcno 是用來保存計數插樁位置和源文件之間關系的文件。GCOVPass 在通過兩層循環插入計數指令的同時，會將文件及 BB 的信息寫入 .gcno 文件。寫入步驟如下：

1. 創建 .gcno 文件，寫入 Magic number(oncg+version)。

2. 隨著函數遍歷寫入文件地址、函數名和函數在源文件中的起止行數（標記文件名，函數在源文件對應行數）。

3. 隨著 BB 遍歷，寫入 BB 編號、BB 起止範圍、BB 的後繼節點編號（標記基本塊跳轉關系）。

4. 寫入函數中BB對應行號信息（標註基本塊與源碼行數關系）。

從上面的寫入步驟可以看出，.gcno 文件結構由四部分組成：

· 文件結構

· 函數結構

· BB 結構

· BB 行結構

通過這四部分結構可以完全還原插樁代碼和源碼的關聯，我們以 BB 結構 / BB 行結構為例，給出結構圖 2 (a) BB 結構，(b) BB 行信息結構，在本章末尾覆蓋率解析部分，我們利用這個結構圖還原代碼執行次數（每行等高格代表 64bit）：

圖2 BB 結構和 BB 行信息結構

.gcda

入口函數

關於 .gcda 的生成邏輯，可參考覆蓋率數據分發源碼。這個文件中包含了 __gcov_flush() 函數，這個函數正是分發邏輯的入口。接下來看看 __gcov_flush() 如何生成 .gcda 文件。

通過閱讀代碼和調試，我們發現在二進制代碼加載時，調用了llvm_gcov_init(writeout_fn wfn， flush_fn ffn)函數，傳入了_llvm_gcov_writeout（寫 gcov 文件），_llvm_gcov_flush（gcov 節點分發）兩個函數，並且根據調用順序，分別建立了以文件為節點的鏈表結構。（flush_fn_node * ，writeout_fn_node *）

__gcov_flush() 代碼如下所示，當我們手動調用__gcov_flush()進行覆蓋率分發時，會遍歷flush_fn_node *這個鏈表（即遍歷所有文件節點），並調用分發函數_llvm_gcov_flush（curr->fn 正是__llvm_gcov_flush函數類型）。

void __gcov_flush() {
 struct flush_fn_node *curr = flush_fn_head;
 while (curr) {
 curr->fn();
 curr = curr->next;
 }
}

具體的分發邏輯

觀察__llvm_gcov_flush的 IR 代碼，可以看到：

圖3 __llvm_gcov_flush 代碼示例

1. __llvm_gcov_flush先調用了__llvm_gcov_writeout，來向 .gcda 寫入覆蓋率信息。

2. 最後將計數數組清零__llvm_gcov_ctr.xx。

而__llvm_gcov_writeout邏輯為：

1. 生成對應源文件的 .gcda 文件，寫入 Magic number。

2. 循環執行

llvm_gcda_emit_function: 向 .gcda 文件寫入函數信息。

llvm_gcda_emit_arcs: 向 .gcda 文件寫入BB執行信息，如果已經存在 .gcda 文件，會和之前的執行次數進行合並。

1. 調用llvm_gcda_summary_info，寫入校驗信息。

2. 調用llvm_gcda_end_file，寫結束符。

感興趣的同學可以自己生成 IR 文件查看更多細節，這裏不再贅述。

.gcda 的文件/函數結構和 .gcno 基本一致，這裏不再贅述，統計插樁信息結構如圖 4 所示。定制化的輸出也可以通過修改上述函數完成。我們的增量代碼測試覆蓋率工具解決代碼 BB 結構變動後合並到已有 .gcda 文件不兼容的問題，也是修改上述函數實現的。

圖4 計數樁輸出結構

覆蓋率解析

在了解了如上所述 .gcno ，.gcda 生成邏輯與文件結構之後，我們以例 1 中的代碼為例，來闡述解析算法的實現。

例 1 中基本塊 B0，B1 對應的 .gcno 文件結構如下圖所示，從圖中可以看出，BB 的主結構完全記錄了基本塊之間的跳轉關系。

圖5 B0，B1 對應跳轉信息

B0，B1 的行信息在 .gcno 中表示如下圖所示，B0 塊因為是入口塊，只有一行，對應行號可以從 B1 結構中獲取，而 B1 有兩行代碼，會依次把行號寫入 .gcno 文件。

圖6 B0，B1 對應行信息

在輸入數字 100 的情況下，生成的 .gcda 文件如下：

圖7 輸入 100 得到的 .gcda 文件

通過控制流程圖中節點出邊的執行次數可以計算出 BB 的執行次數，核心算法為計算這個 BB 的所有出邊的執行次數，不存在出邊的情況下計算所有入邊的執行次數（具體實現可以參考 gcov 工具源碼），對於 B0 來說，即看 index=0 的執行次數。而 B1 的執行次數即 index=1，2 的執行次數的和，對照上圖中 .gcda 文件可以推斷出，B0 的執行次數為 ctr[0]=1，B1 的執行次數是 ctr[1]+ctr[2]=1， B2 的執行次數是 ctr[3]=0，B4 的執行次數為 ctr[4]=1，B5 的執行次數為 ctr[5]=1。

經過上述解析，最終生成的 HTML 如下圖所示（利用 lcov）：

圖8 覆蓋率檢測報告

以上是 Clang 生成覆蓋率信息和解析的過程，下面介紹美團到店餐飲 iOS 團隊基於以上原理做的增量代碼測試覆蓋率工具。

增量代碼覆蓋率檢測原理

方案權衡

由於 gcov 工具（和前面的 .gcov 文件區分，gcov 是覆蓋率報告生成工具）生成的覆蓋率檢測報告可讀性不佳，如圖 9 所示。我們做的增量代碼測試覆蓋率工具是基於 lcov 的擴展，報告展示如上節末尾圖 8 所示。

圖9 gcov 輸出，行前數字代表執行次數，#### 代表沒執行

比 gcov 直接生成報告多了一步，lcov 的處理流程是將 .gcno 和 .gcda 文件解析成一個以 .info 結尾的中間文件（這個文件已經包含全部覆蓋率信息了），之後通過覆蓋率報告生成工具生成可讀性比較好的 HTML 報告。

結合前兩章內容和覆蓋率報告生成步驟，覆蓋率生成流程如下圖所示。考慮到增量代碼覆蓋率檢測中代碼增量部分需要通過 Git 獲取，比較自然的想法是用 git diff 的信息去過濾覆蓋率的內容。根據過濾點的不同，存在以下兩套方案：

1. 通過 GCOVPass 過濾，只對修改的代碼進行插樁，每次修改後需重新插樁。

2. 通過 .info 過濾，一次性為所有代碼插樁，獲取全部覆蓋率信息，過濾覆蓋率信息。

圖10 覆蓋率生成流程

分析這兩個方案，第一個方案需要自定義 LLVM 的 Pass，進而會引入以下兩個問題：

· 只能使用開源 Clang 進行編譯，不利於接入正常的開發流程。

· 每次重新插樁會丟失之前的覆蓋率信息，多次運行只能得到最後一次的結果。

而第二個方案相對更加輕量，只需要過濾中間格式文件，不僅可以解決我們在文章開頭提到的問題，也可以避免上述問題：

· 可以很方便地加入到平常代碼的開發流程中，甚至對開發者透明。

· 未修改文件的覆蓋率可以疊加（有修改的那些控制流程圖結構可能變化，無法疊加）。

因此我們實際開發選定的過濾點是在 .info 。在選定了方案 2 之後，我們對中間文件 .info 進行了一系列調研，確定了文件基本格式（函數/代碼行覆蓋率對應的文件的表示），這裏不再贅述，具體可以參考 .info 生成文檔。

增量代碼測試覆蓋率工具的實現

前一節是實現增量代碼覆蓋率檢測的基本方案選擇，為了更好地接入現有開發流程，我們做了以下幾方面的優化。

降低使用成本

在接入方面，接入增量代碼測試覆蓋率工具只需一次接入配置，同步到代碼倉庫後，團隊中成員無需配置即可使用，降低了接入成本。

在使用方面，考慮到插樁在編譯時進行，對全部代碼進行插樁會很大程度降低編譯速度，我們通過解析 Podfile（iOS 開發中較為常用的包管理工具 CocoaPods 的依賴描述文件），只對 Podfile 中使用本地代碼的倉庫進行插樁（可配置指定倉庫），降低了團隊的開發成本。

對開發者透明

接入增量代碼測試覆蓋率工具後，開發者無需特殊操作，也不需要對工程做任何其他修改，正常的 git commit 代碼，git push 到遠端就會自動生成並上傳這次 commit 的覆蓋率信息了。

為了做到這一點，我們在接入 Pod 的過程中，自動部署了 Git 的 pre-push 腳本。熟悉 Git 的同學知道，Git 的 hooks 是開發者的本地腳本，不會被納入版本控制，如何通過一次配置就讓這個倉庫的所有使用成員都能開啟，是做好這件事的一個難點。

我們考慮到 Pod 本身會被納入版本控制，因此利用了 CocoaPods 的一個屬性 script_phase，增加了 Pod 編譯後腳本，來幫助我們把 pre-push 插入到本地倉庫。利用 script_phase 插入還帶來了另外一個好處，我們可以直接獲取到工程的緩存文件，也避免了 .gcno / .gcda 文件獲取的不確定性。整個流程如下：

圖11 pre-push 分發流程

覆蓋率累計

在實現了覆蓋率的過濾後，我們在實際開發中遇到了另外一個問題：修改分支/循環結構後生成的 .gcda 文件無法和之前的合並。 在這種情況下，__gcov_flush會直接返回，不再寫入 .gcda 文件了導致覆蓋率檢測失敗，這也是市面上已有工具的通用問題。

而這個問題在開發過程中很常見，比如我們給例 1 中的遊戲增加一些提示，當輸入比預設數字大時，我們就提示出來，反之亦然。

- (void)guessNumberGame:(NSInteger)guessNumber
{
 NSInteger targetNumber = 10;
 NSLog(@"Welcome to the game");
 if (guessNumber == targetNumber) {
 NSLog(@"Bingo!");
 } else if (guessNumber > targetNumber) {
 NSLog(@"Input number is larger than the given target!");
 } else {
 NSLog(@"Input number is smaller than the given target!");
 }
}

這個問題困擾了我們很久，也推動了對覆蓋率檢測原理的調研。結合前面覆蓋率檢測的原理可以知道，不能合並的原因是生成的控制流程圖比原來多了兩條邊（ .gcno 和舊的 .gcda 也不能匹配了），反映在 .gcda 上就是數組多了兩個數據。考慮到代碼變動後，原有的覆蓋率信息已經沒有意義了，當發生邊數不一致的時候，我們會刪除掉舊的 .gcda 文件，只保留最新 .gcda 文件（有變動情況下 .gcno 會重新生成）。如下圖所示：

圖12 覆蓋率沖突解決算法

整體流程圖

結合上述流程，我們的增量代碼測試覆蓋率工具的整體流程如圖 13 所示。

開發者只需進行接入配置，再次運行時，工程中那些作為本地倉庫進行開發的代碼庫會被自動插樁，並在 .git 目錄插入 hooks 信息；當開發者使用模擬器進行需求自測時，插樁統計結果會被自動分發出去；在代碼被推到遠端前，會根據插樁統計結果，生成僅包含本次代碼修改的詳細增量代碼測試覆蓋率報告，以及向遠端推送覆蓋率信息；同時如果測試覆蓋率小於 80% 會強制拒絕提交（可配置關閉，百分比可自定義），保證只有經過充分自測的代碼才能提交到遠端。

圖13 增量代碼測試覆蓋率生成流程圖

總結

以上是我們在代碼開發質量方面做的一些積累和探索。通過對覆蓋率生成、解析邏輯的探究，我們揭開了覆蓋率檢測的神秘面紗，也讓我們能更好的控制展示報告。開發階段的增量代碼覆蓋率檢測，可以幫助開發者聚焦變動代碼的邏輯缺陷，從而更好地避免線上問題。

iOS 增量代碼覆蓋率檢測實踐