作者：李卓立 仲凱寧
背景介紹
在《位元組跳動 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）等相關優化，系列文章也會進一步進行相關的分享，敬請期待，
參考鏈接
- https://mp.weixin.qq.com/s/MTt3Igy7fu7hU0ooE8vZog
- https://reviews.llvm.org/rG4272cc7d4c1e1a8cb39595cfe691e2d6985f7161
- https://lldb.llvm.org/design/api.html
- https://github.com/facebook/fishhook
- https://discourse.llvm.org/t/rfc-lldb-telemetry-metrics/64588
關于位元組終端技術團隊
位元組跳動終端技術團隊 (Client Infrastructure) 是大前端基礎技術的全球化研發團隊（分別在北京、上海、杭州、深圳、廣州、新加坡和美國山景城設有研發團隊），負責整個位元組跳動的大前端基礎設施建設，提升公司全產品線的性能、穩定性和工程效率；支持的產品包括但不限于抖音、今日頭條、西瓜視頻、飛書、瓜瓜龍等，在移動端、Web、Desktop等各終端都有深入研究，
加入我們
我們是位元組的 Client Infrastructure 部門下的編譯器工具鏈團隊，團隊成員由編譯器專家及構建系統專家組成，我們基于開源的 LLVM/Swift 專案提供深度定制的 clang/swift 編譯器、聯結器、lldb 除錯器和語言基礎庫等工具及優化方案，覆寫構建性能優化及應用性能穩定性優化等場景，并在業務研發效率和應用品質提升方面取得了顯著的效果，同時，在實踐的程序中我們也看到了很多令人興奮的新機會，希望有更多對編譯工具鏈技術感興趣的同學加入我們一起探索，
作業地點
深圳、北京
職位描述
- 設計與實作高效的編譯器/聯結器/除錯器優化
- 自定義 LLVM 工具鏈的維護和開發
- 提升Client Infrastructure編譯工具鏈的性能及穩定性
- 協同業務團隊推動技術方案的落地
職位要求
- 至少熟練掌握 C++/Objective-C/Swift 其中一門語言，熟悉語言特性的實作細節
- 熟悉編程語言的實作技術，如解釋器、編譯器、記憶體管理方面的實作
- 熟悉某個構建系統 (CMake/Bazel/Gradle/XCBuild 等)
- 有編譯器、聯結器、除錯器等工具的開發和優化經驗優先，有 LLVM、GCC 等專案專案開發經歷優先
- 有移動端技術堆疊開發經驗優先
職位鏈接
點擊鏈接投遞簡歷：https://job.toutiao.com/s/FBS9cLk!
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/505567.html
標籤：其他