Kotlin 有着诸多的特性,比如空指针安全、方法扩展、支持函数式编程、丰富的语法糖等。这些特性使得 Kotlin 的代码比 Java 简洁优雅许多,提高了代码的可读性和可维护性,节省了开发时间,提高了开发效率。这也是我们团队转向 Kotlin 的原因,但是在实际的使用过程中,我们发现看似写法简单的 Kotlin 代码,可能隐藏着不容忽视的额外开销。
本场 Chat 剖析了 Kotlin 的隐藏开销,并就如何避免开销进行了探索和实践,主要从以下几个方面进行分析:
作者简介:周佳,美团点评前端 Android 开发工程师,2016年毕业于南京信息工程大学,同年加入美团点评到店餐饮事业群,参与大众点评美食频道的日常开发工作。
Kotlin 有着诸多的特性,比如空指针安全、方法扩展、支持函数式编程、丰富的语法糖等。这些特性使得 Kotlin 的代码比 Java 简洁优雅许多,提高了代码的可读性和可维护性,节省了开发时间,提高了开发效率。这也是我们团队转向 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 代码无疑是低效的。
我们可以通过以下解决方法来减少生成的字节码:
const
关键字将常量声明为编译时常量。@JvmField
注解。lazy()
委托属性可以用于只读属性的惰性加载,但是在使用 lazy()
时经常被忽视的地方就是有一个可选的 model 参数:
lazy()
默认情况下会指定LazyThreadSafetyMode.SYNCHRONIZED
,这可能会造成不必要线程安全的开销,应该根据实际情况,指定合适的 model 来避免不需要的同步锁。
在 Kotlin 中有 3 种数组类型:
IntArray
, FloatArray
,其他:基本类型数组,被编译成int[]
, float[]
,其他Array
:非空对象数组Array
:可空对象数组使用这三种类型来声明数组,可以发现它们之间的区别:
等同的 Java 代码:
后面两种方法都对基本类型做了装箱处理,产生了额外的开销。
所以当需要声明非空的基本类型数组时,应该使用 xxxArray,避免自动装箱。
Kotlin提供了 downTo
、 step
、 until
、 reversed
等函数来帮助开发者更简单的使用 For 循环,如果单一的使用这些函数确实是方便简洁又高效,但要是将其中两个结合呢?比如下面这样:
上面的 For 循环中结合使用了 downTo
和 step
,那么等同的 Java 代码又是怎么实现的呢?
重点看这行代码:
IntProgression var10000 = RangesKt.step(RangesKt.downTo(10, 1), 2);
这行代码就创建了两个 IntProgression
临时对象,增加了额外的开销。
Kotlin 的隐藏开销不止上面列举的几个,为了避免开销,我们需要实现这样一个工具,实现 Kotlin 语法的检查,列出不规范的代码并给出修改意见。同时为了保证开发同学的代码都是经过工具检查的,整个检查流程应该自动化。
再进一步考虑,Kotlin 代码的检查规则应该具有扩展性,方便其他使用方定制自己的检查规则。
基于此,整个工具主要包含下面三个方面的内容:
结合对工具的需求,在经过思考和查阅资料之后,确定了三种可供选择的方案:
ktlint 是一款用来检查 Kotlin 代码风格的工具,和我们的工具定位不同,需要经过大量的改造工作才行。
detekt 是一款用来静态分析 Kotlin 代码的工具,符合我们的需求,但是不太适合 Android 工程,比如无法指定 variant(变种)检查。另外,在整个检查流程中,一份 kt
文件只能检查一次,检查结果(当时)只支持控制台输出,不便于阅读。
改造 Lint 来增加 Lint 对 Kotlin 代码检查的支持,一方面 Lint 提供的功能完全可以满足我们的需求,同时还能支持资源文件和 class 文件的检查,另一方面改造后的 Lint 和 Lint 很相似,学习上手的成本低。
相对于前两种方案,方案 3 的成本收益比最高,所以我们决定改造 Lint 成 Kotlin Lint(KLint) 插件。
先来大致了解下 Lint 的工作流程,如下图:
很显然,上图中的红框部分需要被改造以适配 Kotlin,主要工作有以下 3 点:
和 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
来实现目的。
最后采用的方案是:
klintrules
这个空的 aar,将 klint.jar
放入 assets 中;klint.jar
;klintrules
aar 时使用 debugCompile 来避免把 klint.jar
带到 release 包。既然是对 Kotlin 代码的检查,自然 Detector 类要定义一套新的接口方法。先来看一下 Java 代码检查规则提供的方法:
相信写过 Lint 规则的同学对上面的方法应该非常熟悉。为了尽量降低 KLint 检查规则编写的学习成本,我们参照 JavaPsiScanner 接口,定义了一套非常相似的接口方法:
通过对上述 3 个主要方面的改造,完成了 KLint 插件。
由于 KLint 和 Lint 的相似,KLint 插件简单易上手:
@SuppressWarnings("")
等Lint支持的注解;mtKlint { klintOptions { abortOnError false htmlReport true htmlOutput new File(project.getBuildDir(), "mtKLint.html") }}
关于自动检查有两个方案:
pre-commit/push-hook
进行检查,检查不通过不允许 commit/push;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 插件。
通过这款工具,实现在 Android Studio 的窗口实时报错,帮助开发同学第一时间发现问题及时解决。
KLint 插件分为 Gradle 插件和 IDE 插件两部分,前者在 build.gradle
中引入,后者通过 Android Studio
安装使用。
针对上面列举的 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 插件共用一套规则,所以上面的规则编写一次,就可以同时在两个插件中使用:
借助 KLint 插件,编写检查规则来约束不规范的 Kotlin 代码,一方面避免了隐藏开销,提高了 Kotlin 代码的性能,另一方面也帮助开发同学更好的理解 Kotlin。
周佳,美团前端 Android 开发工程师,2016 年毕业于南京信息工程大学,同年加入美团到店餐饮事业群,参与大众点评美食频道的日常开发工作。
本文首发于GitChat,未经授权不得转载,转载需与GitChat联系。
阅读全文: http://gitbook.cn/gitchat/activity/5b3dd77505765f300a81bfe0
您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ,阅读更多 GitChat 专享技术内容哦。