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

作者:李卓立 仲凱寧

背景介紹

《位元組跳動 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. //mp.weixin.qq.com/s/MTt3Igy7fu7hU0ooE8vZog
  2. //reviews.llvm.org/rG4272cc7d4c1e1a8cb39595cfe691e2d6985f7161
  3. //lldb.llvm.org/design/api.html
  4. //github.com/facebook/fishhook
  5. //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. 有移動端技術棧開發經驗優先

職位鏈接

點擊鏈接投遞簡歷://job.toutiao.com/s/FBS9cLk!