概述

Lint是Google提供的Android靜態代碼檢查工具，可以掃描并發現代碼中潛在的問題，提醒開發人員及早修正，提高代碼質量。除了Android原生提供的幾百個Lint規則，還可以開發自定義Lint規則以滿足實際需要。

為什么要使用Lint

在美團外賣Android App的迭代過程中，線上問題頻繁發生。開發時很容易寫出一些問題代碼，例如Serializable的使用：實現了Serializable接口的類，如果其成員變量引用的對象沒有實現Serializable接口，序列化時就會Crash。我們對一些常見問題的原因和解決方法做分析總結，并在開發人員組內或跟測試人員一起分享交流，幫助相關人員主動避免這些問題。

為了進一步減少問題發生，我們逐步完善了一些規范，包括制定代碼規范，加強代碼Review，完善測試流程等。但這些措施仍然存在各種不足，包括代碼規范難以實施，溝通成本高，特別是開發人員變動頻繁導致反復溝通等，因此其效果有限，相似問題仍然不時發生。另一方面，越來越多的總結、規范文檔，對于組內新人也產生了不小的學習壓力。

有沒有辦法從技術角度減少或減輕上述問題呢？

我們調研發現，靜態代碼檢查是一個很好的思路。靜態代碼檢查框架有很多種，例如FindBugs、PMD、Coverity，主要用于檢查Java源文件或class文件；再例如Checkstyle，主要關注代碼風格；但我們最終選擇從Lint框架入手，因為它有諸多優勢：

功能強大，Lint支持Java源文件、class文件、資源文件、Gradle等文件的檢查。

擴展性強，支持開發自定義Lint規則。

配套工具完善，Android Studio、Android Gradle插件原生支持Lint工具。

Lint專為Android設計，原生提供了幾百個實用的Android相關檢查規則。

有Google官方的支持，會和Android開發工具一起升級完善。

在對Lint進行了充分的技術調研后，我們根據實際遇到的問題，又做了一些更深入的思考，包括應該用Lint解決哪些問題，怎么樣更好的推廣實施等，逐步形成了一套較為全面有效的方案。

Lint API簡介

為了方便后文的理解，我們先簡單看一下Lint提供的主要API。

主要API

Lint規則通過調用Lint API實現，其中最主要的幾個API如下：

Issue：表示一個Lint規則。

Detector：用于檢測并報告代碼中的Issue，每個Issue都要指定Detector。

Scope：聲明Detector要掃描的代碼范圍，例如JAVA_FILE_SCOPE、CLASS_FILE_SCOPE、RESOURCE_FILE_SCOPE、GRADLE_SCOPE等，一個Issue可包含一到多個Scope。

Scanner：用于掃描并發現代碼中的Issue，每個Detector可以實現一到多個Scanner。

IssueRegistry：Lint規則加載的入口，提供要檢查的Issue列表。

舉例來說，原生的ShowToast就是一個Issue，該規則檢查調用Toast.makeText()方法后是否漏掉了Toast.show()的調用。其Detector為ToastDetector，要檢查的Scope為JAVA_FILE_SCOPE，ToastDetector實現了JavaPsiScanner，示意代碼如下：

public class ToastDetector extends Detector implements JavaPsiScanner {public static final Issue ISSUE = Issue.create("ShowToast","Toast created but not shown","...",Category.CORRECTNESS,6,Severity.WARNING,new Implementation(ToastDetector.class,Scope.JAVA_FILE_SCOPE));// ... }

IssueRegistry的示意代碼如下：

public class MyIssueRegistry extends IssueRegistry {@Overridepublic List<Issue> getIssues() {return Arrays.asList(ToastDetector.ISSUE,LogDetector.ISSUE,// ...);} }

Scanner

Lint開發過程中最主要的工作就是實現Scanner。Lint中包括多種類型的Scanner如下，其中最常用的是掃描Java源文件和XML文件的Scanner。

• JavaScanner / JavaPsiScanner / UastScanner：掃描Java源文件
• XmlScanner：掃描XML文件
• ClassScanner：掃描class文件
• BinaryResourceScanner：掃描二進制資源文件
• ResourceFolderScanner：掃描資源文件夾
• GradleScanner：掃描Gradle腳本
• OtherFileScanner：掃描其他類型文件

值得注意的是，掃描Java源文件的Scanner先后經歷了三個版本。

最開始使用的是JavaScanner，Lint通過Lombok庫將Java源碼解析成AST(抽象語法樹)，然后由JavaScanner掃描。

在Android Studio 2.2和lint-api 25.2.0版本中，Lint工具將Lombok AST替換為PSI，同時棄用JavaScanner，推薦使用JavaPsiScanner。PSI是JetBrains在IDEA中解析Java源碼生成語法樹后提供的API。相比之前的Lombok AST，PSI可以支持Java 1.8、類型解析等。使用JavaPsiScanner實現的自定義Lint規則，可以被加載到Android Studio 2.2+版本中，在編寫Android代碼時實時執行。

在Android Studio 3.0和lint-api 25.4.0版本中，Lint工具將PSI替換為UAST，同時推薦使用新的UastScanner。 UAST是JetBrains在IDEA新版本中用于替換PSI的API。UAST更加語言無關，除了支持Java，還可以支持Kotlin。

本文目前仍然基于PsiJavaScanner做介紹。根據UastScanner源碼中的注釋，可以很容易的從PsiJavaScanner遷移到UastScanner。

Lint規則

我們需要用Lint檢查代碼中的哪些問題呢？

開發過程中，我們比較關注App的Crash、Bug率等指標。通過長期的整理總結發現，有不少發生頻率很高的代碼問題，其原理和解決方案都很明確，但是在寫代碼時卻很容易遺漏且難以發現；而Lint恰好很容易檢查出這些問題。

Crash預防

Crash率是App最重要的指標之一，避免Crash也一直是開發過程中比較頭疼的一個問題，Lint可以很好的檢查出一些潛在的Crash。例如：

• 原生的NewApi，用于檢查代碼中是否調用了Android高版本才提供的API。在低版本設備中調用高版本API會導致Crash。
• 自定義的SerializableCheck。實現了Serializable接口的類，如果其成員變量引用的對象沒有實現Serializable接口，序列化時就會Crash。我們制定了一條代碼規范，要求實現了Serializable接口的類，其成員變量（包括從父類繼承的）所聲明的類型都要實現Serializable接口。
• 自定義的ParseColorCheck。調用Color.parseColor()方法解析后臺下發的顏色時，顏色字符串格式不正確會導致IllegalArgumentException，我們要求調用這個方法時必須處理該異常。

Bug預防

有些Bug可以通過Lint檢查來預防。例如：

• SpUsage：要求所有SharedPrefrence讀寫操作使用基礎工具類，工具類中會做各種異常處理；同時定義SPConstants常量類，所有SP的Key都要在這個類定義，避免在代碼中分散定義的Key之間沖突。
• ImageViewUsage：檢查ImageView有沒有設置ScaleType，加載時有沒有設置Placeholder。
• TodoCheck：檢查代碼中是否還有TODO沒完成。例如開發時可能會在代碼中寫一些假數據，但最終上線時要確保刪除這些代碼。這種檢查項比較特殊，通常在開發完成后提測階段才檢查。

性能/安全問題

一些性能、安全相關問題可以使用Lint分析。例如：

• ThreadConstruction：禁止直接使用new Thread()創建線程（線程池除外），而需要使用統一的工具類在公用線程池執行后臺操作。
• LogUsage：禁止直接使用android.util.Log，必須使用統一工具類。工具類中可以控制Release包不輸出Log，提高性能，也避免發生安全問題。

代碼規范

除了代碼風格方面的約束，代碼規范更多的是用于減少或防止發生Bug、Crash、性能、安全等問題。很多問題在技術上難以直接檢查，我們通過封裝統一的基礎庫、制定代碼規范的方式間接解決，而Lint檢查則用于減少組內溝通成本、新人學習成本，并確保代碼規范的落實。例如：

• 前面提到的SpUsage、ThreadConstruction、LogUsage等。
• ResourceNaming：資源文件命名規范，防止不同模塊之間的資源文件名沖突。

代碼檢查的實施

當檢查出代碼問題時，如何提醒開發者及時修正呢？

早期我們將靜態代碼檢查配置在Jenkins上，打包發布AAR/APK時，檢查代碼中的問題并生成報告。后來發現雖然靜態代碼檢查能找出來不少問題，但是很少有人主動去看報告，特別是報告中還有過多無關緊要的、優先級很低的問題（例如過于嚴格的代碼風格約束）。

因此，一方面要確定檢查哪些問題，另一方面，何時、通過什么樣的技術手段來執行代碼檢查也很重要。我們結合技術實現，對此做了更多思考，確定了靜態代碼檢查實施過程中的主要目標：

重點關注高優先級問題，屏蔽低優先級問題。正如前面所說，如果代碼檢查報告中夾雜了大量無關緊要的問題，反而影響了關鍵問題的發現。

高優問題的解決，要有一定的強制性。當檢查發現高優先級的代碼問題時，給開發者明確直接的報錯，并通過技術手段約束，強制要求開發者修復。

某些問題盡可能做到在第一時間發現，從而減少風險或損失。有些問題發現的越早越好，例如業務功能開發中使用了Android高版本API，通過Lint原生的NewApi可以檢查出來。如果在開發期間發現，當時就可以考慮其他技術方案，實現困難時可以及時和產品、設計人員溝通；而如果到提代碼、提測，甚至發版、上線時才發現，可能為時已晚。

優先級定義

每個Lint規則都可以配置Sevirity（優先級），包括Fatal、Error、Warning、Information等，我們主要使用Error和Warning，如下。

• Error級別：明確需要解決的問題，包括Crash、明確的Bug、嚴重性能問題、不符合代碼規范等，必須修復。
• Warning級別：包括代碼編寫建議、可能存在的Bug、一些性能優化等，適當放松要求。

執行時機

Lint檢查可以在多個階段執行，包括在本地手動檢查、編碼實時檢查、編譯時檢查、commit檢查，以及在CI系統中提Pull Request時檢查、打包發版時檢查等，下面分別介紹。

手動執行

在Android Studio中，自定義Lint可以通過Inspections功能(Analyze - Inspect Code)手動運行。

在Gradle命令行環境下，可直接用./gradlew lint執行Lint檢查。

手動執行簡單易用，但缺乏強制性，容易被開發者遺漏。

編碼階段實時檢查

編碼時檢查即在Android Studio中寫代碼時在代碼窗口實時報錯。其好處很明顯，開發者可以第一時間發現代碼問題。但受限于Android Studio對自定義Lint的支持不完善，開發人員IDE的配置不同，需要開發者主動關注報錯并修復，這種方式不能完全保證效果。

IDEA提供了Inspections功能和相應的API來實現代碼檢查，Android原生Lint就是通過Inspections集成到了Android Studio中。對于自定義Lint規則，官方似乎沒有給出明確說明，但實際研究發現，在Android Studio 2.2+版本和基于JavaPsiScanner開發的條件下（或Android Studio 3.0+和JavaPsiScanner/UastScanner），IDE會嘗試加載并實時執行自定義Lint規則。

技術細節：

在Android Studio 2.x版本中，菜單Preferences - Editor - Inspections - Android - Lint - Correctness - Error from Custom Lint Check（avaliable for Analyze|Inspect Code）中指出，自定義Lint只支持命令行或手動運行，不支持實時檢查。

Error from Custom Rule When custom (third-party) lint rules are integrated in the IDE, they are not available as native IDE inspections, so the explanation text (which must be statically registered by a plugin) is not available. As a workaround, run the lint target in Gradle instead; the HTML report will include full explanations.

在Android Studio 3.x版本中，打開Android工程源碼后，IDE會加載工程中的自定義Lint規則，在設置菜單的Inspections列表里可以查看，和原生Lint效果相同（Android Studio會在打開源文件時觸發對該文件的代碼檢查）。

分析自定義Lint的IssueRegistry.getIssues()方法調用堆棧，可以看到Android Studio環境下，是由org.jetbrains.android.inspections.lint.AndroidLintExternalAnnotator調用LintDriver加載執行自定義Lint規則。

參考代碼： https://github.com/JetBrains/android/tree/master/android/src/org/jetbrains/android/inspections/lint

在Android Studio中的實際效果如圖：

本地編譯時自動檢查

配置Gradle腳本可實現編譯Android工程時執行Lint檢查。好處是既可以盡早發現問題，又可以有強制性；缺點是對編譯速度有一定的影響。

編譯Android工程執行的是assemble任務，讓assemble依賴lint任務，即可在編譯時執行Lint檢查；同時配置LintOptions，發現Error級別問題時中斷編譯。

在Android Application工程（APK）中配置如下，Android Library工程（AAR）把applicationVariants換成libraryVariants即可。

android.applicationVariants.all { variant ->variant.outputs.each { output ->def lintTask = tasks["lint${variant.name.capitalize()}"]output.assemble.dependsOn lintTask} }

LintOptions的配置：

android.lintOptions {abortOnError true }

本地commit時檢查

利用git pre-commit hook，可以在本地commit代碼前執行Lint檢查，檢查不通過則無法提交代碼。這種方式的優勢在于不影響開發時的編譯速度，但發現問題相對滯后。

技術實現方面，可以編寫Gradle腳本，在每次同步工程時自動將hook腳本從工程拷貝到.git/hooks/文件夾下。

提代碼時CI檢查

作為代碼提交流程規范的一部分，發Pull Request提代碼時用CI系統檢查Lint問題是一個常見、可行、有效的思路。可配置CI檢查通過后代碼才能被合并。

CI系統常用Jenkins，如果使用Stash做代碼管理，可以在Stash上配置Pull Request Notifier for Stash插件，或在Jenkins上配置Stash Pull Request Builder插件，實現發Pull Request時觸發Jenkins執行Lint檢查的Job。

在本地編譯和CI系統中做代碼檢查，都可以通過執行Gradle的Lint任務實現。可以在CI環境下給Gradle傳遞一個StartParameter，Gradle腳本中如果讀取到這個參數，則配置LintOptions檢查所有Lint問題；否則在本地編譯環境下只檢查部分高優先級Lint問題，減少對本地編譯速度的影響。

Lint生成報告的效果如圖所示：

打包發布時檢查

即使每次提代碼時用CI系統執行Lint檢查，仍然不能保證所有人的代碼合并后一定沒有問題；另外對于一些特殊的Lint規則，例如前面提到的TodoCheck，還希望在更晚的時候檢查。

于是在CI系統打包發布APK/AAR用于測試或發版時，還需要對所有代碼再做一次Lint檢查。

最終確定的檢查時機

綜合考慮多種檢查方式的優缺點以及我們的目標，最終確定結合以下幾種方式做代碼檢查：

編碼階段IDE實時檢查，第一時間發現問題。

本地編譯時，及時檢查高優先級問題，檢查通過才能編譯。

提代碼時，CI檢查所有問題，檢查通過才能合代碼。

打包階段，完整檢查工程，確保萬無一失。

配置文件支持

為了方便代碼管理，我們給自定義Lint創建了一個獨立的工程，該工程打包生成一個AAR發布到Maven倉庫，而被檢查的Android工程依賴這個AAR（具體開發過程可以參考文章末尾鏈接）。

自定義Lint雖然在獨立工程中，但和被檢查的Android工程中的代碼規范、基礎組件等存在較多耦合。

例如我們使用正則表達式檢查Android工程的資源文件命名規范，每次業務邏輯變動要新增資源文件前綴時，都要修改Lint工程，發布新的AAR，再更新到Android工程中，非常繁瑣。另一方面，我們的Lint工程除了在外賣C端Android工程中使用，也希望能直接用在其他端的其他Android工程中，而不同工程之間存在差異。

于是我們嘗試使用配置文件來解決這一問題。以檢查Log使用的LogUsage為例，不同工程封裝了不同的Log工具類，報錯時提示信息也應該不一樣。定義配置文件名為custom-lint-config.json，放在被檢查Android工程的模塊目錄下。在Android工程A中的配置文件是：

{"log-usage-message": "請勿使用android.util.Log，建議使用LogUtils工具類" }

而Android工程B的配置文件是：

{"log-usage-message": "請勿使用android.util.Log，建議使用Logger工具類" }

從Lint的Context對象可獲取被檢查工程目錄從而讀取配置文件，關鍵代碼如下：

import com.android.tools.lint.detector.api.Context;public final class LintConfig {private LintConfig(Context context) {File projectDir = context.getProject().getDir();File configFile = new File(projectDir, "custom-lint-config.json");if (configFile.exists() && configFile.isFile()) {// 讀取配置文件...}} }

配置文件的讀取，可以在Detector的beforeCheckProject、beforeCheckLibraryProject回調方法中進行。LogUsage中檢查到錯誤時，根據配置文件定義的信息報錯。

public class LogUsageDetector extends Detector implements Detector.JavaPsiScanner {// ...private LintConfig mLintConfig;@Overridepublic void beforeCheckProject(@NonNull Context context) {// 讀取配置mLintConfig = new LintConfig(context);}@Overridepublic void beforeCheckLibraryProject(@NonNull Context context) {// 讀取配置mLintConfig = new LintConfig(context);}@Overridepublic List<String> getApplicableMethodNames() {return Arrays.asList("v", "d", "i", "w", "e", "wtf");}@Overridepublic void visitMethod(JavaContext context, JavaElementVisitor visitor, PsiMethodCallExpression call, PsiMethod method) {if (context.getEvaluator().isMemberInClass(method, "android.util.Log")) {// 從配置文件獲取MessageString msg = mLintConfig.getConfig("log-usage-message");context.report(ISSUE, call, context.getLocation(call.getMethodExpression()), msg);}} }

模板Lint規則

Lint規則開發過程中，我們發現了一系列相似的需求：封裝了基礎工具類，希望大家都用起來；某個方法很容易拋出RuntimeException，有必要做處理，但Java語法上RuntimeException并不強制要求處理從而經常遺漏……

這些相似的需求，每次在Lint工程中開發同樣會很繁瑣。我們嘗試實現了幾個模板，可以直接在Android工程中通過配置文件配置Lint規則。

如下為一個配置文件示例：

{"lint-rules": {"deprecated-api": [{"method-regex": "android\\.content\\.Intent\\.get(IntExtra|StringExtra|BooleanExtra|LongExtra|LongArrayExtra|StringArrayListExtra|SerializableExtra|ParcelableArrayListExtra).*","message": "避免直接調用Intent.getXx()方法，特殊機型可能發生Crash，建議使用IntentUtils","severity": "error"},{"field": "java.lang.System.out","message": "請勿直接使用System.out，應該使用LogUtils","severity": "error"},{"construction": "java.lang.Thread","message": "避免單獨創建Thread執行后臺任務，存在性能問題，建議使用AsyncTask","severity": "warning"},{"super-class": "android.widget.BaseAdapter","message": "避免直接使用BaseAdapter，應該使用統一封裝的BaseListAdapter","severity": "warning"}],"handle-exception": [{"method": "android.graphics.Color.parseColor","exception": "java.lang.IllegalArgumentException","message": "Color.parseColor需要加try-catch處理IllegalArgumentException異常","severity": "error"}]} }

示例配置中定義了兩種類型的模板規則：

• DeprecatedApi：禁止直接調用指定API
• HandleException：調用指定API時，需要加try-catch處理指定類型的異常

問題API的匹配，包括方法調用(method)、成員變量引用(field)、構造函數(construction)、繼承(super-class)等類型；匹配字符串支持glob語法或正則表達式（和lint.xml中ignore的配置語法一致）。

實現方面，主要是遍歷Java語法樹中特定類型的節點并轉換成完整字符串（例如方法調用android.content.Intent.getIntExtra），然后檢查是否有模板規則與其匹配。匹配成功后，DeprecatedApi規則直接輸出message報錯；HandleException規則會檢查匹配到的節點是否處理了特定Exception（或Exception的父類），沒有處理則報錯。

按Git版本檢查新增文件

隨著Lint新規則的不斷開發，我們又遇到了一個問題。Android工程中存在大量歷史代碼，不符合新增Lint規則的要求，但也沒有導致明顯問題，這時接入新增Lint規則要求修改所有歷史代碼，成本較高而且有一定風險。例如新增代碼規范，要求使用統一的線程工具類而不允許直接用Handler以避免內存泄露等。

我們嘗試了一個折中的方案：只檢查指定git commit之后新增的文件。在配置文件中添加配置項，給Lint規則配置git-base屬性，其值為commit ID，只檢查此次commit之后新增的文件。

實現方面，執行git rev-parse --show-toplevel命令獲取git工程根目錄的路徑；執行git ls-tree --full-tree --full-name --name-only -r <commit-id>命令獲取指定commit時已有文件列表（相對git根目錄的路徑）。在Scanner回調方法中通過Context.getLocation(node).getFile()獲取節點所在文件，結合git文件列表判斷是否需要檢查這個節點。需要注意的是，代碼量較大時要考慮Lint檢查對電腦的性能消耗。

總結

經過一段時間的實踐發現，Lint靜態代碼檢查在解決特定問題時的效果非常好，例如發現一些語言或API層面比較明確的低級錯誤、幫助進行代碼規范的約束。使用Lint前，不少這類問題恰好對開發人員來說又很容易遺漏（例如原生的NewApi檢查、自定義的SerializableCheck）；相同問題反復出現；代碼規范的執行，特別是有新人參與開發時，需要很高的學習和溝通成本，還經常出現新人提交代碼時由于沒有遵守代碼規范反復被要求修改。而使用Lint后，這些問題都能在第一時間得到解決，節省了大量的人力，提高了代碼質量和開發效率，也提高了App的使用體驗。

參考資料與擴展閱讀

• 使用 Lint 改進您的代碼 | Android Studio
• Android Plugin DSL Reference：LintOptions
• Android自定義Lint實踐
• Lint工具的源碼分析(3)
• Android Studio Release Notes
• Git - Documentation

Lint和Gradle相關技術細節還可以閱讀個人博客：

• Android Lint：基本使用與配置
• Android Lint：自定義Lint調試與開發
• Android Gradle配置快速入門
• Gradle開發快速入門——DSL語法原理與常用API介紹

作者簡介

• 子健，Android高級工程師，2015年畢業于西安電子科技大學并校招加入美團外賣。前期先后負責過外賣App首頁、商家容器、評價等核心業務模塊的開發維護，目前重點負責參與外賣打包自動化、代碼檢查、平臺化等技術工作。

招聘

美團外賣App團隊誠招Android/iOS高級工程師/技術專家，工作地北京/上海可選，歡迎有興趣的同學投遞簡歷到wukai05#meituan.com。

總結

以上是生活随笔為你收集整理的美团外卖Android Lint代码检查实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。