Android静态代码扫描效率优化与实践

背景与问题

DevOps实践中，我们在CI(Continuous Integration)持续集成过程主要包含了代码提交、静态检测、单元测试、编译打包环节。其中静态代码检测可以在编码规范，代码缺陷，性能等问题上提前预知，从而保证项目的交付质量。Android项目常用的静态扫描工具包括CheckStyle、Lint、FindBugs等，为降低接入成本，美团点评集团内部孵化了静态代码扫描插件，集合了以上常用的扫描工具。项目初期引入集团内部基建时我们接入了代码扫描插件，在PR(Pull Request)流程中借助Jenkins插件来触发自动化构建，从而达到监控代码质量的目的。初期单次构建耗时平均在1~2min左右，对研发效率影响甚少。但是随着时间推移，代码量随业务倍增，项目也开始使用Flavor来满足复杂的需求，这使得我们的单次PR构建达到了8~9min左右，其中静态代码扫描的时长约占50%，持续集成效率不高，对我们的研发效率带来了挑战。

思考与策略

针对以上的背景和问题，我们思考以下几个问题：

思考一：现有插件包含的扫描工具是否都是必需的？

扫描工具对比

为了验证扫描工具的必要性，我们关心以下一些维度：

扫码侧重点，对比各个工具分别能针对解决什么类型的问题；
内置规则种类，列举各个工具提供的能力覆盖范围；
扫描对象，对比各个工具针对什么样的文件类型扫描；
原理简介，简单介绍各个工具的扫描原理；
优缺点，简单对比各个工具扫描效率、扩展性、定制性、全面性上的表现。

注：FindBugs只支持Java1.0~1.8，已经被SpotBugs替代。鉴于部分老项目并没有迁移到Java8，目前我们并没有使用SpotBugs代替FindBugs的原因如下，详情参考官方文档。同时，SpotBugs的作者也在讨论是否让SpotBugs支持老的Java版本，结论是不提供支持。

经过以上的对比分析我们发现，工具的诞生都能针对性解决某一领域问题。CheckStyle的扫描速度快效率高，对代码风格和圈复杂度支持友好；FindBugs针对Java代码潜在问题，能帮助我们发现编码上的一些错误实践以及部分安全问题和性能问题；Lint是官方深度定制，功能极其强大，且可定制性和扩展性以及全面性都表现良好。所以综合考虑，针对思考一，我们的结论是整合三种扫描工具，充分利用每一个工具的领域特性。

思考二：是否可以优化扫描过程？

既然选择了整合这几种工具，我们面临的挑战是整合工具后扫描效率的问题，首先来分析目前的插件到底耗时在哪里。

静态代码扫描耗时分析

Android项目的构建依赖Gradle工具，一次构建过程实际上是执行所有的Gradle Task。由于Gradle的特性，在构建时各个Module都需要执行CheckStyle、FindBugs、Lint相关的Task。对于Android来说，Task的数量还与其构建变体Variant有关，其中Variant = Flavor * BuildType。所以一个Module执行的相关任务可以由以下公式来描述：Flavor * BuildType *（Lint，CheckStyle，Findbugs），其中*为笛卡尔积。如下图所示：

可以看到，一次构建全量扫描执行的Task跟Varint个数正相关。对于现有工程的任务，我们可以看一下目前各个任务的耗时情况：（以实际开发中某一次扫描为例）

通过对Task耗时排序，主要的耗时体现在FindBugs和Lint对每一个Module的扫描任务上，CheckStyle任务并不占主要影响。整体来看，除了工具本身的扫描时间外，耗时主要分为多Module、多Variant带来的任务数量耗时。

优化思路分析

对于工具本身的扫描时间，一方面受工具自身扫描算法和检测规则的影响，另一方面也跟扫描的文件数量相关。针对源码类型的工具比如CheckStyle和Lint，需要经过词法分析、语法分析生成抽象语法树，再遍历抽象语法树跟定义的检测规则去匹配；而针对字节码文件的工具FindBugs，需要先编译源码成Class文件，再通过BCEL分析字节码指令并与探测器规则匹配。如果要在工具本身算法上去寻找优化点，代价比较大也不一定能找到有效思路，投入产出比不高，所以我们把精力放在减少Module和Variant带来的影响上。

从上面的耗时分析可以知道，Module和Variant数直接影响任务数量，一次PR提交的场景是多样的，比如多Module多Variant都有修改，所以要考虑这些都修改的场景。先分析一个Module多Variant的场景，考虑到不同的Variant下源代码有一定差异，并且FindBugs扫描针对的是Class文件，不同的Variant都需要编译后才能扫描，直接对多Variant做处理比较复杂。我们可以简化问题，用以空间换时间的方式，在提交PR的时候根据Variant用不同的Jenkins Job来执行每一个Variant的扫描任务。所以接下来的问题就转变为如何优化在扫描单个Variant的时候多Module任务带来的耗时。

对于Module数而言，我们可以将其抽取成组件，拆分到独立仓库，将扫描任务拆分到各自仓库的变动时期，以aar的形式集成到主项目来减少Module带来的任务数。那对于剩下的Module如何优化呢？无论是哪一种工具，都是对其输入文件进行处理，CheckStyle对Java源代码文件处理，FindBugs对Java字节码文件处理，如果我们可以通过一次任务收集到所有Module的源码文件和编译后的字节码文件，我们就可以减少多Module的任务了。所以对于全量扫描，我们的主要目标是来解决如何一次性收集所有Module的目标文件。

思考三：是否支持增量扫描？

上面的优化思路都是基于全量扫描的，解决的是多Module多Variant带来的任务数量耗时。前面提到，工具本身的扫描时间也跟扫描的文件数量有关，那么是否可以从扫描的文件数量来入手呢？考虑平时的开发场景，提交PR时只是部分文件修改，我们没必要把那些没修改过的存量文件再参与扫描，而只针对修改的增量文件扫描，这样能很大程度降低无效扫描带来的效率问题。有了思路，那么我们考虑以下几个问题：

如何收集增量文件，包括源码文件和Class文件？
现在业界是否有增量扫描的方案，可行性如何，是否适用我们现状？
各个扫描工具如何来支持增量文件的扫描？

根据上面的分析与思考路径，接下来我们详细介绍如何解决上述问题。

优化探索与实践

全量扫描优化

搜集所有Module目标文件集

获取所有Module目标文件集，首先要找出哪些Module参与了扫描。一个Module工程在Gradle构建系统中被描述为一个“Project”，那么我们只需要找出主工程依赖的所有Project即可。由于依赖配置的多样性，我们可以选择在某些Variant下依赖不同的Module，所以获取参与一次构建时与当前Variant相关的Project对象，我们可以用如下方式：

static Set<Project> collectDepProject(Project project, BaseVariant variant, Set<Project> result = null) {if (result == null) {result = new HashSet<>()}Set taskSet = variant.javaCompiler.taskDependencies.getDependencies(variant.javaCompiler)taskSet.each { Task task ->if (task.project != project && hasAndroidPlugin(task.project)) {result.add(task.project)BaseVariant childVariant = getVariant(task.project)if (childVariant.name == variant.name || "${variant.flavorName}${childVariant.buildType.name}".toLowerCase() == variant.name.toLowerCase()) {collectDepProject(task.project, childVariant, result)}}}return result
}

目前文件集分为两类，一类是源码文件，另一类是字节码文件，分别可以如下处理：

projectSet.each { targetProject ->if (targetProject.plugins.hasPlugin(CodeDetectorPlugin) && GradleUtils.hasAndroidPlugin(targetProject)) {GradleUtils.getAndroidExtension(targetProject).sourceSets.all { AndroidSourceSet sourceSet ->if (!sourceSet.name.startsWith("test") && !sourceSet.name.startsWith(SdkConstants.FD_TEST)) {source sourceSet.java.srcDirs}}}
}

注：上面的Source是CheckStyle Task的属性，用其来指定扫描的文件集合；

// 排除掉一些模板代码class文件
static final Collection<String> defaultExcludes = (androidDataBindingExcludes + androidExcludes + butterKnifeExcludes + dagger2Excludes).asImmutable()List<ConfigurableFileTree> allClassesFileTree = new ArrayList<>()
ConfigurableFileTree currentProjectClassesDir = project.fileTree(dir: variant.javaCompile.destinationDir, excludes: defaultExcludes)
allClassesFileTree.add(currentProjectClassesDir)
GradleUtils.collectDepProject(project, variant).each { targetProject ->if (targetProject.plugins.hasPlugin(CodeDetectorPlugin) && GradleUtils.hasAndroidPlugin(targetProject)) {// 可能有的工程没有Flavor只有buildTypeGradleUtils.getAndroidVariants(targetProject).each { BaseVariant targetProjectVariant ->if (targetProjectVariant.name == variant.name || "${targetProjectVariant.name}".toLowerCase() == variant.buildType.name.toLowerCase()) {allClassesFileTree.add(targetProject.fileTree(dir: targetProjectVariant.javaCompile.destinationDir, excludes: defaultExcludes))}}}
}

注：收集到字节码文件集后，可以用通过FindBugsTask 的 Class 属性指定扫描，后文会详细介绍FindBugs Task相关属性。

对于Lint工具而言，相应的Lint Task并没有相关属性可以指定扫描文件，所以在全量扫描上，我们暂时没有针对Lint做优化。

全量扫描优化数据

通过对CheckStyle和FindBugs全量扫描的优化，我们将整体扫描时间由原来的9min降低到了5min左右。

增量扫描优化

由前面的思考分析我们知道，并不是所有的文件每次都需要参与扫描，所以我们可以通过增量扫描的方式来提高扫描效率。

增量扫描技术调研

在做具体技术方案之前，我们先调研一下业界的现有方案，调研如下：

针对Lint，我们可以借鉴现有实现思路，同时深入分析扫描原理，在3.x版本上寻找出增量扫描的解决方案。对于CheckStyle和FindBugs，我们需要了解工具的相关配置参数，为其指定特定的差异文件集合。

注：业界有一些增量扫描的案例，例如diff_cover，此工具主要是对单元测试整体覆盖率的检测，以增量代码覆盖率作为一个指标来衡量项目的质量，但是这跟我们的静态代码分析的需求不太符合。它有一个比较好的思路是找出差异的代码行来分析覆盖率，粒度比较细。但是对于静态代码扫描，仅仅的差异行不足以完成上下文的语义分析，尤其是针对FindBugs这类需要分析字节码的工具，获取的差异行还需要经过编译成Class文件才能进行分析，方案并不可取。

寻找增量修改文件

增量扫描的第一步是获取待扫描的目标文件。我们可以通过git diff命令来获取差异文件，值得注意的是对于删除的文件和重命名的文件需要忽略，我们更关心新增和修改的文件，并且只需要获取差异文件的路径就好了。举个例子：git diff –name-only –diff-filter=dr commitHash1 commitHash2，以上命令意思是对比两次提交记录的差异文件并获取路径，过滤删除和重命名的文件。对于寻找本地仓库的差异文件上面的命令已经足够了，但是对于PR的情况还有一些复杂，需要对比本地代码与远程仓库目标分支的差异。集团的代码管理工具在Jenkins上有相应的插件，该插件默认提供了几个参数，我们需要用到以下两个： - ${targetBranch}：需要合入代码的目标分支地址； - ${sourceCommitHash}：需要提交的代码hash值；

通过这两个参数执行以下一系列命令来获取与远程目标分支的差异文件。

git remote add upstream ${upstreamGitUrl}
git fetch upstream ${targetBranch}
git diff --name-only --diff-filter=dr $sourceCommitHash upstream/$targetBranch

配置远程分支别名为UpStream，其中upstreamGitUrl可以在插件提供的配置属性中设置；
获取远程目标分支的更新；
比较分支差异获取文件路径。

通过以上方式，我们找到了增量修改文件集。

Lint扫描原理分析

在分析Lint增量扫描原理之前，先介绍一下Lint扫描的工作流程：

App Source Files

项目中的源文件，包括Java、XML、资源文件、proGuard等。

lint.xml

用于配置希望排除的任何 Lint 检查以及自定义问题严重级别，一般各个项目都会根据自身项目情况自定义的lint.xml来排除一些检查项。

lint Tool

一套完整的扫描工具用于对Android的代码结构进行分析，可以通过命令行、IDEA、Gradle命令三种方式运行lint工具。

lint Output

Lint扫描的输出结果。

从上面可以看出，Lint Tool就像一个加工厂，对投入进来的原料（源代码）进行加工处理（各种检测器分析），得到最终的产品（扫描结果）。Lint Tool作为一个扫描工具集，有多种使用方式。Android为我们提供了三种运行方式，分别是命令行、IDEA、Gradle任务。这三种方式最终都殊途同归，通过LintDriver来实现扫描。如下图所示：

为了方便查看源码，新建一个工程，在build.gradle脚本中，添加如下依赖：

compile 'com.android.tools.build:gradle:3.1.1'
compile 'com.android.tools.lint:lint-gradle:26.1.1'

我们可以得到如下所示的依赖：

lint-api-26.1.1

Lint工具集的一个封装，实现了一组API接口，用于启动Lint；

lint-checks-26.1.1

一组内建的检测器，用于对这种描述好Issue进行分析处理；

lint-26.1.1

可以看做是依赖上面两个jar形成的一个基于命令行的封装接口形成的脚手架工程，我们的命令行、Gradle任务都是继承自这个jar包中相关类来做的实现；

lint-gradle-26.1.1

可以看做是针对Gradle任务这种运行方式，基于lint-26.1.1做了一些封装类；

lint-gradle-api-26.1.1

真正Gradle Lint任务在执行时调用的入口；

在理解清楚了以上几个jar的关系和作用之后，我们可以发现Lint的核心库其实是前三个依赖。后面两个其实是基于脚手架，对Gradle这种运行方式做的封装。最核心的逻辑在LintDriver的Analyze方法中。

fun analyze() {...省略部分代码...for (project in projects) {fireEvent(EventType.REGISTERED_PROJECT, project = project)}registerCustomDetectors(projects)...省略部分代码...try {for (project in projects) {phase = 1val main = request.getMainProject(project)// The set of available detectors varies between projectscomputeDetectors(project)if (applicableDetectors.isEmpty()) {// No detectors enabled in this project: skip itcontinue}checkProject(project, main)if (isCanceled) {break}runExtraPhases(project, main)}} catch (throwable: Throwable) {// Process canceled etcif (!handleDetectorError(null, this, throwable)) {cancel()}}...省略部分代码...
}

主要是以下三个重要步骤：

registerCustomDetectors(projects)

Lint为我们提供了许多内建的检测器，除此之外我们还可以自定义一些检测器，这些都需要注册进Lint工具用于对目标文件进行扫描。这个方法主要做以下几件事情：

遍历每一个Project和它的依赖Library工程，通过client.findRuleJars来找出自定义的jar包；
通过client.findGlobalRuleJars找出全局的自定义jar包，可以作用于每一个Android工程；
从找到的jarFiles列表中，解析出自定义的规则，并与内建的Registry一起合并为CompositeIssueRegistry；需要注意的是，自定义的Lint的jar包存放位置是build/intermediaters/lint目录，如果是需要每一个工程都生效，则存放位置为~/.android/lint/。

computeDetectors(project)

这一步主要用来收集当前工程所有可用的检测器。

checkProject(project, main)接下来这一步是最为关键的一步。在此方法中，调用runFileDetectors来进行文件扫描。Lint支持的扫描文件类型很多，因为是官方支持，所以针对Android工程支持的比较友好。一次Lint任务运行时，Lint的扫描范围主要由Scope来描述。具体表现在：

fun infer(projects: Collection<Project>?): EnumSet<Scope> {if (projects == null || projects.isEmpty()) {return Scope.ALL}// Infer the scopevar scope = EnumSet.noneOf(Scope::class.java)for (project in projects) {val subset = project.subsetif (subset != null) {for (file in subset) {val name = file.nameif (name == ANDROID_MANIFEST_XML) {scope.add(MANIFEST)} else if (name.endsWith(DOT_XML)) {scope.add(RESOURCE_FILE)} else if (name.endsWith(DOT_JAVA) || name.endsWith(DOT_KT)) {scope.add(JAVA_FILE)} else if (name.endsWith(DOT_CLASS)) {scope.add(CLASS_FILE)} else if (name.endsWith(DOT_GRADLE)) {scope.add(GRADLE_FILE)} else if (name == OLD_PROGUARD_FILE || name == FN_PROJECT_PROGUARD_FILE) {scope.add(PROGUARD_FILE)} else if (name.endsWith(DOT_PROPERTIES)) {scope.add(PROPERTY_FILE)} else if (name.endsWith(DOT_PNG)) {scope.add(BINARY_RESOURCE_FILE)} else if (name == RES_FOLDER || file.parent == RES_FOLDER) {scope.add(ALL_RESOURCE_FILES)scope.add(RESOURCE_FILE)scope.add(BINARY_RESOURCE_FILE)scope.add(RESOURCE_FOLDER)}}} else {// Specified a full project: just use the full project scopescope = Scope.ALLbreak}}
}

可以看到，如果Project的Subset为Null，Scope就为Scope.ALL，表示本次扫描会针对能检测的所有范围，相应地在扫描时也会用到所有全部的Detector来扫描文件。

如果Project的Subset不为Null，就遍历Subset的集合，找出Subset中的文件分别对应哪些范围。其实到这里我们已经可以知道，Subset就是我们增量扫描的突破点。接下来我们看一下runFileDetectors：

if(scope.contains(Scope.JAVA_FILE)||scope.contains(Scope.ALL_JAVA_FILES)){val checks = union(scopeDetectors[Scope.JAVA_FILE],scopeDetectors[Scope.ALL_JAVA_FILES])if (checks != null && !checks.isEmpty()) {val files = project.subsetif (files != null) {checkIndividualJavaFiles(project, main, checks, files)} else {val sourceFolders = project.javaSourceFoldersval testFolders = if (scope.contains(Scope.TEST_SOURCES))project.testSourceFolderselseemptyList<File> ()val generatedFolders = if (isCheckGeneratedSources)project.generatedSourceFolderselseemptyList<File> ()checkJava(project, main, sourceFolders, testFolders, generatedFolders, checks)}}
}

这里更加明确，如果project.subset不为空，就对单独的Java文件扫描，否则，就对源码文件和测试目录以及自动生成的代码目录进行扫描。整个runFileDetectors的扫描顺序入下：

Scope.MANIFEST
Scope.ALL_RESOURCE_FILES)|| scope.contains(Scope.RESOURCE_FILE) || scope.contains(Scope.RESOURCE_FOLDER) || scope.contains(Scope.BINARY_RESOURCE_FILE)
scope.contains(Scope.JAVA_FILE) || scope.contains(Scope.ALL_JAVA_FILES)
scope.contains(Scope.CLASS_FILE) || scope.contains(Scope.ALL_CLASS_FILES) || scope.contains(Scope.JAVA_LIBRARIES)
scope.contains(Scope.GRADLE_FILE)
scope.contains(Scope.OTHER)
scope.contains(Scope.PROGUARD_FILE)
scope.contains(Scope.PROPERTY_FILE)

与官方文档的描述顺序一致。

现在我们已经知道，增量扫描的突破点其实是需要构造project.subset对象。

/*** Adds the given file to the list of files which should be checked in this* project. If no files are added, the whole project will be checked.** @param file the file to be checked*/public void addFile(@NonNull File file) {if (files == null) {files = new ArrayList<>();}files.add(file);}/*** The list of files to be checked in this project. If null, the whole* project should be checked.** @return the subset of files to be checked, or null for the whole project*/@Nullablepublic List<File> getSubset() {return files;}

注释也很明确的说明了只要Files不为Null，就会扫描指定文件，否则扫描整个工程。

Lint增量扫描Gradle任务实现

前面分析了如何获取差异文件以及增量扫描的原理，分析的重点还是侧重在Lint工具本身的实现机制上。接下来分析，在Gradle中如何实现一个增量扫描任务。大家知道，通过执行./gradlew lint命令来执行Lint静态代码检测任务。创建一个新的Android工程，在Gradle任务列表中可以在Verification这个组下面找到几个Lint任务，如下所示：

这几个任务就是 Android Gradle插件在加载的时候默认创建的。分别对应于以下几个Task：

lint->LintGlobalTask：由TaskManager创建；
lintDebug、lintRelease、lintVitalRelease->LintPerVariantTask：由ApplicationTaskManager或者LibraryTaskManager创建，其中lintVitalRelease只在release下生成；

所以，在Android Gradle 插件中，应用于Lint的任务分别为LintGlobalTask和LintPerVariantTask。他们的区别是前者执行的是扫描所有Variant，后者执行只针对单独的Variant。而我们的增量扫描任务其实是跟Variant无关的，因为我们会把所有差异文件都收集到。无论是LintGlobalTask或者是LintPerVariantTask，都继承自LintBaseTask。最终的扫描任务在LintGradleExecution的runLint方法中执行，这个类位于lint-gradle-26.1.1中，前面提到这个库是基于Lint的API针对Gradle任务做的一些封装。

/** Runs lint on the given variant and returns the set of warnings */private Pair<List<Warning>, LintBaseline> runLint(@Nullable Variant variant,@NonNull VariantInputs variantInputs,boolean report, boolean isAndroid) {IssueRegistry registry = createIssueRegistry(isAndroid);LintCliFlags flags = new LintCliFlags();LintGradleClient client =new LintGradleClient(descriptor.getGradlePluginVersion(),registry,flags,descriptor.getProject(),descriptor.getSdkHome(),variant,variantInputs,descriptor.getBuildTools(),isAndroid);boolean fatalOnly = descriptor.isFatalOnly();if (fatalOnly) {flags.setFatalOnly(true);}LintOptions lintOptions = descriptor.getLintOptions();if (lintOptions != null) {syncOptions(lintOptions,client,flags,variant,descriptor.getProject(),descriptor.getReportsDir(),report,fatalOnly);} else {// Set up some default reportersflags.getReporters().add(Reporter.createTextReporter(client, flags, null,new PrintWriter(System.out, true), false));File html = validateOutputFile(createOutputPath(descriptor.getProject(), null, ".html",null, flags.isFatalOnly()));File xml = validateOutputFile(createOutputPath(descriptor.getProject(), null, DOT_XML,null, flags.isFatalOnly()));try {flags.getReporters().add(Reporter.createHtmlReporter(client, html, flags));flags.getReporters().add(Reporter.createXmlReporter(client, xml, false));} catch (IOException e) {throw new GradleException(e.getMessage(), e);}}if (!report || fatalOnly) {flags.setQuiet(true);}flags.setWriteBaselineIfMissing(report && !fatalOnly);Pair<List<Warning>, LintBaseline> warnings;try {warnings = client.run(registry);} catch (IOException e) {throw new GradleException("Invalid arguments.", e);}if (report && client.haveErrors() && flags.isSetExitCode()) {abort(client, warnings.getFirst(), isAndroid);}return warnings;}

我们在这个方法中看到了warnings = client.run(registry)，这就是Lint扫描得到的结果集。总结一下这个方法中做了哪些准备工作用于Lint扫描： 1. 创建IssueRegistry，包含了Lint内建的BuiltinIssueRegistry； 2. 创建LintCliFlags； 3. 创建LintGradleClient，这里面传入了一大堆参数，都是从Gradle Android 插件的运行环境中获得； 4. 同步LintOptions，这一步是将我们在build.gralde中配置的一些Lint相关的DSL属性，同步设置给LintCliFlags，给真正的Lint 扫描核心库使用； 5. 执行Client的Run方法，开始扫描。

扫描的过程上面的原理部分已经分析了，现在我们思考一下如何构造增量扫描的任务。我们已经分析到扫描的关键点是client.run(registry)，所以我们需要构造一个Client来执行扫描。一个想法是通过反射来获取Client的各个参数，当然这个思路是可行的，我们也验证过实现了一个用反射方式构造的Client。但是反射这种方式有个问题是丢失了从Gradle任务执行到调用Lint API开始扫描这一过程中做的其他事情，侵入性比较高，所以我们最终采用继承LintBaseTask自行实现增量扫描任务的方式。

FindBugs扫描简介

FindBugs是一个静态分析工具，它检查类或者JAR 文件，通过Apache的BCEL库来分析Class，将字节码与一组缺陷模式进行对比以发现问题。FindBugs自身定义了一套缺陷模式，目前的版本3.0.1内置了总计300多种缺陷，详细可参考官方文档。FindBugs作为一个扫描的工具集，可以非常灵活的集成在各种编译工具中。接下来，我们主要分析在Gradle中FindBugs的相关内容。

Gradle FindBugs任务属性分析

在Gradle的内置任务中，有一个FindBugs的Task，我们看一下官方文档对Gradle属性的描述。

选几个比较重要的属性介绍：

Classes 该属性表示我们要分析的Class文件集合，通常我们会把编译结果的Class目录用于扫描。
Classpath 分析目标集合中的Class需要用到的所有相关的Classes路径，但是并不会分析它们自身，只用于扫描。
Effort 包含MIN，Default，MAX，级别越高，分析得越严谨越耗时。
findBugs ClasspathFinbugs库相关的依赖路径，用于配置扫描的引擎库。
reportLevel 报告级别，分为Low，Medium，High。如果为Low，所有Bug都报告，如果为High，仅报告High优先级。
Reports 扫描结果存放路径。

通过以上属性解释，不难发现要FindBugs增量扫描，只需要指定Classes的文件集合就可以了。

FindBugs任务增量扫描分析

在做增量扫描任务之前，我们先来看一下FindBugs IDEA插件是如何进行单个文件扫描的。

我们选择Analyze Current File对当前文件进行扫描，扫描结果如下所示：

可以看到确实只扫描了一个文件。那么扫描到底使用了哪些输入数据呢，我们可以通过扫描结果的提示清楚看到：

这里我们能看到很多有用的信息：

源码目录列表，包含了工程中的Java目录，res目录，以及编译过程中生成的一些类目录；
需要分析的目标Class集合，为编译后的Build目录下的当前Java文件对应的Class文件；
Aux Classpath Entries,表示分析上面的目标文件需要用到的类路径。

所以，根据IDEA的扫描结果来看，我们在做增量扫描的时候需要解决上面这几个属性的获取。在前面我们分析的属性是Gradle在FindBugs lib的基础上，定义的一套对应的Task属性。真正的FinBugs属性我们可以通过官方文档或者源码中查到。

配置AuxClasspath

前文提到，ClassPath是用来分析目标文件需要用到的相关依赖Class，但本身并不会被分析，所以我们需要尽可能全的找到所有的依赖库，否则在扫描的时候会报依赖的类库找不到。

FileCollection buildClasses = project.fileTree(dir: "${project.buildDir}/intermediates/classes/${variant.flavorName}/${variant.buildType.name}",includes: classIncludes)FileCollection targetClasspath = project.files()
GradleUtils.collectDepProject(project, variant).each { targetProject ->GradleUtils.getAndroidVariants(targetProject).each { targetVariant ->if (targetVariant.name.capitalize().equalsIgnoreCase(variant.name.capitalize())) {targetClasspath += targetVariant.javaCompile.classpath}}
}classpath = variant.javaCompile.classpath + targetClasspath + buildClasses

FindBugs增量扫描误报优化

对于增量文件扫描，参与的少数文件扫描在某些模式规则上可能会出现误判，但是全量扫描不会有问题，因为参与分析的目标文件是全集。举一个例子：

class A {public static String buildTime = "";....
}

静态变量buildTime会被认为应该加上Final，但是其实其他类会对这个变量赋值。如果单独扫描类A文件，就会报缺陷BUG_TYPE_MS_SHOULD_BE_FINAL。我们通过Findbugs-IDEA插件来扫描验证，也同样会有一样的问题。要解决此类问题，需要找到谁依赖了类A，并且一同参与扫描，同时也需要找出类A依赖了哪些文件，简单来说：需要找出与类A有直接关联的类。为了解决这个问题，我们通过ASM来找出相关的依赖，具体如下：

void findAllScanClasses(ConfigurableFileTree allClass) {allScanFiles = [] as HashSetString buildClassDir = "${project.buildDir}/$FINDBUGS_ANALYSIS_DIR/$FINDBUGS_ANALYSIS_DIR_ORIGIN"Set<File> moduleClassFiles = allClass.filesfor (File file : moduleClassFiles) {String[] splitPath = file.absolutePath.split("$FINDBUGS_ANALYSIS_DIR/$FINDBUGS_ANALYSIS_DIR_ORIGIN/")if (splitPath.length > 1) {String className = getFileNameNoFlag(splitPath[1],'.')String innerClassPrefix = ""if (className.contains('$')) {innerClassPrefix = className.split('\\$')[0]}if (diffClassNamePath.contains(className) || diffClassNamePath.contains(innerClassPrefix)) {allScanFiles.add(file)} else {Iterable<String> classToResolve = new ArrayList<String>()classToResolve.add(file.absolutePath)Set<File> dependencyClasses = Dependencies.findClassDependencies(project, new ClassAcceptor(), buildClassDir, classToResolve)for (File dependencyClass : dependencyClasses) {if (diffClassNamePath.contains(getPackagePathName(dependencyClass))) {allScanFiles.add(file)break}}}}}
}

通过以上方式，我们可以解决一些增量扫描时出现的误报情况，相比IDEA工具，我们更进一步降低了扫描部分文件的误报率。

CheckStyle增量扫描

相比而言，CheckStyle的增量扫描就比较简单了。CheckStyle对源码扫描，根据官方文档各个属性的描述，我们发现只要指定Source属性的值就可以指定扫描的目标文件。

void configureIncrementScanSource() {boolean isCheckPR = falseDiffFileFinder diffFileFinderif (project.hasProperty(CodeDetectorExtension.CHECK_PR)) {isCheckPR = project.getProperties().get(CodeDetectorExtension.CHECK_PR)}if (isCheckPR) {diffFileFinder = new DiffFileFinderHelper.PRDiffFileFinder()} else {diffFileFinder = new DiffFileFinderHelper.LocalDiffFileFinder()}source diffFileFinder.findDiffFiles(project)if (getSource().isEmpty()) {println '没有找到差异java文件，跳过checkStyle检测'}
}

优化结果数据

经过全量扫描和增量扫描的优化，我们整个扫描效率得到了很大提升，一次PR构建扫描效率整体提升50%+。优化数据如下：

落地与沉淀

扫描工具通用性

解决了扫描效率问题，我们想怎么让更多的工程能低成本的使用这个扫描插件。对于一个已经存在的工程，如果没有使用过静态代码扫描，我们希望在接入扫描插件后续新增的代码能够保证其经过增量扫描没有问题。而老的存量代码，由于代码量过大增量扫描并没有效率上的优势，我们希望可以使用全量扫描逐步解决存量代码存在的问题。同时，为了配置工具的灵活，也提供配置来让接入方自己决定选择接入哪些工具。这样可以让扫描工具同时覆盖到新老项目，保证其通用。所以，要同时支持配置使用增量或者全量扫描任务，并且提供灵活的选择接入哪些扫描工具。

扫描完整性保证

前面提到过，在FindBugs增量扫描可能会出现因为参与分析的目标文件集不全导致的某类匹配规则误报，所以在保证扫描效率的同时，也要保证扫描的完整性和准确性。我们的策略是以增量扫描为主，全量扫描为辅，PR提交使用增量扫描提高效率，在CI配置Daily Build使用全量扫描保证扫描完整和不遗漏。

我们在自己的项目中实践配置如下：

apply plugin: 'code-detector'codeDetector {// 配置静态代码检测报告的存放位置reportRelativePath = rootProject.file('reports')/*** 远程仓库地址，用于配置提交pr时增量检测*/upstreamGitUrl = "ssh://git@xxxxxxxx.git"checkStyleConfig {/*** 开启或关闭 CheckStyle 检测* 开启：true* 关闭：false*/enable = true/*** 出错后是否要终止检查* 终止：false* 不终止：true。配置成不终止的话 CheckStyleTask 不会失败，也不会拷贝错误报告*/ignoreFailures = false/*** 是否在日志中展示违规信息* 显示：true* 不显示：false*/showViolations = true/*** 统一配置自定义的 checkstyle.xml 和 checkstyle.xsl 的 uri* 配置路径为：*      "${checkStyleUri}/checkstyle.xml"*      "${checkStyleUri}/checkstyle.xsl"** 默认为 null，使用 CodeDetector 中的默认配置*/checkStyleUri = rootProject.file('codequality/checkstyle')}findBugsConfig {/*** 开启或关闭 Findbugs 检测* 开启：true* 关闭：false*/enable = true/*** 可选项，设置分析工作的等级，默认值为 max* min, default, or max. max 分析更严谨，报告的 bug 更多. min 略微少些*/effort = "max"/*** 可选项，默认值为 high* low, medium, high. 如果是 low 的话，那么报告所有的 bug*/reportLevel = "high"/*** 统一配置自定义的 findbugs_include.xml 和 findbugs_exclude.xml 的 uri* 配置路径为：*      "${findBugsUri}/findbugs_include.xml"*      "${findBugsUri}/findbugs_exclude.xml"* 默认为 null，使用 CodeDetector 中的默认配置*/findBugsUri = rootProject.file('codequality/findbugs')}lintConfig {/*** 开启或关闭 lint 检测* 开启：true* 关闭：false*/enable = true/*** 统一配置自定义的 lint.xml 和 retrolambda_lint.xml 的 uri* 配置路径为：*      "${lintConfigUri}/lint.xml"*      "${lintConfigUri}/retrolambda_lint.xml"* 默认为 null，使用 CodeDetector 中的默认配置*/lintConfigUri = rootProject.file('codequality/lint')}
}

我们希望扫描插件可以灵活指定增量扫描还是全量扫描以应对不同的使用场景，比如已存在项目的接入、新项目的接入、打包时的检测等。

执行脚本示例：

./gradlew ":${appModuleName}:assemble${ultimateVariantName}" -PdetectorEnable=true -PcheckStyleIncrement=true -PlintIncrement=true -PfindBugsIncrement=true -PcheckPR=${checkPR} -PsourceCommitHash=${sourceCommitHash} -PtargetBranch=${targetBranch} --stacktrace

希望一次任务可以暴露所有扫描工具发现的问题，当某一个工具扫描到问题后不终止任务，如果是本地运行在发现问题后可以自动打开浏览器方便查看问题原因。

def finalizedTaskArray = [lintTask,checkStyleTask,findbugsTask]
checkCodeTask.finalizedBy finalizedTaskArray"open ${reportPath}".execute()

为了保证提交的PR不会引起打包问题影响包的交付，在PR时触发的任务实际为打包任务，我们将静态代码扫描任务挂接在打包任务中。由于我们的项目是多Flavor构建，在CI上我们将触发多个Job同时执行对应Flavor的增量扫描和打包任务。同时为了保证代码扫描的完整性，我们在真正的打包Job上执行全量扫描。

总结与展望

本文主要介绍了在静态代码扫描优化方面的一些思路与实践，并重点探讨了对Lint、Finbugs、CheckStyle增量扫描的一些尝试。通过对扫描插件的优化，我们在代码扫描的效率上得到了提升，同时在实践过程中我们也积累了自定义Lint检测规则的方案，未来我们将配合基础设施标准化建设，结合静态扫描插件制定一些标准化检测规则来更好的保证我们的代码规范以及质量。