我正在寻找多个移动平台开发的替代方案，并发现了Codename One，它使用Java作为 通用语言，而不是HTML/CSS/JS或脚本语言。
我没有找到它的工作原理。它是否为iOS和Win7捆绑了JVM，并在Android中使用Dalvik？它是否将源代码翻译成本地语言，并且我们可以访问该源代码？考虑到他们承诺“无折衷”，是否有其他奇技淫巧？当我编写面向不特定Java的代码时，应该注意哪些限制？
预防措施：这是关于Codename One的问题，而不是关于选择跨平台、选择本地还是选择Web的问题。
Codename One 提供了一种可选的SaaS方法，因此未来可能会改变以适应改进的架构。请注意，Codename One还提供了一个离线构建选项，这意味着那些禁止使用云架构的机构仍然可以使用Codename One，但需要额外的开销和复杂性。它也意味着您可以免费使用它，而不必与构建服务器配合工作。
目前在Android上，标准的Java代码照常运行。在使用时，Java 8语法将使用retrolambda转换为所有平台。这使其与所有Android版本以及其他端口兼容。
在iOS上，Codename One构建并开源了ParparVM，这是一个非常保守的虚拟机。ParparVM具有并发（非阻塞）GC，并且完全由Java/C编写。这实际上意味着在构建服务器上生成并编译了一个xcode项目，因此就像手动编写本地应用程序一样，“未来可靠”适应Apple的更改。例如，针对iOS构建的最新64位和位码更改，ParparVM无需进行任何修改即可符合这些更改。
过去，Codename One使用XMLVM以非常相似的方式生成本地代码，但是XMLVM解决方案对Codename One的需求过于通用。
iOS构建在云中的Mac上使用xcode（官方的苹果构建工具）进行编译和签名。这使它们与当前/未来的Apple更改兼容，并允许开发人员在针对iOS时使用Windows / Linux。您可以在此处了解有关ParparVM与iOS兼容性的更多信息。
过去，Codename One曾使用一个基于XMLVM的C#翻译器来支持Windows Phone，但这并不是一个理想的方法。需要注意的是，将代码转换成C#的XMLVM后端与以前用于iOS转换的后端非常不同。Codename One选择停止使用旧后端，因为它不如新的UWP后端强大，并且不能与Microsoft未来的目标相匹配，即集中关注UWP（通用Windows平台）。对于Windows 10桌面和移动设备的支持，Codename One使用iKVM来针对UWP（通用Windows平台），并已经在Codename One github存储库中开源了对原始iKVM代码的更改。
需要注意的是，UWP构建是在云中的Windows 10计算机上完成的，因此允许开发人员在构建本地Windows应用程序时使用Mac / Linux或旧版本的Windows...
企业级订阅者可以使用JavaScript构建目标，它们使用TeaVM进行静态翻译。 TeaVM通过一种相当复杂的方式将应用程序分解为线程以使用JavaScript。为了支持复杂的UI，Codename One使用HTML5 Canvas API，该API允许绝对灵活地构建应用程序。
对于桌面构建，Codename One使用javafxpackager，因为在云中可以使用Mac和Windows机器，所以javafxpackager的特定于平台的本质不是问题。
Codename One采取了非常平衡的可移植性方法。我想加入实用主义的评论。
从用户界面方面来看，CN1确实在平台提供的画布上绘制其所有UI。如果您选择它，它会尝试模仿平台原生外观和感觉，但与Swing的“本机平台外观和感觉”一样成功，因为本机平台不断变化，“本地外观和感觉”总是滞后的，并且在大多数情况下感觉不太对。
但是，如果您选择平台无关的外观（这是今天的趋势），则不会以任何方式限制Codenameone默认组件集的设置：就像使用跨平台外观和感觉的Swing一样（“Metal”等）。这很好。
从语言方面来看：在iOS上，它是编译成C的Java，然后与手写的Objective-C绑定，并且不捆绑VM，只有可移植性层。这里最重要的是Java被编译成C而不是Objective-C，因此它比符合惯用法的Objective C代码更快，因为它执行虚拟或更频繁的直接方法调用，而不是缓慢的Objective C消息分发。这很好。
在Android上，它似乎也比较快，因为它使用Dalvik / Art，而不是CN1的庞大的Android本地UI。这可以使动态UI创建在运行时更快，这很好。
CN1方法最强大的一点是它的仿真器（在桌面JavaFX画布上实现），您可以使用它来开发软件。仿真器使用与移动平台上相同的UI代码和可移植性API，并允许您使用所选的IDE进行调试。它重新启动速度很快，编辑编译运行周期与Android相比非常可持续。这很好。
第二个非常强的点（主要！）是其UI库、所有本机代码和字节码到C翻译器的开放性质。如果您花费了一些精力，可以避免在他们的农场上构建Android / iOS端口，并从其产品的特定修订版本中解除自己的束缚（但无法脱离他们提供的不少价值增值服务，这些服务不是开源的！）。根据您的情况，这可能（或可能不会！）对您非常有利！
Codenameone的最大弱点是其成熟度不够理想，这意味着如果您将基本UI组件用于非预期方式，很容易出现问题。同时，它的Java可移植性层覆盖范围不够广泛（并且存在漏洞），不能满足所有人的需求，您可能需要在某些地方使用本机代码，并移植其他纯Java库。
此外，当前图形性能的状态不够优化；如果屏幕上有大量文本，您很容易错过16毫秒的流畅动画/重绘时间限制，可以通过双缓冲来解决，但也有其限制。幸运的是，在两个主要平台的实现中仍有优化的空间，希望他们会改善它。
总体而言，Codenameone作为跨平台框架在几类应用程序中具有优势；您也可能会发现他们的服务有价值。
