一、概述
在App的开发迭代过程中，线上问题时有发生。通过静态代码分析工具，是为了进一步减少问题发生，我们逐步完善了一些规范，包括制定代码规范，加强代码Review，完善测试流程等。但这些措施仍然存在各种不足，包括代码规范难以实施，沟通成本高，特别是开发人员变动频繁导致反复沟通等，因此其效果有限，相似问题仍然不时发生。另一方面，越来越多的总结、规范文档，对于组内新人也产生了不小的学习压力
1.1 三大主流分析工具优缺点对比：
PMD： 对Java语言支持比较友好，检查规则比较丰富，但是检查结果不太友好，阅读困难，结果未做分类，暂不支持Kotlin；
Findbugs： 配置检测标准，扫描结果分区分等级，有利于快速定位问题，但是未自定义过滤条件，检查结果很冗余，暂不支持Kotlin；
Lint： 官方推荐，且已集成AS，提供了丰富的内嵌规则，以及丰富的API进行自定义，支持kotlin。
基于上述情况，我们选定引入Lint作为项目静态代码检测工具，提升项目代码质量和健壮性
二、Lint使用
2.1 关于lint的一些命令，可以参考官网，这里简单介绍一些。
* lint path(项目目录) --进行项目的lint检查
* lint –check id path --利用指定的issue进行项目检查
* lint –list --列出所有的issue
* lint –show id --介绍指定的issue
* lint –help --查看帮助
* lint --stacktrace --展示堆栈信息
* -p modulename lint --执行指定模块Lint检查
* -w lint 只检查错误，忽略警告
* lintDebug 对某个特定的版本运行 lint 任务，首字母大写
对于大型项目，建议按模块分开执行lint检查，否则会发生内存溢出。
完整命令行：gradlew -w -p moduleName lintDebug
附部分gradle命令:
* gradlew -v --查看当前gradle版本号
* gradlew clean --清除工程目录下的build文件夹
* gradlew build --检查依赖并编译打包(debug、release环境)
* gradlew assembleDebug --编译打包debug环境
* gradlew assembleRelease --编译打包release环境
2.2 使用android studio自带的lint工具
点击Analyze的Inspect Code选项，即可开启lint检查，在Inspection窗口中可以看到lint检查的结果，lint查询的错误类型包括：
* Missing Translation and Unused Translation【缺少翻译或者没有】
* Layout Peformance problems (all the issues the old layoutopt tool used to find, and more)【布局展示问题】
* Unused resources【没有使用的资源】
* Inconsistent array sizes (when arrays are defined in multiple configurations)【不一致的数组大小】
* Accessibility and internationalization problems (hardcoded strings, missing contentDescription, etc)【可访问性和国际化问题，包括硬链接的字符串，缺少contentDescription，等等】
* Icon problems (like missing densities, duplicate icons, wrong sizes, etc)【图片问题，丢失密度，重复图片，错误尺寸等】
* Usability problems (like not specifying an input type on a text field)【使用规范，比如没有在一个文本上指定输入的类型】
* Manifest errors【Manifest.xml中的错误】
* and so on
android自带的lint规则的更改可以在Setting的Edit选项下选择Inspections（File > Settings > Project Settings），对已有的lint规则进行自定义选择。
参考官方文档
三、自定义规则
3.1 创建java-library
在项目中新建java library, 添加最新稳定版lint依赖26.x.x
dependencies {
compileOnly 'com.android.tools.lint:lint-api:26.6.1'
compileOnly 'com.android.tools.lint:lint-checks:26.6.1'
}
3.2 创建自定义的IssueRegistry, 在app中使用该Registry
继承IssueRegistry,添加自定义的detector
public class IssuesRegister extends IssueRegistry {
@NotNull
@Override
public List<Issue> getIssues() {
return new ArrayList<Issue>() {{
//添加自定义的Detector
add(SelfLogDetector.ISSUE);
add(NewThreadDetector.ISSUE);
add(MessageObtainDetector.ISSUE);
add(ViewIdCorrectnessDetector.ISSUE);
add(LayoutNameDetector.ACTIVITY_LAYOUT_NAME_ISSUE);
add(LayoutNameDetector.FRAGMENT_LAYOUT_NAME_ISSUE);
}};
}
}
在java moudle的build.gradle中声明自定义的IssueRegistry
jar {
manifest {
attributes("Lint-Registry-v2": "com.lintrules.IssuesRegister")
}
}
3.3 app中引入自定义的lint
Gradle Plugin3.0之前,用的是包装aar的方式引入自定义的lint, 参照 linkedIn方案
-
3.0后增加 lintChecks, 无需再使用包装aar的方式
New lintChecks dependency configuration allows you to build a JAR that defines custom lint rules, and package it into your AAR and APK projects. Your custom lint rules must belong to a separate project that outputs a single JAR and includes only compileOnly dependencies. Other app and library modules can then depend on your lint project using the lintChecks configuration:
我们可以直接在项目的build.gradle里添加
dependencies { lintChecks project(':lintrules') //这里添加java library }
3.4 实现自定义Detector
detector是lint的核心,主要分为下面几步
- 每个规则都先继承抽象类Detector，然后实现Detector.Scanner接口
- 定义ISSUE的内容，严重级别，提示信息，提示位置
- 实现getApplicableXX和visitXX方法，在getApplicableXX中定义检查的域,，visitXX中定义检查的规则
- 调用JavaContext.reportIssue()提示异常
3.5 实现Scanner接口
Scanner包括以下几种
- JavaScanner / JavaPsiScanner / UastScanner：扫描Java源文件
- SourceCodeScanner 扫描 Java 或符合JVM规范的源码文件（如 kotlin）
- ClassScanner 扫描编译后的 class 文件
- BinaryResourceScanner 扫描二进制资源文件（如.png）
- ResourceFloderScanner 扫描资源目录
- XmlScanner 扫描 xml 文件
- GradleScanner 扫描 Gradle 文件
- OtherFileScanner 扫描其他文件
每个Scanner都实现了很多getApplicableXX和visitXX方法,这些方法都是成对使用
3.6 定义ISSUE
ISSUE在每个Detector中定义，lint检查到相关项将ISSUE报告出来，示例：
public static final Issue ISSUE = Issue.create(
"InnerClassSerializable", //问题 Id
"内部类需要实现Serializable接口", //问题的简单描述
"内部类需要实现Serializable接口",//问题的详细描述
Category.SECURITY, //问题类型
5, // 0-10严重级别
Severity.ERROR, //问题严重程度
new Implementation(SerializableDetector.class,
Scope.JAVA_FILE_SCOPE); //Detector 和 Scope 的对应关系
3.7 实现getApplicableXX和visitXX方法方法
例如实现SourceCodeScanner接口,我们applicableSuperClasses()中指定需要检查的父类名列表,visitClass()当检测到你指定的父类名列表时,就会进入该方法, 根据参数JavaContext, Uclass可以很方便的获取Class的继承关系,名字等信息
@Nullable
@Override
public List<String> applicableSuperClasses() {
//指定检查"java.io.Serializable"
return Collections.singletonList(CLASS_SERIALIZABLE);
}
/**
* 扫描到applicableSuperClasses()指定的list时,回调该方法
*/
@Override
public void visitClass(JavaContext context, UClass declaration) {
//只从最外部开始向内部类递归检查
if (declaration instanceof UAnonymousClass) {
return;
}
sortClass(context, declaration);
}
再比如XmlScanner, 可以利用getApplicableElements()和visitElement()方法来进行xml中节点的扫描
@Override
public Collection<String> getApplicableElements() {
return Arrays.asList( //指定检查这几个控件的命名规范,可自行扩展
TEXT_VIEW,
IMAGE_VIEW,
BUTTON,
EDIT_TEXT,
CHECK_BOX
);
}
/**
* 扫描到getApplicableElements()指定的xml节点时,回调该方法
*/
@Override
public void visitElement(XmlContext context, Element element) {
//这个detector只扫描android:id属性,其他属性跳过
if (!element.hasAttributeNS(ANDROID_URI, ATTR_ID)) return;
Attr attr = element.getAttributeNodeNS(ANDROID_URI, ATTR_ID);
String value = attr.getValue();
if (value.startsWith(NEW_ID_PREFIX)) {
....
}
}
3.8 报告ISSUE
在需要报告ISSUE的地方调用context.report()
context.report(ISSUE, //定义好的ISSUE
uClass.getNameIdentifier(), //ISSUE对应的AST节点
context.getLocation(uClass.getNameIdentifier()), //ISSUE提示的位置
String.format("内部类 `%1$s` 需要实现Serializable接口", uClass.getName())); //ISSUE的描述
四、AST语法树
Lint从第一个版本就选择了lombok-ast作为自己的AST Parser，并且用了很久。但是Java语言本身在不断更新，Android也在不断迭代出新，lombok-ast慢慢跟不上发展，所以Lint在25.2.0版增加了IntelliJ的PSI（Program Structure Interface）作为新的AST Parser。但是PSI于IntelliJ、于Lint也只是个过渡性方案，事实上IntelliJ早已开始了新一代AST Parser，UAST（Unified AST）的开发，而Lint也将于即将发布的25.4.0版中将PSI更新为UAST。
更多的介绍请参考LintParser具体介绍, 简单的说从lambok->PSI->UAST,官方一直在优化lint的执行效率和扩展性,本文使用的是Lint26.2.0版本
五、检测成果
5.1 AS自带插件检测
5.1.1 NullPointerException，每个开发迭代周期处理
5.1.2 Unused resources，每个季度至少组织清理一次
5.2 Lint gradlew检测
5.2.1 按模块扫描所得清单
5.2.2 对应模块的报告详情
5.2.3 检测问题归类，以自定义规则为例
- ViewId命名不规范
- 内部类未序列化
- Log使用不规范
- 线程使用不规范
- MessageObtain规范
- 其他
5.3 借助第三方平台检查
5.3.1 通过持续集成平台，对84个NullPointerException问题进行修复，后续每个迭代例行检测。
5.3.2 Snoarqube平台代码重复率总体占比9.1%，其中50%及以上有42000多行，后续每个迭代推动整改。
六、总结
经过一段时间的实践发现，Lint静态代码检查在解决特定问题时的效果非常好，主要包括以下几个方面：
6.1 Crash预防
Crash率是App最重要的指标之一，避免Crash也一直是开发过程中比较头疼的一个问题，Lint可以很好的检查出一些潜在的Crash。例如：
原生的NewApi，用于检查代码中是否调用了Android高版本才提供的API。在低版本设备中调用高版本API会导致Crash。
自定义的SerializableCheck。实现了Serializable接口的类，如果其成员变量引用的对象没有实现Serializable接口，序列化时就会Crash。我们制定了一条代码规范，要求实现了Serializable接口的类，其成员变量（包括从父类继承的）所声明的类型都要实现Serializable接口。
6.2 Bug预防
有些Bug可以通过Lint检查来预防。例如：
SpUsage：要求所有SharedPrefrence读写操作使用基础工具类，工具类中会做各种异常处理；同时定义AppPreference常量类，所有SP的Key都要在这个类定义，避免在代码中分散定义的Key之间冲突。
TodoCheck：检查代码中是否还有TODO没完成。例如开发时可能会在代码中写一些假数据，但最终上线时要确保删除这些代码。这种检查项比较特殊，通常在开发完成后提测阶段才检查。
6.3 性能/安全问题
一些性能、安全相关问题可以使用Lint分析。例如：
ThreadConstruction：禁止直接使用new Thread()创建线程（线程池除外），而需要使用统一的工具类在公用线程池执行后台操作。
LogUsage：禁止直接使用android.util.Log，必须使用统一工具类。工具类中可以控制Release包不输出Log，提高性能，也避免发生安全问题。
6.4 代码规范
除了代码风格方面的约束，代码规范更多的是用于减少或防止发生Bug、Crash、性能、安全等问题。很多问题在技术上难以直接检查，我们通过封装统一的基础库、制定代码规范的方式间接解决，而Lint检查则用于减少组内沟通成本、新人学习成本，并确保代码规范的落实。
例如：前面提到的AppPreference、RxThreadUtil、LogUtils/KLog等。
ResourceNaming：资源文件命名规范，防止不同模块之间的资源文件名冲突。
