前言
Android自定义Lint检查有效提升代码质量、避免人工的低级失误、规范代码,属于程序自动化的内容,这部分内容涉及的资料较少,但是实际意义重大,尤其是对有规模的团队而言。
提示:文中链接需要点击文章末尾处阅读原文才能点击。
作者 介绍
QJoy
目前供职于优酷来疯团队,除了android相关的日常业务工作,平时个人喜爱研究自动部署测试,音视频相关,以及基于OpenGL的特效研究。热衷开源、分享交流知识。
一、 Coding时遇到的问题
1
案例
案例1:com.alibaba.fastjson.JSON
工程中经常会使用 FastJson 来解析 Json 数据,由于会使用反射机制构造 JavaBean 对象,那么 release 版本混淆的情况下,如果没有对相应的 JavaBean 对象做keep处理的话,JavaBean 无法成功构建,从而出现对象为 NULL 的情况。往往会在临上线的两三天在release包中突然发现莫名的崩溃、功能失效之类的问题,都是由于这个原因。造成每每发版本就要加班的窘境。
案例2:activity基类
由于有一些统计,例如友盟统计活跃的需求,需要在 Activity 中的 OnResume/OnPause 实现某些方法,当然还有很多我们项目自身的原因,需要所有工程中的 Activity都要继承自某一个我们实现的 BaseActivity,如果是个小工程小团队,我们可以全局搜索一下,定期检查一下,都可以。如果是个十余人甚至更大的团队,每个版本的需求中都有可能产生新的 Activity,或者在大的工程重构后,能否保证人不会犯错,不会忘记将我们的 Activity 继承自我们的 BaseActivity ?
案例3:团队的编码规范
当一个团队技术负责人认认真真的制订了少量有效的编码规范后,苦口婆心的像是传销似的要求团队成员遵循,难道需要我们对工程中的每行代码都要 review 吗?培养习惯真的不容易。
好了,管中窥豹而已,项目中的“非典型技术的技术问题”还有很多是不是?除了自动化我们就别想指望人来解决。
2
解决
类型1: 如果你根本没听说过 Lint,请赶紧 Google 一下 Android Lint。因为你是一个或者很可能会成为一个技术 Leader,如果到时候要靠人工审核这些,你的麻烦就大了去了;(初级-看一下整个第二大部分)
类型2: 如果你听说过Lint没有使用过,打开你的工程cd到主工程,再 ../gradlew Lint 一下。或者在 AndroidStudio Menu 中点击Analyse -> Inspect Code。因为知识不只停留在:“啊,我听说过”;(初级-看一下整个第二大部分)
类型3: 如果经常使用 Google 提供的 Lint,然而没有自定义过 Lint,这篇文章最适合你。因为关于自定义 Custom-Lint 资料不多,我也把好的资料地址都放进来了;
类型4: 如果你是自定义 Lint 高手,联系我 Email,交换一下学习心得,这个最难得。
二、
Lint检查基础
1
什么是 Lint 检查
版权说明:此部分概念性内容大部分摘抄自网络,并非原创,地址放在文章最后一部分参考资料中。
2
为什么要使用自定义Lint检查
Google 提供的默认 Lint 检查很全面但是我们终归会有很多项目特性、自定义规则无法满足,如开头我提到的几个案例,这时候我们需要自定义 Lint。另外更深层的问题是要自动化检查取代人工检查的成本,提高生产效率,降低人工低级失误带来的负面影响,这个理论是自从工业革命开始就早已被确认的毋庸置疑了,没什么可争论的,不管自动化过程花费多长时间、多大精力,我们都要坚持。Google 在 Custom-Lint 上提供了强大的 API 支持我们,而且更新速度很快,只可惜相关文档还是比较少的。
3
自定义 Lint 入门 & Custom-Lint 核心API
说明:此部分可参见教程:自定义 Lint 规则简介,这里仅罗列大体思路和使用时的备注。
A. Gradle配置包
compile 'com.android.tools.lint:lint-api:25.2.0'
compile 'com.android.tools.lint:lint-checks:25.2.0'
至于使用的版本号,你可以查看一下最新的,请务必如此,我之前在写“FastJsonDetector”时,使用的是24.3.1版本,想查看某个类是否实现了某个接口,调查了很久而不得方法,结果发现新版本25.1.0里面新增了“getInterfaces”这个方法。所以希望大家尽量使用新版本API。
B. com.android.tools.lint.client.api.IssueRegistry
实现一个继承自此类的子类,他起到的作用是注册你有哪些检查要开放出去在 Lint 过程中被执行。
另外一定注意这个地方,要在 Gradle 配置上他才可以。
jar {
manifest {
attributes('Lint-Registry': 'com.qjoy.LFIssueRegistry')
}
}
C. Detector 实例+ XXXScanner 接口
继承 Detector 并选择 Detector 中合适的 XXXScanner 接口来实现。在这里根据自身业务需求,实现各种自定义探测器(Detector ),并定义各种 issue,根据自身需求的不同这样的类可以有一个或多个。
其中,com.android.tools.lint.detector.api.Detector 提供了7种 XXXScanner 接口。
另外,利用 Context(此处的 Context 是 Lint 检查的类,不是 Android 的那个)的 report 方法报警,就会在错误日志中产生一条记录啦。
怎么样,是不是足够强大,检查所有你能想到的。
每种 XXXScanner 接口功能说明:
三、 AndroidLintWatchDog 中的自定义 Lint 检查
说明:最好看一下源码: GitHub follow&star。
我们选择两个我们实现的Detector简单分析一下,其余的请查看源代码吧:
1
BaseActivityDetector
目标:类是否继承自 LFBaseActivity 或者 LFBaseAppCompatActivity。
public class BaseActivityDetector extends Detector implements Detector.JavaScanner
{
...省略非核心代码...
public AstVisitor createJavaVisitor(JavaContext context) {
return new ForwardingAstVisitor() {
@Override
public boolean visitClassDeclaration(ClassDeclaration node) {
...核心代码...
在这里分析node,检查通过或者报警
}
}
}
由于是扫描 Java 代码内容,我们实现 JavaScanner,利用createJavaVisitor 接口的 visitClassDeclaration 扫描内容。
这里我们使用一个递归方法recursiveSupperClass
查看父类,追溯直到checkActivityRules
发现继承了 LFBaseActivity/LFBaseAppCompatActivity,或者直到发现直接继承了 Activity/AppCompatActivity,或者直接继承了 Object (说明他根本不是 Activity )。
2
ImageFileSizeDetector
目标:检查图片文件尺寸是否超过某个限定的大小。
public class ImageFileSizeDetector extends Detector implements Detector.BinaryResourceScanner {
...省略非核心代码...
@Override
public boolean appliesTo(ResourceFolderType var1) {
return var1.getName().equalsIgnoreCase(String.valueOf(ResourceFolderType.MIPMAP)) || var1.getName().equalsIgnoreCase(String.valueOf(ResourceFolderType.DRAWABLE));
}
@Override
public void checkBinaryResource(ResourceContext context) { String filename = context.file.getName(); ...核心代码...
在这里分析node,检查通过或者报警
}
}
由于是扫描二进制资源,我们实现 BinaryResourceScanner,利用 BinaryResourceScanner 接口的 checkBinaryResource 扫描内容。 通过 ResourceContext 可以获取文件信息,用来做我们判断的条件。
最后,让我们看看执行效果吧:
四
参考资料与鸣谢
五、
工程源码
工程源码托管在 GitHub follow&star。
小贴士
本文由原作者薛晴独家授权Open软件开发小组发布,著作权归原作者所有。如需转载请联系原作者申请授权。