没有人敢确保自己的代码不出bug，但是用Lint至少能够确保所有人都少犯初级过错，守住团队代码质量的底线。

大纲：

  • 为什么说 Lint 关于团队有重要价值
  • 想让Lint丝滑的融入工作流，不得不对Lint进行二开
  • EaseLint 项目介绍

为什么说 Lint 关于团队有重要价值

我发现许多时候大家简单把IDE的语法过错提示与 Lint 搞混，语法检测就如同写word文档时提示单词拼写过错，Lint则像是grammarly（辅佐写作软件），辅佐作者改善语句措词，使其更为高雅得体，更契合上下文。

Android 官方对 Lint功用的描绘十分精确：经过进行 lint 检查来改善代码 。这里要害词是改善，也便是当开发者写了一行语法正确而且运转正常的代码，但是它可能不是最优或最安全的写法，或最优的API组合，经过Lint 检测将发现这些坏代码，经过实时提示来辅佐开发者改善为更强健更安全的写法。

下面就举几个比方来表现这一特性。

  • 事例1：检测代码标准

在接入 ViewBinding 时，为了确保xml内的view Id 与 ViewBinding 坚持一致性的驼峰命名，需求避免运用 btn_xx 下划线命名，这样便利阅览代码与检索代码。一般像这样的标准会在团队内会集同步，怎么能确保在这个标准自同步后新提交的代码viewId 100% 是驼峰命名呢？留意这里说的是达到100%契合标准，要彻底根绝因人为导致的疏漏。

在实践中从两个点下手就能100%达成这一目的，第一是本地借助IDE实时检测xml文件，辅佐开发者快速改善代码，像下面这样

开源EaseLint，帮助团队轻松落地Lint

第二个是下文会说到的自动履行lint task 进行检测，并经过lint陈述输出问题代码清单

  • 事例2:屏蔽不安全的原生API

在运用 Integer.parseInt 等办法时有可能会触发 NumberFormatException 导致Crash。有两种办法来规避，一是运用统一封装的东西类，二是必须包一个try catch。下图是完结这个检测要求的Lint效果：

开源EaseLint，帮助团队轻松落地Lint

  • 事例3：检测导致Crash的危险代码

在App侧必定会用到序列化用于解析接口数据，完结序列化会带来溃散危险，假如一个完结了序列化接口的类

它的成员变量应用的类未完结序列化接口，就有可能引发溃散。

这种问题靠code review 来根绝难度是蛮大的，一般也希望线上code review 时更多重视业务逻辑而非初级的编码过错，这样能有效削减 code review耗时。

针对这类问题需求编写一个Lint规矩，检测完结了序列化接口的类其成员变量的类型是否完结了序列化接口，像下面这样：

开源EaseLint，帮助团队轻松落地Lint

上面三个比方分别从团队标准与危险代码办理阐述了Lint的作用，也表现了出来一点，Lint 天然生成是依赖团队来放大价值的，即将团队的沉淀的技术经历，经过Lint快速触达到每一个成员与每一个项目中，依此来不断拉高团队代码质量的底线，并长期确保不劣化。

上述的比方都是自定义 Lint 规矩，只需求稍加学习便能够完结。比方入门能够看 google simples 中的android-custom-lint-rules，再看看官方文档 Lint API Guide，根本就能够大胆进行自定义规矩开发了。还有一个十分重要的资料时看 com.android.tools.lint:lint-checks:2.xx 库里的几百个检测器，这些检测器是自定义 Lint时最好的示范。

根本功用便是这样，但想要完全发挥 Lint的效益还需求下不少功夫，为了让Lint丝滑的融入工作流，需求对 Lint做一些二开。

想让Lint丝滑的融入工作流，不得不对Lint进行二开

落地Lint会自定义Lint就行了吗？当然还不行，有几个中心问要解决:

要支撑自定义扫描方针

大型项目全量扫描十分耗时，前史代码运转良好，扫描出来去改动无太大必要反而徒增危险。另外也应该满足谁动的代码谁负责处理Issue。所以这自定义扫描方针是十分必要的功用（增量扫描并不精确），比方单次commit的文件，兼并代码时两个分支之间的diff文件，就算是全量扫描也需求设置一个 git 时刻线，屏蔽掉很多前史代码。

Android Studio 是支撑的设置扫描范围的，但难以自动化。关于怎么完结自定义扫描方针市道上有挺多计划的，下面是一些网络上被验证可行的计划：

  • 1.美团外卖Android Lint代码检查实践中提出的在扫描时获取到file，与运用git命令筛选好的文件列表进行比对，匹配上才扫描，否则忽略。
  • 2.Android Lint增量扫描实战纪要,二开 lint gradle 包下的LintGradleExecution，LintGradleClient ，LintRequest等文件，为设置扫描方针开一个接口出来供外部插件传参，EaseLint也是这个计划。
  • 3.相对早一点的还有流利说开源的okcheck

动态上线新规矩，动态下线反常规矩

这一步相对较为简略，已然都已经接收了LintGradleClient 等中心类，那么外部的Lint Task也需二开进行适配。在这个过程中很简单就能够接收 runLint等要害办法，精确找到 LintOptions 的干涉机遇，来完结动态配置解析与设置。

扫描机遇要融入工作流，要自动化，让开发丝滑无感

这一步有许多挑选，至于终究挑选哪一种要根据团队工作流来确认。下面罗列一些常用机遇：

  • 1.编码时IDE会自动加载自定义的Lint规矩，进行实时提示
  • 2.本地commit时利用git hook 的pre commit 履行脚本出发lint task，检索履行成果，不成功则commit会失利

实践发现这一步是比较耗时的，主要是lint task 会触发一次完好的编译（这能够进行干涉，但不高雅）

#!/bin/sh
echo "========pre commit start============="
pwd
pwd
chmod 777 ./gradlew
logs=./gradlew easeLint --stacktrace
echo "taskLog:$logs"
# 检索 日志中是否包括==lint_passed==
if [[ $logs == *"==lint_passed=="* ]];
then
  echo "success:pre commit check has passed"
  exit 0
else
echo "fail:pre commit check has not passed"
exit 1
fi
  • 3.只依赖本地环境还不行，开发人员的本地开发环境总会有差异，IDE bug 或者误操作封闭了 Lint 等等。我认为最好的机遇在提交PR(Pull request) 或MR(Merge Request) 时，运用git hook 告诉CI服务器履行Lint扫描，检测不经过不允许兼并，需求改善代码后重新提交并再次扫描，这样确保兼并到骨干的代码必定会被检测。

开源EaseLint，帮助团队轻松落地Lint

  • 4.大厂巨型团队还会在打包前做一次全量扫描作为兜底，这个视具体情况而定。咱们之前的分支办理是肯定不会出现绕过MP卡点的，这一步并非必须。

Lint陈述要同步到企业IM或邮箱，完结自动化告诉

将扫描陈述上传到文件服务器上（像阿里云的OSS，腾讯云的COS都是成本低且十分易接入的文件服务器），一同对扫描陈述xml文件进行开始解析，将陈述html文件与解析成果一并发至对应开发邮箱或企业IM，点开即看，完结闭环。

开源EaseLint，帮助团队轻松落地Lint

运用Lint数据量化代码优化成果

Lint支撑输出xml与html 两种 ，xml 格局能够用于解析并将数据存档。分析频率并不高，根据实践分析体量耗时来决议是否需求试用数据库。

将这些数据依照项目，时刻做一张表，再合作线上Crash率等一同呈现，是十分不错的数据分析办法。更细化的便是对线上Crash进行符号归类，选出Lint 能够根绝的部分来单独呈现，Lint扫描出的Error 与 crash率 必定是成负相关的。

EaseLint 项目介绍

前往仓库检查最新文档:github.com/Western-par…

滑到底部可点赞谈论

浏览橘子树其他文章：橘子树的飞书写作记载