Kotlin代碼檢查在美團的探索與實踐

背景

Kotlin有著諸多的特性，比如空指針安全、方法擴展、支持函數式編程、豐富的語法糖等。這些特性使得Kotlin的代碼比Java簡潔優雅許多，提高了代碼的可讀性和可維護性，節省了開發時間，提高了開發效率。這也是我們團隊轉向Kotlin的原因，但是在實際的使用過程中，我們發現看似寫法簡單的Kotlin代碼，可能隱藏著不容忽視的額外開銷。本文剖析了Kotlin的隱藏開銷，並就如何避免開銷進行了探索和實踐。

Kotlin的隱藏開銷

伴生對象

伴生對象通過在類中使用companion object來創建，用來替代靜態成員，類似於Java中的靜態內部類。所以在伴生對象中聲明常量是很常見的做法，但如果寫法不對，可能就會產生額外開銷。比如下面這段聲明Version常量的代碼：

class Demo { fun getVersion(): Int { return Version } companion object { private val Version = 1 }}

表面上看還算簡潔，但是將這段Kotlin代碼轉化成等同的Java代碼後，卻顯得晦澀難懂：

public class Demo { private static final int Version = 1; public static final Demo.Companion Companion = new Demo.Companion(); public final int getVersion() { return Companion.access$getVersion$p(Companion); } public static int access$getVersion$cp() { return Version; } public static final class Companion { private static int access$getVersion$p(Companion companion) { return companion.getVersion(); } private int getVersion() { return Demo.access$getVersion$cp(); } }}

與Java直接讀取一個常量不同，Kotlin訪問一個伴生對象的私有常量字段需要經過以下方法：

• 調用伴生對象的靜態方法
• 調用伴生對象的實例方法
• 調用主類的靜態方法
• 讀取主類中的靜態字段

為了訪問一個常量，而多花費調用4個方法的開銷，這樣的Kotlin代碼無疑是低效的。

我們可以通過以下解決方法來減少生成的字節碼：

1. 對於基本類型和字符串，可以使用const關鍵字將常量聲明為編譯時常量。
2. 對於公共字段，可以使用@JvmField註解。
3. 對於其他類型的常量，最好在它們自己的主類對象而不是伴生對象中來存儲公共的全局常量。

lazy()委託屬性

lazy()委託屬性可以用於只讀屬性的惰性加載，但是在使用lazy()時經常被忽視的地方就是有一個可選的model參數：

• LazyThreadSafetyMode.SYNCHRONIZED：初始化屬性時會有雙重鎖檢查，保證該值只在一個線程中計算，並且所有線程會得到相同的值。
• LazyThreadSafetyMode.PUBLICATION：多個線程會同時執行，初始化屬性的函數會被多次調用，但是隻有第一個返回的值被當做委託屬性的值。
• LazyThreadSafetyMode.NONE：沒有雙重鎖檢查，不應該用在多線程下。

lazy()默認情況下會指定LazyThreadSafetyMode.SYNCHRONIZED，這可能會造成不必要線程安全的開銷，應該根據實際情況，指定合適的model來避免不需要的同步鎖。

基本類型數組

在Kotlin中有3種數組類型：

• IntArray，FloatArray，其他：基本類型數組，被編譯成int[]，float[]，其他
• Array：非空對象數組
• Array：可空對象數組

使用這三種類型來聲明數組，可以發現它們之間的區別：

等同的Java代碼：

後面兩種方法都對基本類型做了裝箱處理，產生了額外的開銷。

所以當需要聲明非空的基本類型數組時，應該使用xxxArray，避免自動裝箱。

for循環

Kotlin提供了downTo、step、until、 reversed等函數來幫助開發者更簡單的使用for循環，如果單一的使用這些函數確實是方便簡潔又高效，但要是將其中兩個結合呢？比如下面這樣：

上面的for循環中結合使用了downTo和step，那麼等同的Java代碼又是怎麼實現的呢？

重點看這行代碼：

IntProgression var10000 = RangesKt.step(RangesKt.downTo(10, 1), 2);

這行代碼就創建了兩個IntProgression臨時對象，增加了額外的開銷。

Kotlin檢查工具的探索

Kotlin的隱藏開銷不止上面列舉的幾個，為了避免開銷，我們需要實現這樣一個工具，實現Kotlin語法的檢查，列出不規範的代碼並給出修改意見。同時為了保證開發同學的代碼都是經過工具檢查的，整個檢查流程應該自動化。

再進一步考慮，Kotlin代碼的檢查規則應該具有擴展性，方便其他使用方定製自己的檢查規則。

基於此，整個工具主要包含下面三個方面的內容：

1. 解析Kotlin代碼
2. 編寫可擴展的自定義代碼檢查規則
3. 檢查自動化

結合對工具的需求，在經過思考和查閱資料之後，確定了三種可供選擇的方案：

ktlint

ktlint是一款用來檢查Kotlin代碼風格的工具，和我們的工具定位不同，需要經過大量的改造工作才行。

detekt

detekt是一款用來靜態分析Kotlin代碼的工具，符合我們的需求，但是不太適合Android工程，比如無法指定variant（變種）檢查。另外，在整個檢查流程中，一份kt文件只能檢查一次，檢查結果（當時）只支持控制檯輸出，不便於閱讀。

改造Lint

改造Lint來增加Lint對Kotlin代碼檢查的支持，一方面Lint提供的功能完全可以滿足我們的需求，同時還能支持資源文件和class文件的檢查，另一方面改造後的Lint和Lint很相似，學習上手的成本低。

相對於前兩種方案，方案3的成本收益比最高，所以我們決定改造Lint成Kotlin Lint（KLint）插件。

先來大致瞭解下Lint的工作流程，如下圖：

Lint流程圖

很顯然，上圖中的紅框部分需要被改造以適配Kotlin，主要工作有以下3點：

• 創建KotlinParser對象，用來解析Kotlin代碼
• 從aar中獲取自定義KLint規則的jar包
• Detector類需要定義一套新的接口方法來適配遍歷Kotlin節點回調時的調用

Kotlin代碼解析

和Java一樣，Kotlin也有自己的抽象語法樹。可惜的是目前還沒有解析Kotlin語法樹的單獨庫，只能通過Kotlin編譯器這個庫中的相關類來解析。KLint用的是kotlin-compiler-embeddable:1.1.2-5庫。

public KtFile parseKotlinToPsi(@NonNull File file) { try { org.jetbrains.kotlin.com.intellij.openapi.project.Project ktProject = KotlinCoreEnvironment.Companion.createForProduction(() -> { }, new CompilerConfiguration(), CollectionsKt.emptyList()).getProject(); this.psiFileFactory = PsiFileFactory.getInstance(ktProject); return (KtFile) psiFileFactory.createFileFromText(file.getName(), KotlinLanguage.INSTANCE, readFileToString(file, "UTF-8")); } catch (IOException e) { e.printStackTrace(); } return null; } //可忽視，只是將文件轉成字符流 public static String readFileToString(File file, String encoding) throws IOException { FileInputStream stream = new FileInputStream(file); String result = null; try { result = readInputStreamToString(stream, encoding); } finally { try { stream.close(); } catch (IOException e) { // ignore } } return result; }

以上這段代碼可以封裝成KotlinParser類，主要作用是將.Kt文件轉化成KtFile對象。

在檢查Kotlin文件時調用KtFile.acceptChildren(KtVisitorVoid)後，KtVisitorVoid便會多次回調遍歷到的各個節點（Node）的方法：

KtVisitorVoid visitorVoid = new KtVisitorVoid(){ @Override public void visitClass(@NotNull KtClass klass) { super.visitClass(klass); } @Override public void visitPrimaryConstructor(@NotNull KtPrimaryConstructor constructor) { super.visitPrimaryConstructor(constructor); } @Override public void visitProperty(@NotNull KtProperty property) { super.visitProperty(property); } ...};ktPsiFile.acceptChildren(visitorVoid);

自定義KLint規則的實現參考了Android自定義Lint實踐這篇文章。

上圖展示了aar中允許包含的文件，aar中可以包含lint.jar，這也是Android自定義Lint實踐這篇文章採用的實現方式。但是klint.jar不能直接放入aar中，當然更不應該將klint.jar重命名成lint.jar來實現目的。

最後採用的方案是：

1. 通過創建klintrules這個空的aar，將klint.jar放入assets中；
2. 修改KLint代碼實現從assets中讀取klint.jar；
3. 項目依賴klintrulesaar時使用debugCompile來避免把klint.jar帶到release包。

Detector類中接口方法的定義

既然是對Kotlin代碼的檢查，自然Detector類要定義一套新的接口方法。先來看一下Java代碼檢查規則提供的方法：

相信寫過Lint規則的同學對上面的方法應該非常熟悉。為了儘量降低KLint檢查規則編寫的學習成本，我們參照JavaPsiScanner接口，定義了一套非常相似的接口方法：

KLint的實現

通過對上述3個主要方面的改造，完成了KLint插件。

由於KLint和Lint的相似，KLint插件簡單易上手：

1. 和Lint相似的編寫規範（參考最後一節的代碼）；
2. 支持@SuppressWarnings("")等Lint支持的註解；
3. 具有和Lint的Options相同功能的klintOptions，如下：

mtKlint { klintOptions { abortOnError false htmlReport true htmlOutput new File(project.getBuildDir(), "mtKLint.html") }}

檢查自動化

• 關於自動檢查有兩個方案：

1. 在開發同學commit/push代碼時，觸發pre-commit/push-hook進行檢查，檢查不通過不允許commit/push；
2. 在創建pull request時，觸發CI構建進行檢查，檢查不通過不允許merge。

這裡更偏向於方案2，因為pre-commit/push-hook可以通過--no-verify命令繞過，我們希望所有的Kotlin代碼都是通過檢查的。

KLint插件本身支持通過./gradlew mtKLint命令運行，但是考慮到幾乎所有的項目在CI構建上都會執行Lint檢查，把KLint和Lint綁定在一起可以省去CI構建腳本接入KLint插件的成本。

通過以下代碼，將lint task依賴klint task，實現在執行Lint之前先執行KLint檢查：

//創建KLint task，並設置被Lint task依賴KLint klintTask = project.getTasks().create(String.format(TASK_NAME, ""), KLint.class, new KLint.GlobalConfigAction(globalScope, null, KLintOptions.create(project)))Set lintTasks = project.tasks.findAll { it.name.toLowerCase().equals("lint")}lintTasks.each { lint -> klintTask.dependsOn lint.taskDependencies.getDependencies(lint) lint.dependsOn klintTask}//創建Klint變種task，並設置被Lint變種task依賴for (Variant variant : androidProject.variants) { klintTask = project.getTasks().create(String.format(TASK_NAME, variant.name.capitalize()), KLint.class, new KLint.GlobalConfigAction(globalScope, variant, KLintOptions.create(project))) lintTasks = project.tasks.findAll { it.name.startsWith("lint") && it.name.toLowerCase().endsWith(variant.name.toLowerCase()) } lintTasks.each { lint -> klintTask.dependsOn lint.taskDependencies.getDependencies(lint) lint.dependsOn klintTask }}

檢查實時化

雖然實現了檢查的自動化，但是可以發現執行自動檢查的時機相對滯後，往往是開發同學準備合代碼的時候，這時再去修改代碼成本高並且存在風險。CI上的自動檢查應該是作為是否有“漏網之魚”的最後一道關卡，而問題應該暴露在代碼編寫的過程中。基於此，我們開發了Kotlin代碼實時檢查的IDE插件。

KLint IDE插件

通過這款工具，實現在Android Studio的窗口實時報錯，幫助開發同學第一時間發現問題及時解決。

Kotlin代碼檢查實踐

KLint插件分為Gradle插件和IDE插件兩部分，前者在build.gradle中引入，後者通過Android Studio安裝使用。

KLint規則的編寫

針對上面列舉的lazy()中未指定mode的case，KLint實現了對應的檢查規則：

public class LazyDetector extends Detector implements Detector.KtPsiScanner { public static final Issue ISSUE = Issue.create( "Lazy Warning",  "Missing specify `lazy` mode ", "see detail: https://wiki.sankuai.com/pages/viewpage.action?pageId=1322215247", Category.CORRECTNESS, 6, Severity.ERROR, new Implementation( LazyDetector.class, EnumSet.of(Scope.KOTLIN_FILE))); @Override public List> getApplicableKtPsiTypes() { return Arrays.asList(KtPropertyDelegate.class); } @Override public KtVisitorVoid createKtPsiVisitor(KotlinContext context) { return new KtVisitorVoid() { @Override public void visitPropertyDelegate(@NotNull KtPropertyDelegate delegate) { boolean isLazy = false; boolean isSpeifyMode = false; KtExpression expression = delegate.getExpression(); if (expression != null) { PsiElement[] psiElements = expression.getChildren(); for (PsiElement psiElement : psiElements) { if (psiElement instanceof KtNameReferenceExpression) { if ("lazy".equals(((KtNameReferenceExpression) psiElement).getReferencedName())) { isLazy = true; } } else if (psiElement instanceof KtValueArgumentList) { List valueArguments = ((KtValueArgumentList) psiElement).getArguments(); for (KtValueArgument valueArgument : valueArguments) { KtExpression argumentValue = valueArgument.getArgumentExpression(); if (argumentValue != null) { if (argumentValue.getText().contains("SYNCHRONIZED") || argumentValue.getText().contains("PUBLICATION") || argumentValue.getText().contains("NONE")) { isSpeifyMode = true; } } } } } if (isLazy && !isSpeifyMode) { context.report(ISSUE, expression,context.getLocation(expression.getContext()), "Specify the appropriate thread safety mode to avoid locking when it’s not needed."); } } } }; }}

檢查結果

Gradle插件和IDE插件共用一套規則，所以上面的規則編寫一次，就可以同時在兩個插件中使用：

• CI上自動檢查對應的檢測結果的html頁面：

檢測結果的html頁面

• Android Studio上對應的實時報錯信息：

實時報錯信息

總結

藉助KLint插件，編寫檢查規則來約束不規範的Kotlin代碼，一方面避免了隱藏開銷，提高了Kotlin代碼的性能，另一方面也幫助開發同學更好的理解Kotlin。

• Exploring Kotlin's hidden costs
• Android自定義Lint實踐

周佳，美團點評前端Android開發工程師，2016年畢業於南京信息工程大學，同年加入美團點評到店餐飲事業群，參與大眾點評美食頻道的日常開發工作。

閱讀更多 美團技術團隊 的文章

關鍵字: 編程語言 美團 腳本語言