小伙伴们，美美又来推荐干货文章啦～本文为美团研发同学实战经验，主要介绍Android静态扫描工具Lint、CheckStyle、FindBugs在扫描效率优化上的一些探索和实践，希望大家喜欢鸭。
背景与问题
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个数正相关。对于现有工程的任务，我们可以看一下目前各个任务的耗时情况：（以实际开发中某一次扫描为例）
