您的位置:首页 > 产品设计 > UI/UE

androidStuido“高级Debug”调试技巧

2018-02-22 23:33 211 查看
掌握调试技巧,提高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写上需要打印的日志即可。





如图无需加代码,无需重新编译。直接再触发一次断点,在debug的Console那里就可以看到运行的日志(之前演示多线程的例子,这里就是典型的线程同步的问题,导致请求了2次网络)

- 异常断点

看断点方式那幅图绿色的箭头指向的+,显示出另外几种断点



其中第一个是方法断点:也就是断点打在方法上,断点的样子会像左边的图标那样(和在方法体里的第一行代码打断点差不多)。

第二种是field断点:用来查看字段的访问(和在getter setter断点相似)



第三种java异常断点好像有点鸡肋的,程序异常的时候,可以通过异常断点查看是哪个地方出问题了。但是崩溃的时候,也可以通过AS的崩溃日志锁定出问题的地方。

选中第三个java exception 断点,在里面输入格式转化出错的异常



OK后断点里面就有这个format异常的断点了。



图中可以看到,上面还可以选择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观察等操作。

总之一切为了提高效率!人生苦短~~
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: