不再使用Debugger分析数据流

原文链接:https://medium.com/sebs-top-tips/analyse-data-flows-without-the-debugger-android-studio-protips-3-ef2885aaffd9

一般我们分析数据传递流会很费力,现在我要分享一个更好的方式。这种方式可能不能保证任何情况都有效,尤其是涉及Intent和Fragment的情况,但依然非常有用。就算是不能一下看清数据流,也可以把范围缩小,然后再脑力猜测。

为什么要说这件事呢

当我们要追踪一段代码时,一般是想知道一段数据是如何传入这段代码的,因为如果传入错误的数据可能导致crash或者是由于数据错误导致的其他bug。在这个过程中,知道数据的来源,即在哪生成的,对于找到、解决问题是至关重要的。

一般来说,要追踪一段代码,我们会设一个断点,然后努力重现出bug的情景,然后让debugger一点点运行,直到bug重现。此时,我们会看stack,尝试找出数据是哪来的,或者是让debugger继续走然后看数据去哪里。

这个方法有瑕疵。

特殊条件下断点失效

在Nick Butcher发这段状态之前,很多人都不知道在Android Studio中还可以给断点设置选项。

你可以让断点自动输出log,即使是在不停止运行的情况下。你可以设置让断点仅在某种情况下起作用。你可以让断点只在指定的实例、类中执行或者设置在断点触发多少次后失效。这个功能真不错,推荐好好读一读文档

options_breakpoint

这样一来debugger就好用多了,让IDE自动为你做检测。但如果话说到这里就结束了,那显然浪费了大家的时间。事实上,还有更好的方式。

静态数据流分析功能

事实上最好的追踪方式都不需要用到debugger。你可能会问这是什么黑科技?这要感谢IDE中内置的静态分析工具:Analyze data flow to/from here(分析这里的数据出入)

当你使用这个选项的时候,IDE会自动找出所有能向变量、参数、属性提供数据的地方,或是这些数据最终传入的地方。

比如说,如果我们想要知道一个方法中的参数是从哪里来的,就可以在这里使用Analyze Data Flow to Here。比如这里我想知道这个Listener是从哪里来的,显示如下:

flow to

而当你想知道数据最终去了哪里,就可以在一条数据上使用Analyze Data Flow from Here。在这里我们用一个监听器的构造器的参数做测试。

flow from

如果你在面板中开启了代码预览,那就完美了。

code preview

在这里我只是举了一些最简单的例子来说明,这种追踪数据的方式无疑可以减少人力,再也不用追着数据猜来猜去了。

欢迎关注我的公众号,将零碎时间都用在刷干货上!

qr

Leave a Reply

Your email address will not be published. Required fields are marked *