如需转载请评论或简信，并注明出处，未经允许不得转载

目录

前言

Debug断点跟踪调试是开发过程中分析代码、解决BUG的一个重要手段，很多程序员的调试水平往往停留在单步执行阶段，因为单步执行往往就可以解决大部分的问题。但是一个优秀的程序员不仅仅要解决问题，还要高效地解决问题，本文将介绍一些非常方便的调试技巧

基本使用

Debug App有两种途径：

第一种是直接点击下图运行按钮右侧的小虫状图标，运行并调试当前Project

image.png

第二种就是调试当前已经处于运行状态下的App，点击运行按钮右侧第五个按钮，弹出Choose Process窗口，选择对应的进程，点击OK按钮即可进入调试模式，此时，我们便可以在需要的地方直接下断点调试代码了

image.png

接下来就是常见的调试方法了，在Debug窗口顶部工具栏有一排操作按钮，比如Step Over（单步执行）、Step Into（进入方法）等，如图所示：

image.png

打断点和取消断点最直接的方式就是单击目标代码行的行号右侧空白处，然后在Debug窗口左侧有个断点浏览按钮View Breakpoints，位于停止按钮下方第一个，可以浏览Project中的所有断点，同时可以添加删除断点

image.png

条件断点

有时候，我们的断点打在了循环体里面，但是我们只想看某一特定循环次数下的运行情况，难道要不停地跳至下一次断点直至满足我们的要求吗？

image.png

条件断点可以自己输入条件，比如for循环中输入i == 5即可让程序直接运行至第六次循环

image.png

日志断点

打印日志也是跟踪程序分析问题的一个非常有效的手段，但是如果我们的程序已经运行并且处于调试模式，此时如果想打印日志来分析代码，难道还要停止调试、添加Log代码并重新编译运行吗？

如果使用日志断点，就不用这么繁琐了。右键点击断点，在弹出的窗口中取消勾选Suspeng复选框（即表示程序运行至此断点时不会停下来供开发者调试），然后勾选Evaluate and log，并输入打印语句即可。这样，当Debug模式下的程序执行至此，不会停下来，而是在控制台中打印对应信息

image.png

image.png

变量赋值

比如，我们的代码里有一个变量，这个变量的值会影响到程序的执行结果。如果我们想观察这个变量在不同的赋值下程序的执行结果怎么办呢？难道要一遍遍的在代码里修改变量值，然后重新运行程序吗？显然这是非常麻烦的操作。如果利用Debug模式下的变量赋值（Set Value），只需要运行一次，就能达到我们的观察效果。在使用该变量的代码处打个断点，然后在Variables窗口找到对应的变量，修改变量值并执行即可

如这里我们可以把b的值改为false，那么Toast输出的值就是Hi

image.png

image.png

变量观察

在Variables变量区和Watches观察区可以查看Debug模式下，程序执行到断点处的变量值或者对象的各属性值，如果程序比较复杂变量很多看起来就有点不方便。那么就可以通过弹出窗口的形式查看属性值，只要将光标定位至断点代码行所用到的变量，IDE会自动弹出一个小窗口，如下图所示，此时，使用对应的快捷键或者点击这个小窗口里的变量即可弹出变量属性值窗口，Mac下的快捷键位command + F1，如图所示：

image.png

我们也可以使用New watch，方便我们更快定位到需要观察的变量

image.png

对象求值

在断点处，如果有变量对象，系统提供了表达式求值功能，针对Variables视图中的变量对象，我们可以输入任何计算语句，实时查看表达式计算结果。具体操作为，右键Variables视图中的变量对象，选择Evaluate Expression，弹出表达式窗口，输入任何你想要的计算语句，点击Evaluate计算按钮，即可显示计算结果

image.png

方法断点

当我们想要观察某个方法的调用时机，可以使用方法断点

这里有一个小建议，我们可以在写一个方法的时候，在方法注释中列出方法入参，这样一方面是可以给入参增加一些注释，同时在打断点的时候，也能非常直观的看到方法入参的值

image.png

变量断点

有时候，我们想知道自定义的变量的何时何地发生了改变，就可以使用变量断点。在变量定义行打断点，开启Debug模式，在程序执行的过程中，如果该变量的值发生改变，程序会自动停下来，并定位在改变变量值的地方。这里要注意的是，对于引用数据类型，通过set方法改变内部的值并不会触发变量断点，只有引用的地址发生改变才会触发

image.png

image.png

异常断点

程序在执行的过程中可能会出现各种各样的未知性异常，如果能在发生异常的时候第一时间让程序停下来，并定位到异常出现的地方，而不是让应用直接崩溃，那样有时候能帮助我们更方便定位问题

打开断点管理器，点击工具栏菜单Run，选择View Breakpoints；在Debug窗口直接点击View Breakpoints图标。点击左上角加号按钮，可以添加各种断点，包括前文提到的Method Breakpoints和Field Watchpoints断点，这里我们选择Exception Breakpoints异常断点，在弹出的Enter Exception Class窗口中输入需要监控的异常类别即可

image.png

image.png

这样当我们运行下面的代码，IDE会自动帮我们定位到问题发生的位置

image.png

总结

debug是非常非常基础的技术，所谓磨刀不误砍柴工，掌握一些小技巧，往往能帮我们更高效的解决一些问题。本文抛砖引玉，希望大家在开发过程中多留心一些很基础的技术，有时候了解一些你认为很不起眼的知识点，能够帮助你解决一些很棘手的问题

但是，在多线程环境下，光靠 debug 是不行的。有时 debug 本身会带来一些问题混淆了现场，比如因为 debug 时的卡顿造成环境不一致等等，这时应该学会使用打日志的形式帮忙调试，平时打日志的时候也应该多注意一些规范，这样能更方便排查问题