参考文章

参考文章

1、运行调试

开启 Debug 调试模式有两种方式：

Debug Run：直接以 Debug 模式运行 APP，该模式的优点是可以调试程序启动相关的代码， 例如 Application.onCreate()。

Attach To Process：在程序运行中选择进程来调试，该模式的优点是随时可开启、关闭 Debug 模式，使用灵活方便。

注意：Debug Run 会导致程序整体变慢，建议使用等待调试，使用该方式可以在启动应用后处于等待状态，在开启调试后，应用才会走初始化流程，有两种方式开启等待断点：
  方法1：「开发者选项 - 选择调试应用」的方式来调试应用启动阶段代码。具体方式为「选择调试应用」-> 「运行应用」-> 「Attach To Process」，然后等待断点执行即可。
  方法2：使用adb命令adb shell am set-debug-app -w --persistent 包名开启，「-w」即表示应用启动时等待调试程序；关闭使用adb shell am clear-debug-app。

2、调试操作

1. Show Execution Point(Alt+F10) ：跳到当前执行的断点处。
2. Step Over(F8)：单步执行，执行到当前行的下一行。
3. Step Into(F7)：进入正在执行的方法。
4. Focus Step Into(Alt+shift_F7)：同3，但是可以进入源码，在3无法进入的情况下，可以尝试该操作。
5. Step Out(shift F8)：跳出正在执行的方法。
6. Drop Frame：返回到当前方法的调用处。
7. Run to Cursor(Alt+F9)：运行到光标处（光标必须在当前断点位置后）。
8. Evaluate expression：计算选中的变量的值。

3、断点类型

断点分为以下类型：
行断点： 当执行到此行是停止执行，等待调试。
属性断点：打在类的成员变量上，当变量初始化或变量的值改变时触发断点。
异常断点：当抛出指定异常时触发断点。
方法断点：当需要知道一个方法的调用方时。
条件断点
日志断点

行断点的使用场景

属性断点的使用场景

当你遇到一个问题，并且怀疑是某个属性值的变化导致的，可以设置属性断点来跟踪这个属性的变化情况，以便快速定位问题所在
调试属性值变化：当你想要追踪某个对象属性的变化情况时，可以设置属性断点。例如，你可能想要查看一个变量何时被修改，以及修改后的新值是什么。

异常断点的使用场景

在有些情况下，我们只对某些特定的异常感兴趣，或者我们只对异常感兴趣；我们希望只要程序发生异常程序就能断下来；这好像保存现场一样，这样就会留下的线索比较多，可以使我们快速的找到问题得根源；
举例说明，首先我们添加一个异常断点，单击
然后在弹出的对话框中进行如下设置

假如我们只关心空指针异常可以进行如下设置

选中空指针异常即可，我们人为设置一个空指针异常来看下运行效果：

方法断点的使用场景

如下所示，有个接口 IMethodTest，同时有两个类 MethodTestImpl1 和 MethodTestImpl2 实现了该接口，在 IMethodTest 的 printMethod() 上打上方法断点
在代码中实例化了 MethodTestImpl2 来调用 printMethod() 。

最后当 Debug 到该方法断点时，会自动走到 MethodTestImpl2 的 printMethod() 的实现中

条件断点

Ctrl + Shift + F8 条件断点
所谓的条件断点就是在特定条件发生的断点，也就是，我们可将某个断点设置为只对某种事件感兴趣，最典型的应用就是在列表循环中，我们希望在某特定的元素出现时暂停程序运行。假如我们有一个数组里面有1、2、3、4、5五个值，我们想在值等于3的时候停下来，可以设置条件断点；

右击断点，在弹出的对话框中设置相应的条件即可，我们运行一下看下效果

日志断点

日志断点
很多时候我们调试的时候更多的是打印日志定位异常代码，缩小范围之后再使用断点解决问题；所以经常做的事情就是在代码里面添加日志信息，输出函数参数，返回信息，输出我们感兴趣的变量信息等。但是这样做的问题在于我们需要重新编译运行程序，并且添加了很多无谓的代码且不好管理，这个时候我们可以使用日志断点；该类型的断点不会使程序停下来，而是在输出我们要它输出的日志信息，然后继续执行。

4、断点管理区