///
/// 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条进行了采样记录，使用字符串一同上传到统计后台中。

总结