介绍frames、threads、evaluate的使用，断点的一些属性以及条件断点、日志断点、异常断点等使用场景，帮助提高debug效率
跳过单步调试的stepOver stepInto等基础调试，从上一幅图开始。
frames查看帧调用关系
图中右边箭头指着的图标用来控制是否显示frames。
左边的箭头指着的是调用关系，从Debug的frames也可以看到：onClick是在performClick中调用的，同时可以看到前面是由ActivityThread调用。
即使没有导入frameWork的源码,从这里点进去，也是可以看到ActivityThread（frameWork层）的源码的！！！（just a joke，只能看看，不能调试frameWork）
通过这种方式也可以看到activityThread，可以看到app的入口main函数，就和java的public static void main一样！
顺便看看验证下ui线程的Looper也是要prepare loop的，只是activityThread在main函数里面提前做了罢了。
Thread查看线程信息
这里开了2个线程来执行doSomeTask函数，然后在deSomeTask那里断点，从debug的Threads可以看到除了Thread-154，另外还有个Thread-155也是被断到了的，把断点放开后会接着由155线程执行doSomeTask。而且从这里我们也可以意识到这是多线程访问，bug可能来源于线程同步未做好。
evaluate计算运行到断点时的相关状态
evaluate就是左边箭头指着的像计算器的那个小图标。
当运行到断点的时候，点击evaluate,弹出左边的弹框，输入要计算的表达式，如当前的线程信息或者其他你想知道的东西。如图可以看到当前线程id是155，所以不是ui线程（threadId = 1），如果在这个函数执行ui操作会抛出异常（非ui线程更新ui）。
这个操作简直666啊，如果以前按单步调试想看某一项信息就比如threadId，必须要写一行代码，重新编译运行
long threadId = Thread.currentThread().getId();
然后断点到这里看threadId变量的值是多少，而且调试完了之后还需要把这行代码删除掉，用evaluate简直太方便。
几种特殊断点
点击红色箭头或者右键黑色箭头指向的断点都可以弹出右边的弹框：设置断点的各种属性。
粉红色的Suspend指是否挂起，如果勾选了（默认suspend），执行到断点处会停下。
蓝色的Condition指挂起的条件，勾选后，符合所写表达式的条件才会停下。
黄色的Evaluate and log指会将evaluate的值打印到console上。
红色的filters指Class的过滤，比如只看某个类的断点或者不看某个类的断点。
不同的断点方式由不同的断点条件组合而成。
- 条件断点
勾选Condition，然后写上需要的条件，比如图中我觉得Bug很可能出现在isRequestWeb = false的情况，我就把condition写上去，执行时忽略掉为true的情况，专心查看为flase的情况。
又比如循环遍历的时候，不想一直手动跳到下一个断点查看每一个循环体，就可以写一个自己想要的条件断下来。 -
日志断点
有的时候改bug，不确定问题在哪儿，不能瞎J8到处断点，一步一步的调试，这样太低效了。这时就需要打日志出来看。
但是log的代码写上bug改完后，还要把这些log删除掉，比较麻烦。更麻烦的是加写一句log，又要重新编译一次。这时就需要使用日志断点。
打上断点，把Suspend打钩取消掉，这样程序不会被断点断下来。然后evaluate and log写上需要打印的日志即可。
image.png
如图无需加代码，无需重新编译。直接再触发一次断点，在debug的Console那里就可以看到运行的日志（之前演示多线程的例子，这里就是典型的线程同步的问题，导致请求了2次网络）
-
异常断点
看断点方式那幅图绿色的箭头指向的+，显示出另外几种断点
image.png
其中第一个是方法断点：也就是断点打在方法上，断点的样子会像左边的图标那样（和在方法体里的第一行代码打断点差不多）。
第二种是field断点：用来查看字段的访问（和在getter setter断点相似）
image.png
第三种java异常断点好像有点鸡肋的，程序异常的时候，可以通过异常断点查看是哪个地方出问题了。但是崩溃的时候，也可以通过AS的崩溃日志锁定出问题的地方。
选中第三个java exception 断点，在里面输入格式转化出错的异常
image.png
OK后断点里面就有这个format异常的断点了。
image.png
图中可以看到，上面还可以选择Any Exception，即只要是exception都会断到。
强行写一个NumberFormat异常，然后重新运行，进入debug模式，触发异常：
String a = "12a";
try {
int b = Integer.parseInt(a);
} catch (NumberFormatException e) {
e.printStackTrace();
}
可以看到是MainActiviy的237行出现了NumberFormatException,点击进入到对应行，果然是那里的问题。
这里为了方便查看就把frames的调用关系隐藏掉了，点击之前frames说的那个图标即可。
异常断点可以结合各种filter使用，比如结合class Filter只查看MainActiviy里面的异常，或者不查看BinaryThree里面的异常，崩溃日志就做不到这一点。
后面的三种暂时也没用到过，就跳过了。
- 其他
调试的花样还有，比如在变量表里面setValue改变变量值、添加到watcher观察等操作。
总之一切为了提高效率！人生苦短~~
