一、介绍
Findbugs,它是一个静态分析工具,它检查类或者jar文件,将字节码和一组缺陷模式进行对比以发现可能的问题。有了静态分析工具,就可以在不实际运行程序的情况下对软件进行分析。不是通过分析类文件的形式或结构来确定程序的意图,而是通常使用Visitor模式来鉴别代码是否符合一些固定的规范。Findbugs可作为一款插件用在Eclipse或 IntelliJ IDEA环境的编译器上。下面介绍一下在Android Studio中如何使用FindBugs
二、安装
2.1、在线安装:
首先打开Android studio的设置中的插件,输入findbugs,如下图所示,点击Browse查找
1.png结果如下图所示,不出意外的话第一个选择安装就没问题了,祝各位安装顺利。
2.png安装完毕之后重启Android studio,然后你就能看到一个红色小鸟图标,证明安装成功了,接下来就能进行使用了。
2.2、本地安装
下载官网:http://andrepdo.github.io/findbugs-idea/
3.png下载完毕后在Android studio中选择本地安装即可
4.png
三、通过面板使用
FindBugs支持对包级别、项目级别、模块级别、单个文件级别,以及自定义范围的Bug分析。使用方法很简单,选择你需要分析的文件,右键,选择findbugs,然后选择需要分析的文件或者资源或者项目
5.png 6.jpg
分析完毕,此时就可以对分析结果进行查看,并有针对性的去解决这些可能存在的问题
7.jpg利用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、报告
我们会得到对应的一个类似与这样的报告:
8.png四、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
网友评论