android - 为什么调试 Android 应用程序使用的原生共享库很慢？

Question

我经常使用 gdbServer 来调试远程 Android 应用程序。我在其中设置断点的区域是一个共享库，用 C++ 编写。

单步执行代码非常慢。有人知道为什么吗？我的假设是对库的 JNI 调用造成了很大的延迟。

Answer 1

My assumption is that the JNI calls to the library impose a large delay.

当你在一个断点处，并在 GDB 中执行 step 命令时，实际上没有发生 JNI 调用(你已经在 native 代码中，继续直到下一行，或者进入下一行函数，JNI 与它有什么关系？)

不幸的是，即使在 native 执行时，step 也可能很慢；对于优化代码尤其如此。

step 命令如何工作？理论上，GDB 可以检查当前行的指令，发现没有 CALL 和 JMP，在下一行的第一条指令上设置一个临时中断，并继续。那会很快，但这并不是 GDB 的实际工作方式。

它所做的反而更简单:它单步执行处理器，并在每条指令中询问“我现在是否停在上次停止时所在的同一行上？”。如果"is"，则再次单步执行，直到答案为“否”。您可以通过设置 set debug infrun 1 来观察此行为。

根据您当前行的指令数量，可能需要 100 个单步才能完成您的 step 命令。这在 native 调试中可能会很慢，在使用远程 gdbserver 时它会变得更慢，因为每次单步完成时，GDB 都需要询问 gdbserver “我现在在哪里”。这是在 GDB 和 gdbserver 之间传输的大量数据包。您可以使用 set debug remote 1 观察这些数据包。

因此影响因素

• GDB 远程协议(protocol)很“健谈”，
• 每个数据包都需要通过(相对)慢速的链接到达设备并返回，并且
• 单个步骤可能涉及其中的 100 个

结合产生您观察到的非常慢的 step 执行。

一个可能的解决方法是避免执行 step。相反，设置断点并检查每个断点的程序状态。最终你会到达错误“下游”的断点(即程序已经处于错误状态)。现在在它的“上游”某处设置一个新断点，然后查看那里的状态。使用“分而治之”的方法，您很快就会将问题归零。