androidstudio断点调试 闪退原因_高效地调试代码——以 Xcode 为例

Debug 是程序员每天要做的事情，根据我的经验，我们大概花30%的时间写 bug，再花剩下 70%的时间 debug。Debug 的难度常常会超过写一个新功能，这是因为写新功能的时候是正向思考，有确定的方向，一路向前；而排错不仅需要正向思考，有的时候还需要逆向思考、横向思考、纵向思考以至于四面八方的思考，比拼脑洞和灵光闪现。如果没有和一个 bug 缠斗几天甚至几周的经历，可能难以理解 debug 给程序员带来的血与泪。Debug 占据程序员这么多时间，直接关系到大家的精神和身体健康，每一招、每一式都是很值得研究和总结的。我希望通过接下来的几篇文章，记录学习 Debugging with Xcode 的过程，并把自己的经验分享出来；也希望借此抛砖引玉，请神牛们批评指正。

本文是系列开篇，就先说些基础的东西。

从操作角度说，Debug 无非就是利用 IDE 的功能，在感兴趣的位置设置一些断点，执行重现bug 的步骤，在断点附近查看变量内容或是程序语句执行情况。如果变量的值与预期不同，或是代码的执行路径与预想的不一样，就可以研究一下是什么导致了这些不一致，然后一步步按图索骥，找到最终的症结所在。虽然 IDE 不是必需的，也可以使用 LLDB 的命令在 Terminal 中调试，但是对于体积庞大、逻辑复杂的应用程序，借助 IDE 显然是更高效的做法，毕竟工欲善其事，必先利其器。

用上面的基本操作，可以适应大多数的调试需求了。只要保持头脑清晰，有正确的预期值，哪怕要设置很多断点，找到 bug 的原因也只是一个时间上的问题。但是还有一些调试需求，用基本操作是应付不来的，比如感兴趣的代码处于一个消息循环或事件循环中，或是其他任何在重现过程中会反复进入的区域。其难点在于，程序运行过程中，断点会被反复命中，而断点一旦命中，程序就被中断，无法施加下一步操作。

解决方案有二。

一是使用条件断点，条件满足时程序才被中断。假设在我们的代码中，鼠标在视图中的移动会反复经过断点，但只有在点击之后，某一个布尔值才会成为 true，那么我们可以设置“该值为 true 再触发中断”这样的条件，这样鼠标可以正常连续移动，直到发生点击事件程序才被中断。

第二种方法是，首先在断点上勾选“命中后继续自动执行”，然后对断点添加动作（Action），比如在命中的时候，向 console 输出信息，可以输出一个字符串，也可以输出变量的值。这样在操作时，断点即使命中，程序也不会停下来，而是在 console 中输入我们想要的信息。一边操作，一边关注 console 的输出，可以获知刚才的操作对程序的影响，判断是否符合预期。

总结

在条件允许时，尽量使用 IDE 的调试功能；对于在 Terminal 中使用命令进行调试的做法，我只想说，有那时间做些有意义的事情更好。Debug 的基本操作可以归结为：添加断点，查看变量和执行情况，找出与预期行为的不同，分析原因，然后重复过程直到找到问题的根本原因。对于反复进入的区域，可以采用条件断点或者是带输出的不中断断点来调试。