Android Studio插件bug终结者——findbugs精解

在程序开发中，bug是不可避免的，但是在版本提交测试之前，快速的定位bug还是可以有效的规避风险的。FindBug插件便是用于分析代码中的bug，在Android Studio中也提供了很好的支持。我看过别人的有关findbug的讲解，都太过肤浅，没有找到使用它的难点所在，所以便自己一边使用摸索，一边总结出一篇关于FindBug使用详解。

http://findbugs.sourceforge.net/bugDescriptions.html#RV_RETURN_VALUE_IGNORED_INFERRED

Findbugs是什么

Findbugs是一个静态分析工具，它检查类或者JAR 文件，将字节码与一组缺陷模式进行对比以发现可能的问题。Findbugs自带检测器，其中有60余种Bad practice【坏的实践】，80余种Correctness【一般正确性】，1种 Internationalization【国际化】，12种Malicious code vulnerability【可能的恶意攻击】，27种Multithreaded correctness【多线程的正确性】，23种Performance【性能问题】，43种Dodgy【潜在的危险，不可靠的代码】。

如何在Android Studio中使用FindBug插件

一、下载安装FindBugs插件；
在Plugins中下载安装FindBugs-Idea，安装方法和其他插件相同，不了解的请参考：
二、配置FindBugs插件；
在Setting中Other Settings中有FindBugs 的配置。FindBugs中配置项较多，其中我们需要设置的是Report，在这里你可以你选择你想要检测的bug类型。这里的类型与上面Findbugs的bug类型一一对应。

三、使用FindBugs插件；

1.分析当前文件，就是你当前操作的类；
2.分析当前包文件下的bug，当前操作类所在的包；
3.分析当前所在module中的bug；
4.分析整个项目中的bug；
5.分析自定义范围中bug；
6.分析所有module中的bug，不包括引用的库文件；
7~10主要是分析完毕记录排序方式
7是按照Fingbug的目录查看，如上图
8是以类为单位查看，查看某个类中bug；
9是以包为单位查看
10是以bug的级别查看

除了在FindBugs视图中可以分析bug外，可以选中类文件，包，module，右键可以找到FindBugs进行bug分析。

四、分析bugs产生的原因；
定位bug：在右边的bug目录中，层层深入，点击最里面的文件就可以bug发生的位置；
分析bug：一般bug所在的目录已经初步定位了bug发生的原因，如下图可以在网页端查看bug的具体原因。

bug指导文档
五、常见的bug事项

Bad practice 坏的实践

一些不好的实践，下面列举几个：

HE： 类定义了equals()，却没有hashCode()；或类定义了equals()，却使用

Object.hashCode()；或类定义了hashCode()，却没有equals()；或类定义了hashCode()，却使用Object.equals()；类继承了equals()，却使用Object.hashCode()。

SQL：Statement 的execute方法调用了非常量的字符串；或Prepared Statement是由一个非常量的字符串产生。

DE： 方法终止或不处理异常，一般情况下，异常应该被处理或报告，或被方法抛出。

Correctness 一般的正确性问题

可能导致错误的代码，下面列举几个：

NP： 空指针被引用；在方法的异常路径里，空指针被引用；方法没有检查参数是否null；null值产生并被引用；null值产生并在方法的异常路径被引用；传给方法一个声明为@NonNull的null参数；方法的返回值声明为@NonNull实际是null。

Nm： 类定义了hashcode()方法，但实际上并未覆盖父类Object的hashCode()；类定义了tostring()方法，但实际上并未覆盖父类Object的toString()；很明显的方法和构造器混淆；方法名容易混淆。

SQL：方法尝试访问一个Prepared Statement的0索引；方法尝试访问一个ResultSet的0索引。

UwF：所有的write都把属性置成null，这样所有的读取都是null，这样这个属性是否有必要存在；或属性从没有被write。

Internationalization 国际化

当对字符串使用upper或lowercase方法，如果是国际的字符串，可能会不恰当的转换。

Malicious code vulnerability 可能受到的恶意攻击

如果代码公开，可能受到恶意攻击的代码，下面列举几个：

FI： 一个类的finalize()应该是protected，而不是public的。

MS：属性是可变的数组；属性是可变的Hashtable；属性应该是package protected的。

Multithreaded correctness 多线程的正确性

多线程编程时，可能导致错误的代码，下面列举几个：

ESync：空的同步块，很难被正确使用。

MWN：错误使用notify()，可能导致IllegalMonitorStateException异常；或错误的

使用wait()。

No： 使用notify()而不是notifyAll()，只是唤醒一个线程而不是所有等待的线程。

SC： 构造器调用了Thread.start()，当该类被继承可能会导致错误。

Performance 性能问题

可能导致性能不佳的代码，下面列举几个：

DM：方法调用了低效的Boolean的构造器，而应该用Boolean.valueOf(…)；用类似

Integer.toString(1) 代替new Integer(1).toString()；方法调用了低效的float的构造器，应该用静态的valueOf方法。

SIC：如果一个内部类想在更广泛的地方被引用，它应该声明为static。

SS： 如果一个实例属性不被读取，考虑声明为static。

UrF：如果一个属性从没有被read，考虑从类中去掉。

UuF：如果一个属性从没有被使用，考虑从类中去掉。

Dodgy 危险的

具有潜在危险的代码，可能运行期产生错误，下面列举几个：

CI： 类声明为final但声明了protected的属性。

DLS：对一个本地变量赋值，但却没有读取该本地变量；本地变量赋值成null，却没有读取该本地变量。

ICAST： 整型数字相乘结果转化为长整型数字，应该将整型先转化为长整型数字再相乘。

INT：没必要的整型数字比较，如X <= Integer.MAX_VALUE。

NP： 对readline()的直接引用，而没有判断是否null；对方法调用的直接引用，而方法可能返回null。

REC：直接捕获Exception，而实际上可能是RuntimeException。

ST： 从实例方法里直接修改类变量，即static属性。

bug是无孔不入，无所不在的，仅仅靠FingBugs是不靠谱的，需要我们在编码过程中逻辑缜密，胆大心细。