Android静态代码扫描效率优化与实践，Android源码剖析之Framwork层消息传递

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

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

扫描工具对比

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

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

注：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 collectDepProject(Projectproject, BaseVariant variant, Set 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))