对于执行 Lint 操作的相关配置,是定义在 gradle 文件的 lintOptions 中,可定义的选项及其默认值包括(翻译自 LintOptions - Android Plugin 2.3.0 DSL Reference):
android {
lintOptions {
// 设置为 true,则当 Lint 发现错误时停止 Gradle 构建
abortOnError false
// 设置为 true,则当有错误时会显示文件的全路径或绝对路径 (默认情况下为true)
absolutePaths true
// 仅检查指定的问题(根据 id 指定)
check ‘NewApi’, ‘InlinedApi’
// 设置为 true 则检查所有的问题,包括默认不检查问题
checkAllWarnings true
// 设置为 true 后,release 构建都会以 Fatal 的设置来运行 Lint。
// 如果构建时发现了致命(Fatal)的问题,会中止构建(具体由 abortOnError 控制)
checkReleaseBuilds true
// 不检查指定的问题(根据问题 id 指定)
disable ‘TypographyFractions’,‘TypographyQuotes’
// 检查指定的问题(根据 id 指定)
enable ‘RtlHardcoded’,‘RtlCompat’, ‘RtlEnabled’
// 在报告中是否返回对应的 Lint 说明
explainIssues true
// 写入报告的路径,默认为构建目录下的 lint-results.html
htmlOutput file(“lint-report.html”)
// 设置为 true 则会生成一个 HTML 格式的报告
htmlReport true
// 设置为 true 则只报告错误
ignoreWarnings true
// 重新指定 Lint 规则配置文件
lintConfig file(“default-lint.xml”)
// 设置为 true 则错误报告中不包括源代码的行号
noLines true
// 设置为 true 时 Lint 将不报告分析的进度
quiet true
// 覆盖 Lint 规则的严重程度,例如:
severityOverrides [“MissingTranslation”: LintOptions.SEVERITY_WARNING]
// 设置为 true 则显示一个问题所在的所有地方,而不会截短列表
showAll true
// 配置写入输出结果的位置,格式可以是文件或 stdout
textOutput ‘stdout’
// 设置为 true,则生成纯文本报告(默认为 false)
textReport false
// 设置为 true,则会把所有警告视为错误处理
warningsAsErrors true
// 写入检查报告的文件(不指定默认为 lint-results.xml)
xmlOutput file(“lint-report.xml”)
// 设置为 true 则会生成一个 XML 报告
xmlReport false
// 将指定问题(根据 id 指定)的严重级别(severity)设置为 Fatal
fatal ‘NewApi’, ‘InlineApi’
// 将指定问题(根据 id 指定)的严重级别(severity)设置为 Error
error ‘Wakelock’, ‘TextViewEdits’
// 将指定问题(根据 id 指定)的严重级别(severity)设置为 Warning
warning ‘ResourceAsColor’
// 将指定问题(根据 id 指定)的严重级别(severity)设置为 ignore
ignore ‘TypographyQuotes’
}
}
lint.xml 这个文件则是配置 Lint 需要禁用哪些规则(issue),以及自定义规则的严重程度(severity),lint.xml 文件是通过 issue 标签指定对一个规则的控制,在项目根目录中建立一个 lint.xml 文件后 Android Lint 会自动识别该文件,在执行检查时按照 lint.xml 的内容进行检查。如上面提到的那样,开发者也可以通过 lintOptions 中的 lintConfig 选项来指定配置文件。一个 lint.xml 示例如下:
<?xml version="1.0" encoding="UTF-8"?>issue 标签中使用 id 指定一个规则,severity="ignore"
则表明禁用这个规则。需要注意的是,某些规则可以通过 ignore 标签指定仅对某些属性禁用,例如上面的 Deprecated
,表示检查是否有使用不推荐的属性和方法,而在 issue 标签中包裹一个 ignore 标签,在 ignore 标签的 regexp
属性中使用正则表达式指定了 singleLine
,则表明对 singleLine
这个属性屏蔽检查。
另外开发者也可以使用 @SuppressLint(issue id)
标注针对某些代码忽略某些 Lint 检查,这个标注既可以加到成员变量之前,也可以加到方法声明和类声明之前,分别针对不同范围进行屏蔽。
常见问题
我们在使用 Android Lint 对项目进行检查后,整理了一些问题及解决方法,下面列举较为常见的场景:
ScrollView size validation
这也是上文提到过的一个情况,在 ScrollView 的第一层子元素中设置了高度为 match_parent
,这是错误的写法,实际上在 measure 时这里必定会被当作 wrap_content
去处理,因此按照 Lint 的建议,直接改为 wrap_content
即可。
Handler reference leaks
Handler 引用的内存泄露问题,例如下面的例子:
protected static final int STOP = 0x10000;
protected static final int NEXT = 0x10001;
@BindView(R.id.rectProgressBar) QMUIProgressBar mRectProgressBar;
@BindView(R.id.circleProgressBar) QMUIProgressBar mCircleProgressBar;
int count;
private Handler myHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
switch (msg.what) {
case STOP:
break;
case NEXT:
if (!Thread.currentThread().isInterrupted()) {
mRectProgressBar.setProgress(count);
mCircleProgressBar.setProgress(count);
}
}
}
};
首先非静态的内部类或者匿名类会隐式的持有其外部类的引用,内部类使用了外部类的方法/成员变量也会导致其持有外部类引用,因此上面这种情况会导致 handler 持有了外部类,外部类同时持有 handler,handler 是异步的,当 handler 的消息发送出去后,外部类因 hanlder 的持有而无法销毁,最终导致内存泄露。
解决办法则是把该内部类改为 static,内部类中使用的外部类方法/成员变量改为弱引用,具体如下:
@BindView(R.id.rectProgressBar) QMUIProgressBar mRectProgressBar;
@BindView(R.id.circleProgressBar) QMUIProgressBar mCircleProgressBar;
int count;
private ProgressHandler myHandler = new ProgressHandler();
@Override
protected View onCreateView() {
myHandler.setProgressBar(mRectProgressBar, mCircleProgressBar);
}
private static class ProgressHandler extends Handler {
private WeakReference weakRectProgressBar;
private WeakReference weakCircleProgressBar;
public void setProgressBar(QMUIProgressBar rectProgressBar, QMUIProgressBar circleProgressBar) {
weakRectProgressBar = new WeakReference<>(rectProgressBar);
weakCircleProgressBar = new WeakReference<>(circleProgressBar);
}
《设计思想解读开源框架》
第一章、 热修复设计
-
第一节、 AOT/JIT & dexopt 与 dex2oat
-
第二节、 热修复设计之 CLASS_ISPREVERIFIED 问题
-
第三节、热修复设计之热修复原理
-
第四节、Tinker 的集成与使用(自动补丁包生成)
第二章、 插件化框架设计
-
第一节、 Class 文件与 Dex 文件的结构解读
-
第二节、 Android 资源加载机制详解
-
第三节、 四大组件调用原理
-
第四节、 so 文件加载机制
-
第五节、 Android 系统服务实现原理
第三章、 组件化框架设计
-
第一节、阿里巴巴开源路由框——ARouter 原理分析
-
第二节、APT 编译时期自动生成代码&动态类加载
-
第三节、 Java SPI 机制
-
第四节、 AOP&IOC
-
第五节、 手写组件化架构
第四章、图片加载框架
-
第一节、图片加载框架选型
-
第二节、Glide 原理分析
-
第三节、手写图片加载框架实战
第五章、网络访问框架设计
-
第一节、网络通信必备基础
-
第二节、OkHttp 源码解读
-
第三节、Retrofit 源码解析
第六章、 RXJava 响应式编程框架设计
-
第一节、链式调用
-
第二节、 扩展的观察者模式
-
第三节、事件变换设计
-
第四节、Scheduler 线程控制
第七章、 IOC 架构设计
-
第一节、 依赖注入与控制反转
-
第二节、ButterKnife 原理上篇、中篇、下篇
-
第三节、Dagger 架构设计核心解密
第八章、 Android 架构组件 Jetpack
-
第一节、 LiveData 原理
-
第二节、 Navigation 如何解决 tabLayout 问题
-
第三节、 ViewModel 如何感知 View 生命周期及内核原理
-
第四节、 Room 架构方式方法
-
第五节、 dataBinding 为什么能够支持 MVVM
-
第六节、 WorkManager 内核揭秘
-
第七节、 Lifecycles 生命周期
本文包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等,资源持续更新中…
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
714283528946)]
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!