Meta 一直在将他们的Android代码库从Java移植到Kotlin。Meta 的工程师 Omer Strulovich 解释说，在这个过程中，他们学到了许多有趣的经验教训，并积累了一些有用的方法。
Meta 之所以决定采用 Kotlin 开发 Android 应用，是因为他们看到了Kotlin相对于 Java 的优势，包括可空性和函数式编程支持、更简短的代码，以及创建特定领域语言的可能性。Kotlin 工程师还清楚地知道，他们必须将尽可能多的 Java 代码库移植到 Kotlin，以防止 Java 空指针问题潜入 Kotlin 代码库，并减少需要维护的 Java 代码。这不是一件容易的事，从一开始就需要做相当多的调研工作。
Meta 工程师必须克服的第一个障碍是，Meta 使用的几个内部优化工具无法与 Kotlin 正常兼容。例如，Meta 必须更新ReDex Android字节码优化器和语法高亮显示工具 Pygments 的词法分析器组件，并构建一个Kotlin符号处理（KSP）API，用于创建 Kotlin 编译器插件。
在代码转换方面，Meta 工程师选择使用 Kotlin 官方转换器 J2K，它可以作为编译器插件使用。除了一些特定的框架（包括 JUnit）之外，这种方法工作得非常好。但对于特定的框架，这个工具缺乏足够的知识，无法进行正确的转换。
我们已经遇到了很多需要进行小修复的情况。有些很容易做到（比如替换 isEmpty），有些需要做一些研究工作才能搞清楚（与 JUnit 规则的情况一样），还有一些是针对 J2K 本身的 bug 的变通方法，这些 bug 可能会导致出现任何问题——从构建时错误到运行时行为。
处理这种情况的正确方法包括三个步骤：首先是准备好 Java 代码，然后在 headless 模式的 Android Studio 实例中自动运行 J2K，最后对生成的文件进行后续处理，进行所有所需的重构和修复。Meta 已经开源了许多重构工具，以帮助其他开发人员完成相同的任务。
这些自动化转换过程并不能解决所有的问题，但我们能够优先解决最常见的问题。我们针对模块运行转换脚本（我们贴切地称之为 Kotlinator），优先考虑活跃和简单的模块。然后我们观察生成的代码：它们可以通过编译吗？它们是否可以顺利通过我们的持续集成管道？如果可以，我们就提交它们。如果不可以，我们就研究问题，并设计新的自动重构过程来修复它们。
Meta 已经通过这种方式移植了超过 1000 万行 Kotlin 代码，让大多数的 Meta Android 工程师切换到Kotlin来完成他们的日常工作。这个过程也验证了许多预期的结果，包括更短的生成代码和不变的执行速度。但是，从消极的方面来看，Kotlin 编译器比 Java 编译器慢得多。使用 KSP 来处理注解，改进 Java 存根生成和编译时间，这为优化带来了新的可能性，不过仍然需要持续的努力。
如果你对完整的细节感兴趣，请不要错过 Meta 的这篇关于迁移到 Kotlin 的文章。
原文链接：
https://www.infoq.com/news/2022/11/meta-port-java-kotlin/
相关阅读：
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论