当大规模采用一门新语言时，有许多不同的因素需要考虑，因为事情可能会发生巨大的变化。对于许多人来说，选择一门语言可以说是取决于个人偏好，但在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。

正如我们关注开发人员的生产力一样，质量也是我们要考虑的另一个重要因素。编写测试对于确保代码质量至关重要。我们花了一些时间来理解测试生态系统的局限性及其与其他语言的兼容性。这不仅包括测试框架，还包括代码覆盖率分析、CI管道，最重要的是，在开始编写Kotlin测试之前，在不违背测试标准的情况下所要采取的步骤。该分析还包括Android中的主要静态分析工具Android Lint，它现在使用UAST支持Java和Kotlin分析及样式检查工具。

行业分析

自从Kotlin于2017年在谷歌I/O大会上宣布成为Android开发的一等语言以来，越来越多的工程师开始接受Kotlin。Stack Overflow 2018调查显示，Kotlin是第二受欢迎的编程语言。Kotlin还被认为是未来语言中增长最快的语言，与Swift、Go、Haskell和Rust并列第一。据谷歌报道，2017年，当Kotlin被宣布为Android开发的第一语言时，Google Play中9%的应用程序已经在使用Kotlin。一年后，即2018年5月，谷歌宣布这一数字已增至35%，同比增长近6倍。

我们分析了Google Play商店中的前300个免费应用程序，并根据它们的DEX文件大小进行了筛选，以了解有多少应用程序在大规模使用Kotlin。虽然这个数字包含了所有第三方库的代码，但它能很好地反映应用程序代码的大小。作为一个初步步骤，我们排除了APK中没有专门Kotlin文件夹的应用程序，该文件夹将包含Kotlin运行时使用的一些Kotlin内置文件。由于代码的混淆，计算Kotlin在代码中的百分比非常棘手。但是，我们使用apktool将所有DEX文件转换为SMALI代码，并发现了两个不同的线索，它们标识了用Kotlin编写的类。对于没有从.source属性中删除原始文件名的应用程序，我们可以提取扩展名*.kt。对于其他应用程序，我们寻找kotlin.Metadata类。总的来说，我们能够建立一个图表来显示应用程序及其类的数量、代码大小和Kotlin百分比。这让我们了解到社区有多成熟，以及我们可以从合作伙伴那里得到多少支持。

起初，大多数库所有者认为，在自己的代码中使用Kotlin实现细节是不成熟的，不应该强加给用户。随着Kotlin社区变得越来越活跃，这种观点已经开始转变。Square是许多最受欢迎的Android开源库的所有者，它宣布他们的核心Okio库已经用Kotlin重写，并且他们将在未来的所有版本中使用Kotlin。其他一些库项目已经选择遵循谷歌针对Android KTX提供的示例，并发布了一个用Java编写的基本库，在其中单独的构件中添加了特定于Kotlin的扩展点。例如，FasterXML的Jackson项目添加了一个用于序列化和反序列化Kotlin类的Kotlin模块，以及Mockito，该项目正在研究添加一个针对Kotlin优化过的mock语法。

全方位考察

除了上面列出的要点，我们还花时间研究了与LinkedIn内部工具系统的集成，包括崩溃报告、审查流程和CI管道。我们不断与社区和其他公司的开发人员进行沟通，包括谷歌和JetBrains，不仅要了解他们的方向，还要确保我们的决定与未来的Android开发保持一致。人才始终是我们首先要考虑的因素之一；因此，与招聘和培训有关的成本也是我们分析的重要部分。

总的来说，我们从社区听到了各种好处和证词。综合分析，我们能够建立一个路线图，使LinkedIn进入下一个使用Kotlin的Android开发时代，并且相信，我们可以最小化技术风险，已经了解了对招聘和培训的影响，能够保持技术标准，并不断为我们的会员提供价值。

原文链接：

Evaluating Language Adoption At Scale

创作场景

要不要大规模采用 Kotlin 替代 Java？我们做了这些考量