概述

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

為什么要使用Lint

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

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

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

我們調(diào)研發(fā)現(xiàn)，靜態(tài)代碼檢查是一個很好的思路。靜態(tài)代碼檢查框架有很多種，例如FindBugs、PMD、Coverity，主要用于檢查Java源文件或class文件；再例如Checkstyle，主要關(guān)注代碼風(fēng)格；但我們最終選擇從Lint框架入手，因為它有諸多優(yōu)勢：

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

擴展性強，支持開發(fā)自定義Lint規(guī)則。

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

Lint專為Android設(shè)計，原生提供了幾百個實用的Android相關(guān)檢查規(guī)則。

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

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

Lint API簡介

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

主要API

Lint規(guī)則通過調(diào)用Lint API實現(xiàn)，其中最主要的幾個API如下：

Issue：表示一個Lint規(guī)則。

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

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

Scanner：用于掃描并發(fā)現(xiàn)代碼中的Issue，每個Detector可以實現(xiàn)一到多個Scanner。

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

舉例來說，原生的ShowToast就是一個Issue，該規(guī)則檢查調(diào)用Toast.makeText()方法后是否漏掉了Toast.show()的調(diào)用。其Detector為ToastDetector，要檢查的Scope為JAVA_FILE_SCOPE，ToastDetector實現(xiàn)了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開發(fā)過程中最主要的工作就是實現(xiàn)Scanner。Lint中包括多種類型的Scanner如下，其中最常用的是掃描Java源文件和XML文件的Scanner。

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

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

最開始使用的是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實現(xiàn)的自定義Lint規(guī)則，可以被加載到Android Studio 2.2+版本中，在編寫Android代碼時實時執(zhí)行。

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

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

Lint規(guī)則

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

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

Crash預(yù)防

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

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

Bug預(yù)防

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

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

性能/安全問題

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

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

代碼規(guī)范

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

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

代碼檢查的實施

當(dāng)檢查出代碼問題時，如何提醒開發(fā)者及時修正呢？

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

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

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

高優(yōu)問題的解決，要有一定的強制性。當(dāng)檢查發(fā)現(xiàn)高優(yōu)先級的代碼問題時，給開發(fā)者明確直接的報錯，并通過技術(shù)手段約束，強制要求開發(fā)者修復(fù)。

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

優(yōu)先級定義

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

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

執(zhí)行時機

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

手動執(zhí)行

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

在Gradle命令行環(huán)境下，可直接用./gradlew lint執(zhí)行Lint檢查。

手動執(zhí)行簡單易用，但缺乏強制性，容易被開發(fā)者遺漏。

編碼階段實時檢查

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

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

技術(shù)細節(jié)：

在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規(guī)則，在設(shè)置菜單的Inspections列表里可以查看，和原生Lint效果相同（Android Studio會在打開源文件時觸發(fā)對該文件的代碼檢查）。

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

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

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

本地編譯時自動檢查

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

編譯Android工程執(zhí)行的是assemble任務(wù)，讓assemble依賴lint任務(wù)，即可在編譯時執(zhí)行Lint檢查；同時配置LintOptions，發(fā)現(xiàn)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代碼前執(zhí)行Lint檢查，檢查不通過則無法提交代碼。這種方式的優(yōu)勢在于不影響開發(fā)時的編譯速度，但發(fā)現(xiàn)問題相對滯后。

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

提代碼時CI檢查

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

CI系統(tǒng)常用Jenkins，如果使用Stash做代碼管理，可以在Stash上配置Pull Request Notifier for Stash插件，或在Jenkins上配置Stash Pull Request Builder插件，實現(xiàn)發(fā)Pull Request時觸發(fā)Jenkins執(zhí)行Lint檢查的Job。

在本地編譯和CI系統(tǒng)中做代碼檢查，都可以通過執(zhí)行Gradle的Lint任務(wù)實現(xiàn)?？梢栽贑I環(huán)境下給Gradle傳遞一個StartParameter，Gradle腳本中如果讀取到這個參數(shù)，則配置LintOptions檢查所有Lint問題；否則在本地編譯環(huán)境下只檢查部分高優(yōu)先級Lint問題，減少對本地編譯速度的影響。

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

打包發(fā)布時檢查

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

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

最終確定的檢查時機

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

編碼階段IDE實時檢查，第一時間發(fā)現(xiàn)問題。

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

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

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

配置文件支持

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

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

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

于是我們嘗試使用配置文件來解決這一問題。以檢查Log使用的LogUsage為例，不同工程封裝了不同的Log工具類，報錯時提示信息也應(yīng)該不一樣。定義配置文件名為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對象可獲取被檢查工程目錄從而讀取配置文件，關(guān)鍵代碼如下：

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回調(diào)方法中進行。LogUsage中檢查到錯誤時，根據(jù)配置文件定義的信息報錯。

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規(guī)則

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

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

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

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

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

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

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

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

按Git版本檢查新增文件

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

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

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

總結(jié)

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

參考資料與擴展閱讀

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

Lint和Gradle相關(guān)技術(shù)細節(jié)還可以閱讀個人博客：

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

作者簡介

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

招聘

美團外賣App團隊誠招Android/iOS高級工程師/技術(shù)專家，工作地北京/上?？蛇x，歡迎有興趣的同學(xué)投遞簡歷到wukai05#meituan.com。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。