技術文章 » 位元組跳動 DanceCC 工具鏈系列之Xcode LLDB耗時監控統計方案

位元組跳動 DanceCC 工具鏈系列之Xcode LLDB耗時監控統計方案

2022-09-07 18:01:58

作者：李卓立 仲凱寧

背景介紹

在《位元組跳動 DanceCC 工具鏈系列之Swift 偵錯效能的優化方案》[1]一文中，我們介紹瞭如何使用自定義的工具鏈，來針對性優化偵錯程式的效能，解決大型Swift專案的偵錯痛點。

在經過內部專案的接入以及一段時間的試用之後，為了精確測量經過優化後的LLDB偵錯Xcode專案效率提升效果，衡量專案收益，需要開發一套能夠同時獲取Xcode官方工具鏈與DanceCC工具鏈偵錯耗時的耗時監控方案。

一般來說，LLDB內建的工作耗時，可以通過輸入log timers dump來獲取粗略的累計耗時，但是這個耗時只包括了原始碼中插入了LLDB_SCOPED_TIMER()宏的函數，並不代表完整的真實耗時。並且這個耗時統計需要使用者手動觸發，如果要單獨獲取某次操作的耗時還需要先進行reset操作清空之前的耗時記錄；對於我們目前的需求而言不夠精確也不夠自動。

因此DanceCC提出了一套專門的方案。方案原理基於LLDB Plugin[2]，利用Fishhook[3]，從LLDB的Script Bridge API[4]層面攔截Xcode對LLDB呼叫，以此來進行耗時監控統計。

注：LLDB論壇也有貢獻者，討論另一套內建的LLDB metries方案[5]，但是目標側重點和我們略有不同，並且截至發稿日未有完整的結論，因此僅在參照連結提及供讀者延伸閱讀。

方案原理

LLDB Plugin

Apple在其LLDB和早期Xcode整合中，為了不侵入一些容易改動的上層邏輯，引入了LLDB Plugin的設計和支援。

每個Plugin是一個動態連結庫，需要實現特定的C++/C入口函數，由LLDB主程序在執行時通過dladdr找到函數入口並載入進記憶體。目前有兩種Plugin的介面形式（網上常見第一種）

  • 新Plugin介面：
namespace lldb {
bool PluginInitialize(SBDebugger debugger);
}

這種Plugin，需要使用者在指令碼中手動按需載入，並常駐在記憶體中：

plugin load /path/to/plugin.dylib
  • 老Plugin介面：
extern "C" bool LLDBPluginInitialize(void);
extern "C" void LLDBPluginTerminate(void);

將編譯的動態庫放入以下兩個目錄，即可自動被載入，無法手動控制時機，在當前偵錯Session結束時解除安裝：

/path/to/LLDB.framework/Resources/Plugins
~/Library/Application Support/LLDB/PlugIns

注入動態庫

圖片

正常流程中，Xcode開始偵錯時會啟動一個lldb-rpc-server的程序，這個程序會載入Xcode預設工具鏈，或指定工具鏈中的LLDB.framework，並且通過這個動態庫中暴露出的Script Bridge API呼叫LLDB的各功能。

圖片

監控流程中，我們向lldbinit檔案中新增了command script import ~/.dancecc/dancecc_lldb.py，用於在LLDB啟動時載入指令碼，指令碼內會執行plugin load ~/.dancecc/libLLDBStatistics.dylib，載入監控動態庫。

監控動態庫在被載入時，因為被載入的動態庫和LLDB.framework不在一個MachO Image中，我們能夠通過Fishhook方案，對LLDB.framework暴露出的我們關心的Script Bridge API進行hook。

hook成功之後，每次Xcode對Script Bridge API進行呼叫都會先進入我們的監控邏輯。此時我們記錄時間戳來計時，然後再進入LLDB.framework中的邏輯，獲取結果後返回給lldb-rpc-server，並在Xcode的GUI中展示。

Hook SB API

Hook SB API時，需要一份含有要部署的LLDB.framework的標頭檔案（Xcode並未內建）。由於上述的流程使用了動態連結的LLDB.framework，我們選擇了Swift 5.6的產物，並tbd化避免倉庫膨脹。

由於LLDB Script Bridge API相對穩定，因此可以使用一個動態庫實現，通過執行時來應對不同版本的API變化（極少出現，截止發文調研5.5~5.7之間Xcode並沒有改變呼叫介面）。

對於hook C++函數的方式，這裡借用了Fishhook進行替換。原C++的函數地址，可通過dlsym呼叫得到。注意C++函數名使用mangled後的名稱（在tbd檔案中可找到）。

///
/// Hook a SB API using the stub method defined with the macros above
///
#define LLDB_HOOK_METHOD(MANGLED, CLASS, METHOD) \
Logger::Log("Hook "#CLASS"::"#METHOD" started!"); \
ptr_##MANGLED.pvoid = dlsym(RTLD_DEFAULT, #MANGLED); \
if (!ptr_##MANGLED.pvoid) { \
    Logger::Log(dlerror()); \
    return; \
} \
if (rebind_symbols((struct rebinding[1]){{#MANGLED, (void *) hook_##MANGLED, (void **) & ptr_##MANGLED.pvoid }}, 1) < 0) { \
    Logger::Log(dlerror()); \
    return; \
} \
Logger::Log("Hook "#CLASS"::"#METHOD" succeed!");

C++的成員函數的函數指標第一個應該是this指標，這裡用self命名。也可以呼叫原實現先獲取結果，再根據結果進行相關的統計邏輯。

///
/// Call the original implementation for member function
///
#define LLDB_CALL_HOOKED_METHOD(MANGLED, SELF, ...)  (SELF->*(ptr_##MANGLED.pmember))(__VA_ARGS__)

最終整體程式碼中Hook一個API就可以寫為：

// 假設期望Hook方法為：char * ClassA::MethodB(int foo, double bar)
// 這裡寫被Hook的方法實現
LLDB_GEN_HOOKED_METHOD(mangled, char *, ClassA, MethodB, int foo, double bar) {
  return LLDB_CALL_HOOKED_METHOD(mangled, self, 1, 2.0);
}
// 這裡是執行Hook（只執行一次）
LLDB_HOOK_METHOD(mangled, ClassA, MethodB);

耗時監控場景

目前耗時監控包含下列場景：

  • 展示frame變數
  • 展開變數的子變數
  • 輸入expr命令（p, po命令也是expr命令的alias）
  • Attach程序耗時
  • Launch程序耗時

展示frame變數場景

經過觀察，我們發現當在Xcode中進入斷點，GUI顯示當前frame的變數時，lldb-rpc-server呼叫SB API的流程為先呼叫SBFrame::GetVariables方法，返回一個表示當前frame中所有變數的SBValueList物件，然後再呼叫一系列方法獲取它們的詳細資訊，最後呼叫SBListener::GetNextEvent等待下一個event出現。因此我們計算展示frame變數的流程為，當SBFrame::GetVariables方法被呼叫時記錄當前時間戳，等待直至SBListener::GetNextEvent方法被呼叫，再記錄此時時間戳算出耗時。

展示子變數場景

經過觀察，我們發現當在Xcode中展開變數，需要顯示當前變數的子變數時，lldb-rpc-server呼叫SB API的流程為先呼叫SBValue::GetNumChildren方法，返回表示當前變數中子變數的數目，然後再呼叫SBValue::GetChildAtIndex獲取這些子變數以及它們的的詳細資訊，最後呼叫SBListener::GetNextEvent等待下一個event出現。因此我們計算展示frame變數的流程為，當SBValue::GetNumChildren方法被呼叫時記錄當前時間戳，等待直至SBListener::GetNextEvent方法被呼叫，再記錄此時時間戳算出耗時。

輸入expr命令場景

Xcode中使用者直接從debug console中輸入LLDB命令的方式是不走SB API的，因此無法直接通過hook的方式獲取耗時。我們發現大多數開發者，都習慣在debug console中使用po/expr等命令而不是GUI點選輸入框。因此我們專門做了支援，通過SB API的OverrideCallback方法進行了攔截。

LLDB.framework暴露了一個用於註冊在LLDB命令前呼叫自定義callback的介面：SBCommandInterpreter::SetCommandOverrideCallback；我們利用了這個介面註冊了一個用於攔截並獲取使用者輸入命令的callback函數，這個callback會記錄當前耗時，然後呼叫SBDebugger::HandleCommand來處理使用者輸入的命令。但是當SBDebugger::HandleCommand被呼叫時，我們註冊的callback一樣會生效，並再次進入我們攔截的callback流程中。

為了解決這個遞迴呼叫自己的問題，我們通過一個static bool isTrapped變數表示當前進入的expr命令是否被OverrideCallback攔截過。如果未被攔截，將isTrapped置true表示expr命令已經被攔截，則呼叫HandleCommand方法重新處理expr命令，此時進入的HandleCommand方法同樣會被OverrideCallback攔截到，但是此時isTrapped已經被置true，因此callback返回false不再進入攔截分支，而是走原有邏輯正常執行expr命令

圖片

Attach程序場景

Attach程序時，lldb-rpc-server會呼叫SBTarget::Attach方法，常見於真機偵錯的場景。這裡在呼叫前後記錄時間戳，計算出耗時即可。

Launch程序場景

Launch程序時，lldb-rpc-server會呼叫SBTarget::Launch方法，常見於模擬器啟動並偵錯的場景。這裡在呼叫前後記錄時間戳，計算出耗時即可。

上報部分

資料上報

為了進一步還原耗時的細節，除了標記場景的型別以外，我們還會統一記錄這些非敏感資訊：

  • 正在偵錯的程序名，用於區分多偵錯Session並存的場景
  • 正在偵錯的App的Bundle ID
  • 當前斷點位置在哪個檔案
  • 當前斷點位置在哪一行
  • 當前斷點位置在哪個函數
  • 當前斷點位置在哪個Module
  • 表示當前使用的工具鏈是Xcode的還是DanceCC的
  • 表示當前使用的Swift版本（與Xcode版本一一對應）

在內網提供的版本中，也通過外部環境變數，得知對應的App的倉庫標識，用於在內網的資料統計平臺上展示和區分。如圖，這是內網大型Swift工程，飛書iOS App接入DanceCC工具鏈之後，某時間的耗時資料，可以明顯看出，DanceCC相比於Xcode的變數顯示耗時，優化了接近一個數量級。

圖片圖片

極端耗時場景堆疊收集

除了基本的耗時時間收集以外，我們還希望能夠及時發現新增的極端耗時場景和新問題，因此設計了一套極端耗時情況下的偵錯程式堆疊收集機制，目前只要發現，展示變數場景和輸入expr命令耗時超過10秒種，則會記錄LLDB.framework的當前呼叫堆疊的每個函數耗時，並將資料上報到後臺進行統計和人工分析。堆疊收集使用了log timers dump所產出的堆疊和耗時資訊，本質上是LLDB程式碼中通過LLDB_SCOPED_TIMER()宏記錄的函數，其會使用編譯器的__PRETTY_FUNCTION__能力來在執行時得到一個用於人類可讀的函數名。在獲取到呼叫前和呼叫後的兩條堆疊後，我們會對每個函數進行Diff計算和排序，將最耗時的前10條進行了取樣記錄，使用字串一同上傳到統計後臺中。

圖片

總結

無論是App還是工具鏈，在做效能優化的同時，資料指標建設是必不可少的。這篇文章講述的監控方案，在後續迭代DanceCC工具鏈的時候，能夠明確相關的優化對實際的偵錯體驗有所幫助，能避免了主觀和片面的測試來評估偵錯程式的可用性。除了偵錯程式之外，DanceCC工具鏈還包括諸如連結器，編譯器，LLVM子工具（如dsymutil）等相關優化，系列文章也會進一步進行相關的分享，敬請期待。

參照連結

  1. https://mp.weixin.qq.com/s/MTt3Igy7fu7hU0ooE8vZog
  2. https://reviews.llvm.org/rG4272cc7d4c1e1a8cb39595cfe691e2d6985f7161
  3. https://lldb.llvm.org/design/api.html
  4. https://github.com/facebook/fishhook
  5. https://discourse.llvm.org/t/rfc-lldb-telemetry-metrics/64588

關於位元組終端技術團隊

位元組跳動終端技術團隊 (Client Infrastructure) 是大前端基礎技術的全球化研發團隊（分別在北京、上海、杭州、深圳、廣州、新加坡和美國山景城設有研發團隊），負責整個位元組跳動的大前端基礎設施建設，提升公司全產品線的效能、穩定性和工程效率；支援的產品包括但不限於抖音、今日頭條、西瓜視訊、飛書、瓜瓜龍等，在行動端、Web、Desktop等各終端都有深入研究。

加入我們

我們是位元組的 Client Infrastructure 部門下的編譯器工具鏈團隊，團隊成員由編譯器專家及構建系統專家組成，我們基於開源的 LLVM/Swift 專案提供深度客製化的 clang/swift 編譯器、連結器、lldb 偵錯程式和語言基礎庫等工具及優化方案，覆蓋構建效能優化及應用效能穩定性優化等場景，並在業務研發效率和應用品質提升方面取得了顯著的效果，同時，在實踐的過程中我們也看到了很多令人興奮的新機會，希望有更多對編譯工具鏈技術感興趣的同學加入我們一起探索。

工作地點

深圳、北京

職位描述

  1. 設計與實現高效的編譯器/連結器/偵錯程式優化
  2. 自定義 LLVM 工具鏈的維護和開發
  3. 提升Client Infrastructure編譯工具鏈的效能及穩定性
  4. 協同業務團隊推動技術方案的落地

職位要求

  1. 至少熟練掌握 C++/Objective-C/Swift 其中一門語言，熟悉語言特性的實現細節
  2. 熟悉程式語言的實現技術，如直譯器、編譯器、記憶體管理方面的實現
  3. 熟悉某個構建系統 (CMake/Bazel/Gradle/XCBuild 等)
  4. 有編譯器、連結器、偵錯程式等工具的開發和優化經驗優先，有 LLVM、GCC 等專案專案開發經歷優先
  5. 有行動端技術棧開發經驗優先

職位連結

點選連結投遞簡歷：https://job.toutiao.com/s/FBS9cLk!