一、介绍
Findbugs，它是一个静态分析工具，它检查类或者jar文件，将字节码和一组缺陷模式进行对比以发现可能的问题。有了静态分析工具，就可以在不实际运行程序的情况下对软件进行分析。不是通过分析类文件的形式或结构来确定程序的意图，而是通常使用Visitor模式来鉴别代码是否符合一些固定的规范。Findbugs可作为一款插件用在Eclipse或 IntelliJ IDEA环境的编译器上。下面介绍一下在Android Studio中如何使用FindBugs
二、安装
2.1、在线安装：
首先打开Android studio的设置中的插件，输入findbugs，如下图所示，点击Browse查找
结果如下图所示，不出意外的话第一个选择安装就没问题了，祝各位安装顺利。
安装完毕之后重启Android studio，然后你就能看到一个红色小鸟图标，证明安装成功了，接下来就能进行使用了。
2.2、本地安装
下载官网：http://andrepdo.github.io/findbugs-idea/
下载完毕后在Android studio中选择本地安装即可
三、通过面板使用
FindBugs支持对包级别、项目级别、模块级别、单个文件级别，以及自定义范围的Bug分析。使用方法很简单，选择你需要分析的文件，右键，选择findbugs，然后选择需要分析的文件或者资源或者项目
分析完毕，此时就可以对分析结果进行查看，并有针对性的去解决这些可能存在的问题
利用findbugs可以找到潜在的很多问题，避免上线后才发现这些低级的问题
最后可以为这些bug定义等级，发布到控制台，然后逐一解决.
四、通过集成在gradle使用
建议在每个project的module下的build.gradle中进行修改
4.1、添加插件
apply plugin: 'com.android.application'
//下面是添加的
apply plugin: 'findbugs'
4.2、添加 task :
task findbugs(type: FindBugs,dependsOn:'assembleDebug') {
ignoreFailures= true
effort= "default"
reportLevel= "high"
println( "$project.buildDir")
classes = files("$project.buildDir/intermediates/classes")
source= fileTree("src/main/java/")
classpath= files()
reports{
xml.enabled=false
html.enabled=true
xml {
destination "$project.buildDir/findbugs.xml"
}
html{
destination "$project.buildDir/findbugs.html"
}
}
}
定义一个task任务，这个任务的类型是FindBugs，依赖assembleDebug先生成.classe文件。
- ignoreFailures：有警告错误的时候也是允许构建。
- reportLevel:报告的级别，Low,Medium,High一般来说我们首先关注的是高级别的报告，再关注低一级别的报告。
- classes和source分别是对应的.classe文件夹地址，和源代码文件地址。
- repoets指定报告类型，有两种方式xml和html，只允许一种输出格式。
4.3、运行方式
在右侧的Gradle的对于的Module可以在Tasks中找到对应的findBugs任务，点击即可运行。也可以在控制台输入gradle findbugs或./gradlew findbugs,执行完成会看到report 生成的路径信息
FindBugs rule violations were found. See the report at: file:///Users/.../app/build/reports/findbugs/findbugs.html
4.4、报告
我们会得到对应的一个类似与这样的报告:
四、bug种类
以下是搜罗的一些关于findBugs发现的bug种类说明
Bad practice 坏的实践
一些不好的实践，下面列举几个：
- HE： 类定义了equals()，却没有hashCode()；或类定义了equals()，却使用Object.hashCode()；或类定义了hashCode()，却没有equals()；或类定义了hashCode()，却使用Object.equals()；类继承了equals()，却使用Object.hashCode()。
- SQL：Statement 的execute方法调用了非常量的字符串；或Prepared Statement是由一个非常量的字符串产生。
- DE： 方法终止或不处理异常，一般情况下，异常应该被处理或报告，或被方法抛出。
Malicious code vulnerability 可能受到的恶意攻击
如果代码公开，可能受到恶意攻击的代码，下面列举几个：
- FI： 一个类的finalize()应该是protected，而不是public的。
- MS：属性是可变的数组；属性是可变的Hashtable；属性应该是package protected的。
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。
Dodgy 危险的
具有潜在危险的代码，可能运行期产生错误，下面列举几个：
- CI： 类声明为final但声明了protected的属性。
- DLS：对一个本地变量赋值，但却没有读取该本地变量；本地变量赋值成null，却没有读取该本地变量。
- ICAST： 整型数字相乘结果转化为长整型数字，应该将整型先转化为长整型数字再相乘。
- INT：没必要的整型数字比较，如X <= Integer.MAX_VALUE。
- NP： 对readline()的直接引用，而没有判断是否null；对方法调用的直接引用，而方法可能返回null。
- REC：直接捕获Exception，而实际上可能是RuntimeException。
- ST： 从实例方法里直接修改类变量，即static属性。
Performance 性能问题
可能导致性能不佳的代码，下面列举几个：
- DM：方法调用了低效的Boolean的构造器，而应该用Boolean.valueOf(…)；用类似Integer.toString(1) 代替new Integer(1).toString()；方法调用了低效的float的构造器，应该用静态的valueOf方法。
- SIC：如果一个内部类想在更广泛的地方被引用，它应该声明为static。
- SS： 如果一个实例属性不被读取，考虑声明为static。
- UrF：如果一个属性从没有被read，考虑从类中去掉。
- UuF：如果一个属性从没有被使用，考虑从类中去掉。
Multithreaded correctness
多线程的正确性多线程编程时，可能导致错误的代码，下面列举几个：
- ESync：空的同步块，很难被正确使用。
- MWN：错误使用notify()，可能导致IllegalMonitorStateException异常；或错误的使用wait()。
- No： 使用notify()而不是notifyAll()，只是唤醒一个线程而不是所有等待的线程。
- SC： 构造器调用了Thread.start()，当该类被继承可能会导致错误。
Internationalization 国际化
当对字符串使用upper或lowercase方法，如果是国际的字符串，可能会不恰当的转换。
五、扩展
官方文档
https://docs.gradle.org/current/dsl/org.gradle.api.plugins.quality.FindBugs.html
