大规模采用 Kotlin 替代 Java？我们应该知道这些利弊

当大规模采用一门新语言时，有许多不同的因素需要考虑，因为事情可能会发生巨大的变化。对于许多人来说，选择一门语言可以说是取决于个人偏好，但在 LinkedIn，我们有一个基础团队，负责评估这些基本技术决策的影响。最近，我们经历了评估 Android 开发语言的过程。从移动基础设施团队的角度来看，我想与你分享一下，我们在评估语言时所采取的步骤，以及为什么我们最终选择了 Kotlin 语言。

方法

大规模采用移动语言有许多不同的因素需要考虑。这样一个决定会对开发人员的生产力、招聘、培训成本以及最终产品产生巨大的影响。例如，你可能会提高开发人员的生产力，并能够交付更多的功能，但是必须付出应用程序大小增加的代价，这最终会影响用户的下载。为了更好地理解采用特定语言的投资和回报，我们认为，公正的技术分析是我们做出决定的基础。一旦做出了客观的评估，我们就可以制定一个最适合整个公司移动开发的路线图。

技术分析

在 Linkedin，Android 开发跨越了不同形式和规模的团队——从开发大型应用程序的大型团队，到开发多个中小型应用程序的小型团队，再到只专注于构建工具和基础设施的团队。为了尽可能全面地执行评估，我们成立了一个委员会，由每个应用程序团队的高级开发人员、基础设施团队和构建工具团队的代表组成。在 LinkedIn 的 Android 开发背景下，这些是我们研究的领域。

语言特性

当谷歌宣布将 Kotlin 作为 Android 开发的官方支持编程语言时，我们都非常激动。Kotlin 作为一门语言，具有许多 Java 世界中没有的新特性，比如空值安全(null-safety)、扩展、数据类、协程等等。虽然我们享受了这些新特性带来的所有好处，但是 Kotlin 还在设计时删除了某些 Java 特性，比如直接原始类型、静态成员、检查异常等等。在我们的分析中，我们深入了解了语言设计决策背后的想法，并研究了反编译代码来理解每个特性。这有助于我们将来制定指导方针，并对我们发布的代码充满信心。

兼容性

在 LinkedIn 的规模下，如果我们决定迁移到一种新的语言，迁移将是一个很长的过程，尤其是对于包含数百万行代码的代码库。正如理解每种语言的特性很重要一样，考虑互操作性也同样重要。幸运的是，Kotlin 和 Android Studio 之间的集成经常提供建议并帮助你重构代码。然而，归根结底，它们是两种不同的语言，让它正常工作只是一个开始。在此过程中，你肯定希望构建一些增强功能。例如，我们遇到的一些问题是为静态成员添加 JVM 注解，并确保 Java API 把单一抽象方法(SAM)转换 参数放在最后，这样 Kotlin 编译器就可以使用拖尾 lambda 语法 。

扩展性

构建时间是移动工程师最优先考虑的问题之一。使用 Kotlin，我们预计构建时间会增加。LinkedIn 的移动开发从数千行代码到数百万行代码不等;因此，构建时间的增加可能有很大差异。这可能不会立即引起注意，但随着时间的推移，我们会密切关注转向 Kotlin 所导致的时间增加，尤其是 LinkedIn 的规模下。为了测试构建时间的长短，我们使用Android Studio Poet 创建了包含不同模块数量、不同 Kotlin 和 Java 代码行的 Android 项目作为模拟，同时保持类似的项目大小和依赖关系图。我们使用Gradle Profiler 测量了清除构建和增量构建，以了解构建时间花在哪里。

考虑到该项目的规模，它有可能影响从开发到生产的许多不同方面。运行时性能是该分析的另一个关键领域。我们在 Kotlin 和 Java 中实现了几种算法作为测试工具，并在物理设备上运行它们。为了使实验更加真实，我们还在这些测试中启用了ProGuard 。研究结果与“Kotlin 和 Java 在 Android 运行时上的性能评估 ”结果一致。有趣的是，Kotlin 中的大部分开销来自空安值全特性，该特性使方法的每个调用都具有非可选参数，都不能被编译器映射到基本类型。这就导致了对 Intrinsics.checkParameterIsNotNull 的调用，它要为我们实验中的大部分开销负责。

应用程序的大小是由许多因素造成的。按照谷歌的说法 ，初始的 Kotlin 标准库导入将使应用程序的大小增加大约 1MB，随着时间的推移，更多的 Java 代码被转换成 Kotlin，由于 Kotlin 字节码方法的增加，应用程序将变得更大。幸运的是，ProGuard 能够从 Kotlin 生成的代码中去除并大大减少未使用的方法。我们创建了示例应用程序，并将它们从 Java 转换为纯 Kotlin，以了解方法数量和应用程序大小的开销。

语言升级

移动开发的前景在不断变化，了解升级过程非常重要。在过去，我们看到语言升级伴随着不兼容的更改、构建失败和许多意外错误，这些错误最终迫使我们锁定主干，甚至执行语言升级。JetBrains 承诺为 Kotlin 提供两种形式的向后兼容性：

新编译器仍将可以使用旧二进制文件(但是旧编译器可能无法识别新二进制文件，比如 javac 1.6，它无法读取由 javac 1.8 编译的类)。

旧二进制文件将可以在运行时继续和新二进制文件一起工作，而新代码可能需要新依赖项。

在源代码兼容性方面，Kotlin 遵循 API 弃用警告的模式，一旦升级到新的编译器版本，该警告就会逐渐变为错误。在过去，我们看到升级通常会给社区足够的时间来适应这些更改。例如，KT-21515 中的语言行为变化被标记为警告，并在接下来的 1.2.x 补丁版本中得以保留，直到 Kotlin 1.3。然而，值得注意的是，JetBrains 并没有声明将在主要版本更改中提供哪种类型的兼容性。

开发者生态系统

Kotlin 能够轻而易举地与 Android Studio 搭配使用并不奇怪，因为 JetBrains 是这两款产品背后的主要贡献者。大多数(如果不是全部的话)Android Studio 工具都可以无缝地与 Kotlin 一起工作，包括调试器、内存分析器、Android 分析器等等。值得一提的 Kotlin 特性包括 Kotlin 自动转换和 Kotlin 反编译器。后者让你深入了解 Kotlin 代码的底层工作机制。

LinkedIn 使用 Gradle 作为 Android 和 Java 产品的实际构建系统。借助 Kotlin- Android Gradle 插件，Kotlin 在 Gradle 中可以顺畅地工作。Gradle 企业版提供远程缓存解决方案。Kotlin 1.2.21 允许 Kotlin 项目使用构建缓存。具体来说，对于 Gradle 构建缓存，它还需要使用 Kotlin Gradle Plugin 1.2.20 和 Gradle 4.3 或更高版本。总的来说，由于采用 Kotlin 而引起的构建工具的变化很少。然而，我们的分析主要集中在 Gradle 上，可能不适用于其他构建系统，比如 Buck。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!