使用Lint检查API兼容性
聊完API差异的那些坑，接下来咱们得说说怎么在代码阶段就把问题堵住。我自己的习惯是：把Lint检查当作代码的“体检医生”。提交代码之前先跑一遍Lint，很多不兼容的调用、废弃的API、权限问题，它都能提前揪出来。
说白了，Android Lint是SDK内置的静态分析工具。它不需要运行你的应用，就能扫描出潜在问题。你想想看，如果等到CI构建或者真机测试才发现API不兼容，那修改成本可就高了去了。
Lint到底在查什么？
它检查的不只是语义错误，还包括：
- 废弃API调用：比如你在targetSdkVersion=34的项目里用了
LocationManager.requestSingleUpdate()（Android 14开始废弃），Lint会直接报警告。 - API等级不匹配：调用了
Build.VERSION_CODES.TIRAMISU及以上才有的方法，但minSdkVersion设太低。 - 隐性兼容性问题：比如在非AndroidX项目里混用了AndroidX库，或者引用了内部隐藏API。
- 资源与权限遗漏：声明了权限却没有对应
，或者引用了不存在drawable。
我有个习惯：每次升级targetSdkVersion之后，第一件事就是跑一遍./gradlew lint，然后对着警告列表逐个修复。哪怕只是“建议性”警告，我也会认真看一眼 —— 有时候它偏偏就是后面崩溃的导火索。
Lint的工作流程
整个过程可以概括为：编译 → 分析 → 报告 → 修复 → 回归。下面这张图帮你理清这几个环节的先后关系和依赖。
记住这个循环：代码改动 → Lint扫描 → 修复 → 再扫描 → 合并。我团队里把这个流程直接写进了Git Hooks，谁要是没跑Lint就push，自动拦截。
如何配置Lint规则？
在项目根目录的build.gradle（或app/build.gradle）里，你可以用lintOptions块进行精细化控制。举个例子：
android {
lintOptions {
// 仅针对API兼容性相关的Issue
check 'NewApi', 'Deprecated', 'ObsoleteSdkInt'
// 设为error级别，编译时直接中断
error 'NewApi'
warning 'Deprecated'
// 忽略某些无害问题
disable 'MissingTranslation'
// 指定基线文件（忽略已有问题）
baseline file("lint-baseline.xml")
// 文本报告输出
textOutput file("lint-report.txt")
htmlOutput file("lint-report.html")
}
}
这里面我最常用的是check和baseline。尤其是在接手遗留项目时，一次性几百条警告根本改不完，用基线文件先记录现存问题，之后新代码产生的警告就一目了然了。
常用检测项清单
| Issue ID | 含义 | 严重程度 |
|---|---|---|
| NewApi | 调用了高于minSdk的API | Error |
| Deprecated | 使用了已废弃API | Warning |
| ObsoleteSdkInt | 使用了已过时的SDK版本常量 | Warning |
| MissingPermission | 未声明必要的权限 | Error |
| UnusedAttribute | 布局属性在当前API级别无效 | Warning |
我曾经踩过的坑：一次我把某个方法的@TargetApi写成了@RequiresApi，Lint居然没有报错，但运行时在低版本手机上直接crash。后来我才发现，@RequiresApi只会被编译期读取，而Lint默认只扫描字节码里的注解。所以，光靠Lint还不够，最好配合单元测试一起做API兼容性验证。
集成到CI流水线
把Lint放进CI的步骤很简单。我个人习惯这么写：
# 在Jenkins/GitLab CI的构建步骤里
./gradlew lintRelease
# 然后检查lint-results-release.html里的错误数量
# 如果错误数 > 0，则构建失败
不过要注意：默认的Lint报告会包含所有module的输出。如果你只想关注某个模块，可以用--module参数：
./gradlew :app:lintRelease --module app
还有一个技巧：设置Lint的基线文件。第一次跑完后用--baseline生成基线，后续CI只对比新增的Issue。这样既能留住历史债，又不让新问题溜走。
核心知识点速查
- 配置入口：
android.lintOptions块 - 关键命令：
./gradlew lint（默认所有变体） - 报告格式：HTML（可视化）、XML（集成工具）、Text（命令行）
- 常用Issue：NewApi、Deprecated、MissingPermission
- 最佳实践：结合baseline、设置error级别、CI中强制检查
最后说个小窍门：如果你发现Lint某些规则太严，可以在lint.xml里按文件夹或文件设置例外。比如对第三方库的代码可以统统忽略：
<lint>
<issue id="NewApi">
<ignore path="**/thirdparty/**" />
</issue>
</lint>这样既保持了API兼容性检查的严格性，又避免被外部代码干扰。