Android studio 之 高级调试技巧，看这一篇够啦

在开发项目或者接手新项目时，为了调试程序或者熟悉项目，避免不了Debug。一般我们常用的也就单步调试等几个简单的功能。其实，Android stuido 还有好多高级的调试功能，如果，我们可以很熟悉的利用这些技巧，我们的效率绝对可以做到事半功倍的。

下面，我们看看本文的项目目录

一、日常使用

1.0，debug 项目，不再愁1.1，查看项目所有断点及删除1.2，临时断点1.3，条件断点1.4，依赖断点1.5，接口断点1.6，异常断点1.7，变量断点1.8，断点日志1.9，断点分组1.10，Log 设置1.11，主动抛出异常1.12，强制返回1.13，返回上一步1.14，添加/修改数据或查看变量的值1.15，修改数据1.16，强制抛出异常1.17，多线程调试1.18，远程调试1.19，导入Crash错误日志1.20，Android Debuger 选择调试类型 二、接手项目必备

2.1，布局查看器2.2，查看栈顶（正在显示的）Activity

一、 日常使用

1.0，debug 项目，不再愁

正常情况下，我们debug项目，需要重新编译，重新跑一遍项目，尤其是在项目大，编译时间长的时候，我们是相当痛苦的。

编译10分钟，调试20秒。

其实，我们项目正在运行的话，是可以直接给项目添加一个调试器，就可以像普通的debug一样，进行调试了。

1，点击Attach Debugger toAndroid Process 按钮2，选中我们要调试的进程，点击确定

1.1，查看项目所有断点及删除

路径：Android studio菜单栏–Run–View breakpoints 里画对号的，都是我们打的断点。点击上面的“减号”，就可以删除对应的断点。

1.2，临时断点

临时断点，执行一次就消失了。有些情况下，确实比较好用。 打断点，我们都知道，那临时断点呢？ 按住Alt键，再打断点，这样就可以了，是不是优秀

来张图，感受下两种断点的区别。圈起来的就是临时断点啦。

1.3，条件断点

有没有在调试for循环的时候，出现过这种情况呢？

调试中. i = 0 i = 1 i = 2 … i = 10 矮油，我要看i=9的情况啊…展示哥手速的时候到啦，再来一次。。。。

。

现在，我们只需要在断点上，点击右键，在Condition那里，设置我们需要的值，循环就会自动停到我们设置的那个值那里，是不是很激动。

1.4，依赖断点

顾名思义，就是一个一个断点的执行，依赖于另一个断点。如果，第一个断点不触发，那么第二个断点也不会触发；相当于绑定依赖的关系。

路径：Android studio菜单栏--Run--View breakpoints--选择断点

例如：有个功能线。A 功能点--通过 B 功能点--到达 C 功能点--到达 D 功能点--到达 E 功能点。（真是的项目，肯定要复杂的多） 假如，现在功能线出问题了，并没有走完所有的功能点。 我们就可以在A B C D E 都打上断点，并且 让E依赖D，D依赖C...B依赖A。这样的话，我们跑一遍就知道，在那个功能点上出问题了。

步骤：

1，打开View Breakpoints，如下图

2，在某个断点上，点击右键，找到Disable until hitting the following breakpoint，选中此断点要依赖的断点（依赖的断点不触发，次断点也不会触发）。如下图

1.5，接口断点

有时候，我们接手新项目时。项目太大，而且都是通过接口隔离的。我们熟悉项目的难度就会很大。 这个时候，我们可以在接口声明的方法上打断点。如果，程序结果，其实现类的时候，就会执行断点。

1.6，异常断点

路径：Android studio菜单栏--Run--View breakpoints--左上角加号---选择Java Exception breakpoints

当程序出现异常后，我们可以通过添加对应的异常断点。添加对应Exception的异常断点后，程序执行到该异常后，就会停留在异常位置。

1.7，变量断点

就是在跟其他断点一样，在变量上打断点。

变量是对象的话，记得断点右键，把Field Access勾选上。

这样的好处就是，这个变量的值在那里改变的时候，断点就会停留在哪里，如下图

省去了，我们为了查看变量赋值，到处打Log日志的麻烦。

1.8，断点日志

打印Log日志，是我们调试程序，分析代码问题的重要手段。

它也是有缺陷的：

有时候，我们会忘记，在某些重要地方打印日志。然后，会重新打日志，重新跑打印的日志。很多时候，都会忘记删除。（没有日志管理的话，很多时候会跟着发布上线）

上面的情况，我相信很多人，都碰到过吧。

那么，有什么更好的方法来打印日志呢，当然是断点日志啦。

我们可以在View Breakpoints里面，在需要打印数据的断点上，添加日志跟我们在代码里打印日志一样。如下图

这样，我们就完美的避开了上面的问题，忘记打日志了，直接断点出加上，还不用重新跑项目。

[1.9，断点分组

当我们接手的项目比较大的时候，我们需要断点调试的地方就特别多。

这个时候，我们如果能按照功能，把断点放到对应的分组。在调试某个功能时，只开启(或)对应分组的断点，是不是就会很方便呢。

你别说，还真有这个功能。

扯完啦，开工。

首先打开View Breakpoints。(路径：Run–View Breakpoints)找到要分组的断点，点击右键，Move to Group—Create New 。这样我们就创建好了分组最后，就是把该功能的其他断点，全部Move to Group到那个分组就可以了。

下图就是创建了一个test的断点分组

如果，我们暂时不想调试该功能，直接去掉 该分组前面的勾选就可以了。 如果想删除断点，选中分组，直接点击上面的“-”号就可以了

1.10，Log 设置

我们在打印Log日志的时候，会看到前面有一长串的时间，包名等等信息，看起来特变繁琐。像下面

我们只需要打开Logcat，点击其左边的设置按钮，把不需要的信息，去掉勾选就可以了。

结果

这样，是不是就清爽很多啦。

1.11，主动抛出异常

我们可以在debug的时候。通过，主动抛出异常，来检测程序的执行，是否符合我们的预期。

我们测试的时候，完全可以通过，在debug的时候，通过该技巧抛出异常，利用上面的异常断点捕获异常。 就是个玩儿…

1.12，强制返回

在某些场景下，我们需要测试不同的情况下，我们程序都是老老实实的呢。

不就是不断的修改代码的状态来验证么，小意思…直到有一次，上线时，代码好像没有改回来。。。翻车啦

现在，我们可以通过Force Return(强制返回) 来强制返回不同的情况，以达到测试的效果，还不用修改代码。终于，可以愉快的玩耍了。

看下怎么执行Force Return

最后看下效果，通过isTrue()方法，返回不同的返回值来调试我们的程序。

1.13，返回上一步

你有没有在调试的时候，碰到过这种情况，好不容易debug到我们要查看的地方，结果，一个不小心，手又快了，又的从头跑一遍。

现在，我们可以利用Drop Frame来返回上一步，是不是又可以愉快的玩耍了。

大写的注意：已经改变的变量值不会恢复。

1.14，添加/修改数据或查看变量的值

有没有遇到过，在打开debug之后，突然发现，少写了一些代码。然后，加上，重新debug，跑完，去掉的呢。

我们可以利用evaluate Expression来查看变量的属性，或者是给变量改变属性。

这个东西绝对是，调试的利器

1.15，修改数据

数量放到变量的上面，点击➕号，在变量上面右键–setValue，修改值后，就可以按照我们的测试意愿来执行了。

1.16，强制抛出异常

有的时候，我们想看看我们的程序是否健壮，会模拟异常，然后，看下是否如我们想的一样()。但是，每次调试都需要我们手动的添加，然后异常，我们自己造的异常。假如，有一天，我们忘记了移除【黑天】

现在，我们不用担心了，idea可以帮助我们强制抛出异常，是不是很兴奋。 https://www.jetbrains.com/help/idea/altering-the-program-s-execution-flow.html#throw_exception

1.17，多线程调试

之前，在多线程调试的时候，我们无法控制线程的执行顺序，这是非常头疼的【头疼，肿么调】， 后来发现，idea可以手动设置线程的执行顺序，是不是欢喜。

看下，最后调试的效果 右击断点。选中suspend+Thread。 然后，进入断点后，我们就可以切换到我们想要执行的线程上就可以了

1.18，远程调试

https://blog.csdn.net/kingdelee/article/details/83034876 https://www.jetbrains.com/help/idea/debugging-code.html#d181035e408

对于IDEA来说，只需要在Run->Edit Configuration里，增加一个Remote，设置主机Host和端口Port，然后调试它即可。

jetbrain https://www.jetbrains.com/help/idea/tutorial-java-debugging-deep-dive.html

1.19，导入Crash错误日志

项目上线后，不管使用哪个Crash抓取功能，我们看着都是非常不舒服。（费眼，不能直接点到源码位置） 那么，Android studio 有木有功能，能让我们把错误日志导入进来呢？ 答案是：当然有。

1，首先，我们把错误日志复制下来

2，然后，点击Studio工具的 Analyze—Stack Trace Or Thread Dump 就会看到下面的输入框了。

3，我们把复制的代码，粘贴进去，点击OK。就会发现错误日志跟我们平时开发时的异常一样了，直接就可以点击进去。如下图，

1.20，Android Debuger 选择调试类型

Debug项目，对我们来说是很常用的技巧。

当项目需要Debug的时候，有时候，C/C++报错的话，每次都需要停顿，像下面这样

SIGSEGV (signal SIGSEGV: invalid address (fault address: 0x0))

对调试程序来说，相当繁琐。 通过修改配置，可以选择你想调试的类型 只调试Java程序还是Java和C++程序。

** 第一步 ** 点击菜单栏----run ----Edit Configurations 打开配置项

** 第二步 **

点击选项Debugger，切换debug type，就可以了

二、接手项目必备

2.1，布局查看器

位置：sdk—tools–bin—uiautomatorviewer 功能：显示当前正在显示的UI的布局结构

功能类似于tools下面的monitor里面的DDMS查看布局文件，感觉更轻量级。 它可以帮助我们更快的熟悉，UI结构 如下图

2.2，查看栈顶（正在显示的）Activity

命令：adb shell dumpsys window | findstr mCurrentFocus 或者 adb shell dumpsys activity activities

输入命令就会，现在当前正在显示的Activity的名字，帮我们快速定位文件位置。

如果连接的设备不止一个的话，执行上面的命令，会提示，adb超过1个设备

adb.exe: more than one device/emulator

这个时候，不要慌…

执行下面命令，查看连接的设备名

adb devices

就可以看到，连接的所有设备了。

List of devices attached

6c368f57 device

emulator-5554 device

只要，在上面的命令上添加 -s [设备名]，就可以了。如下

adb -s 6c368f57 shell dumpsys window | findstr mCurrentFocus

就又可以查看，我们想看的设备正在显示的Activity名字了。

未完待续…