RoboVM 将死

本文翻译自 RoboVM is Dead ，作者是 Mike Fleischauer，翻译已获得本人授权。

文章标题几乎已经说明了一切。虽然这则消息让人感觉遗憾，但基本也在意料之中。也许有人还不知道，RoboVM 是一种可供您在 iOS 设备上运行 Java 应用程序的技术。这种技术也许对游戏开发者最为有用，可以让 LibGDX 应用程序在诸如 iPad、iPhone 以及 Apple TV 等设备上运行。

到底是如何实现的？这里面还有些故事…

为了支持 iOS，LibGDX 于 2013 年 5 月从 Xamarin 迁移至 RoboVM（这事本身就够讽刺了）。当时 RoboVM 还是开源的，在功能方面比 Xamarin 做得更好。当时一切都发展的很好，直到 2015 年 10 月Xamarin 突然收购了 RoboVM。从那时起，这个开源项目基本停摆，大家开始不看好 RoboVM 的未来。Xamarin 通过为 LibGDX 开发者提供免费许可的方式对这一问题做出回应，这些举措打消了开发者对未来的很多顾虑。当时我和 Xamarin 的 CEO Nat Friedman 进行了如下交流，现在看起来就有些诡异了：

真正的魔鬼都隐藏在细节中，对吧！老实说，Nat 是个正直的人，我觉得他当时根本想象不到接下来会发生的事。随后 Microsoft 在 2016 年 2 月宣布收购了 Xamarin。对大部分开发者来说，这无疑是个好消息，因为消息公布后没多久他们就让 Xamarin免费并开源了。这一系列事件中真正让人纳闷的是，RoboVM 到底该怎么处理？Xamarin 以前的目标是掌控向移动设备移至应用的过程，但 Microsoft 的目标更主要是提高.NET 开发堆栈的接受率。这么说吧，目前 Microsoft 并不是 Java 最大的支持者，那么当尘埃落定后，RoboVM 该怎么办？

直到今天，RoboVM 团队发布了这样一则消息：

过去几周来，为了确定 RoboVM 的未来发展方向，我们与 Xamarin 和 Microsoft 合作对该产品的技术和业务情况进行了评估。考虑到使用 Java 进行移动开发的大环境后，我们最终决定逐步停止 RoboVM 的开发。

为了帮助客户消化这则消息的影响，我们准备了一篇常见问题解答。对于其中未包含的问题，请联系我们：support@robovm.com。

我用 RoboVM 开发的应用会遇到什么情况？

客户已经发布的应用将不受任何影响。如果您的应用还在开发中，您还可以像其他任何 iOS 应用那样继续完成开发工作，除非 Apple 在 iOS 中引入了某些较为重大的变动。您在 RoboVM Studio 中创建的 Android 项目和应用可以使用 Android Studio 或 IntelliJ IDEA 打开并编译，您在 Android 和 iOS 上使用的任何跨平台 RoboPods 也依然可以在这些项目中使用，不过可能受到未来一些重大系统级改动的影响。

对于正在使用 RoboVM 开发的应用，我该如何处理？

取决于应用开发工作所处阶段，目前有多种方式可以帮您继续开发，包括帮您移至到Xamarin 的工具，并可换为使用以iOS 为目标的Java SDK 版本。尤其是 libGDX 刚刚公布了自己对 Intel Multi-OS Engine（多操作系统引擎）的支持，这意味着对于目前大部分活跃的 RoboVM 开发者，都有可用的备选方案。此外 Microsoft 和 Xamarin 都非常愿意为您的移动应用开发工作提供帮助，同时我们也希望能帮助您继续前进。如果您想和我们讨论您的应用开发计划，请给我们发邮件：support@robovm.com。

我能否继续使用自己的许可？

可以。在 2017 年 4 月 30 日之前，您可以继续激活现有的已付费或免费赠送的订阅。这样您就有了足够的时间可以将现有应用过渡至其他方案。

我已经购买了许可，可以获得退款吗？

可以。我们对截至今天的所有现有客户提供全额退款服务。请发邮件至 support@robovm.com 申请退款。

简单来说，Microsoft 看了看 RoboVM，发现它与自己的规划不符，于是就一枪崩掉了。疼啊！今时不同往日，连 Microsoft 都在想方设法让自己显得对开源更友好，希望通过包容、扩展，以及废除等做法摆脱自己的过去。他们没有选择将 RoboVM 重新开源，让用户至少能像以前那样自娱自乐，这一点真的让人感觉遗憾。如果有足够多的反对声音，也许他们最终会这样做的，至少现在有关这个话题的讨论对 Microsoft 来说并不是多好的消息。不过他们能为所有提出申请的客户全额退款，这一点做的倒是不错。

与此同时，LibGDX 开发者又该何去何从？从上文链接的内容中可以知道答案。LibGDX 项目的创始人 Mario Zechner 针对这一话题发布了一篇内容相当丰富的博客文章。建议您通读全文以了解各种可用的选项，不过我依然会将重点摘录如下：

RoboVM 将死，然后怎么办？

几位 libGDX 员工持有的免费 RoboVM 许可密钥可用于将自己的 LibGDX 应用部署至 iOS。这些许可密钥在2017 年 4 月 17 日之前可以继续使用。然而RoboVM 将不再获得后续更新，不会增加新的功能或修复 Bug。整个社区所依赖的所有 RoboPods 也将面临相同问题。更重要的是，现在已经无法注册新的免费 RoboVM Indie 许可了。

简而言之，如果您已经使用 RoboVM 开发了一款游戏，在许可过期之前您可以继续使用 RoboVM。如果您要新开发一个游戏，此时将无法使用 RoboVM。但无论哪种情况，您都应该尽早更换为其他备选方案。

备选方案都有什么？

RoboVM 有很多备选方案，然而在功能方面没有一个能比得上 RoboVM。一起来看看这些可用方案吧。我们会从不同的视角审视这些方案：工具 (IDE、Maven、Gradle) 的支持情况、绑定的支持、二进制文件大小、性能，以及与 Bitcode 的兼容性。

深入介绍前，我想重点谈谈对 Bitcode 的兼容性，这也许是最重要的功能。Apple 最近提出了一个新的要求，禁止以原始机器代码 (Raw machine code) 的形式为 watchOS 和 tvOS 提交应用。Apple 希望开发者以 Bitcode 的形式提交应用。Bitcode 是一种（近似于）独立于机器的中间语言，Apple 会通过这种语言为提交的应用生成实际的机器代码。因此任何对于 Bitcode 没有明确支持计划的解决方案都存在巨大的劣势。

可用方案（每个方案的特性和不足之处请参阅 Mario Zechner 的博客原文）：

• Mobile OpenJDK 9
• Codename One
• J2ObjC
• Avian
• Xamarin + IKVM
• Intel Multi-OS Engine

–节略–

LibGDX 在 iOS 上的未来是怎样的？

Tomski 已经为 Multi-OS 引擎写了一个新的 libGDX 后端。LibGDX 的发展路线图如下：

1. 清理 Multi-OS 后端，将其与 libGDX 设置界面相集成，更新相关文档。这些工作我们已经完成了 95%，希望能在本周末某个时间发布相关代码。
2. 下周发布一个新的 libGDX 版本，让 Multi-OS 引擎成为新建 LibGDX 项目的默认 iOS 后端。
3. 开始为流行的第三方 iOS 库创建绑定。我们希望整个社区都能参与到这项工作中。
4. 在许可过期（2017 年 4 月 17 日）前维持 RoboVM 后端继续运行。我们会尽一切努力修复后端可能存在的任何 Bug，然而我们无法修复 RoboVM 本身存在的 Bug。

您现有应用的发展路线图应该是类似这样的：

1. 继续使用 RoboVM 1.14.0 以及相应的后端发布更新。
2. 立刻开始为您在 iOS 平台下的应用添加基于 Multi-OS 引擎的版本。
3. 测试您的应用，并将 Bug 报告至我们的跟踪管理系统。
4. 尽快切换至 Multi-OS 引擎。

目前的情况就是这样。天还没塌，世界末日也还没到，不过前路上很快会遇到一些坎坷。一些人无疑会对此感到沮丧，不过还请理智发泄您的怒火。这件事上 Mario 和 RoboVM 团队并不是反派，实际上他们刚刚失去了自己的孩子，试想一下吧这时候你会有怎样的感觉？

一个好技术因为商业方面的原因被放弃，这种事确实很糟糕。我认为，如果 Microsoft 将 RoboVM 项目开源，而不是彻底杀死它，这样的结果更能让所有人皆大欢喜。再宏伟的计划也有可能无法实现，而开发和维护这种项目所需的技能并不常见。因此不妨给这个技术一条生路，不要让它成为商业决策的牺牲品。更重要的是，这样开发者也能在过渡至新解决方案过程中获得更多时间、更丰富的选项，实现更平滑的过渡。

最终，这不是 Xamarin、RoboVM，或 LibGDX 能决定的。这件事的决定权百分之百在于 Microsoft。如果您想将自己的精力专注于一些有意义的事情，那么这事就是一个很好的目标。毕竟 Microsoft 是一家试图改善自己在非微软平台开发者，以及开源社区成员眼中形象的公司。但是这样的举措… 无疑提供不了任何帮助！

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。