我正在寻找为多个移动平台开发的替代方案，并找到了Codename One，它使用 Java 作为lingua franca，而不是 HTML/CSS/JS 或脚本语言。
我找不到的是它是如何工作的。它是否将 JVM 与 iOS 和 Win7 的应用程序捆绑在一起，并在 Android 中使用 Dalvik？它是否将源代码翻译为本地代码，我们是否可以访问此源代码？考虑到他们承诺“不妥协”，还有其他魔法吗？在编写不可知的 Java 时，我应该注意哪些限制？
先发制人：这是一个关于 Codename One 的问题，而不是关于我应该选择哪个跨平台，或者我应该使用原生还是使用 Web。
Codename One有一种可选的 SaaS 方法，因此这可能（并且可能会）在未来发生变化以适应改进的架构。请注意，Codename One 还提供了离线构建的选项，这意味着有政策禁止此类云架构的公司仍然可以使用 Codename One，但会带来一些额外的开销/复杂性。这也意味着您可以免费使用它，而无需使用构建服务器。
目前在 Android 上，标准 Java 代码按原样执行。Java 8 语法在使用时使用所有平台的 retrolambda 进行翻译。这允许它与所有 Android 版本以及其他端口兼容。
在 iOS Codename One 上构建并开源ParparVM，这是一个非常保守的 VM。ParparVM具有并发（非阻塞）GC，它完全用 Java/C 编写。这实际上意味着在构建服务器上生成并编译了一个 xcode 项目，因此它就像您手动编写一个原生应用程序一样有效，因此可以为 Apple 所做的更改提供“未来证明”。例如，最近对 iOS 构建的 64 位和位码更改，ParparVM 无需修改即可符合这些更改。
过去 Codename One 使用XMLVM以非常相似的方式生成本机代码，但 XMLVM 解决方案对于 Codename One 的需求来说过于通用。
iOS 构建使用 xcode（Apple 官方构建工具）在云中的 Mac 上编译和签名。这使它们与 Apple 当前/未来的更改兼容，并允许开发人员在针对 iOS 的同时使用 Windows/Linux。您可以在此处阅读有关 ParparVM 与 iOS 兼容性的更多信息。
过去 Codename One 使用依赖 XMLVM 的 C# 翻译器支持 Windows Phone，但这不是一种理想的方法。请注意，转换为 C# 的 XMLVM 后端与以前用于转换为 iOS 的后端非常不同。Codename One 选择停止使用旧后端，因为它不如新的 UWP 后端强大，并且不符合微软向前发展和专注于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，它为构建应用程序提供了绝对的灵活性。
对于 Codename One 使用的桌面构建javafxpackager，因为 Mac 和 Windows 机器都可以在云中使用，平台特定的性质javafxpackager不是问题。
Codename One 的突出之处在于它采用“轻量级架构”的 UI 方法，使 UI 可以在所有平台上无缝工作，并且几乎完全用 Java 开发。它通过在“轻量级”中嵌入“重量级”小部件的能力得到增强。您可以在此博客文章中了解更多信息。请注意，此时对等互连正在经历一些改进，现在支持更复杂的用法，例如分层。
轻量级组件完全用 Java 编写，这允许开发人员在模拟器和 GUI 构建器中准确预览应用程序。
Codename One 通过使用大多数平台的原生游戏 API（例如 iOS 上的 OpenGL ES）进行绘图来实现快速性能。
Codename One 背后的核心技术都是开源的，包括 Codename One 自己开发的大部分东西，例如ParparVM，还有完整的库、平台端口、设计器工具、设备皮肤等。您可以在此处了解有关使用 Codename One 资源的更多信息。
仅供参考，此答案的作者 Shai Almog 是 Codename One 的首席执行官。
代号一采用了非常平衡的可移植性方法。我想补充一句务实的评论。
从用户界面方面来看，CN1 确实在平台提供的画布上绘制了它的所有 UI。如果您选择它，它会尝试模仿平台原生的外观和感觉，但它的“原生平台外观和感觉”与 Swing 一样成功，因为原生平台不断变化，而“原生 l&f”总是落后于大多数案例感觉不太对。
但是，如果您选择独立于平台的外观和感觉（这是当今的一种趋势），您就不会受到 Codenameone 的默认组件集的任何限制：它就像具有跨平台外观和感觉的 Swing（"金属”等）。哪个好。
从语言方面：在 iOS 上，它是 java 编译成 C，然后绑定到手写的 Objective-C，它不捆绑 VM，只捆绑可移植层。这里最重要的是，java 被编译为 C 而不是 Objective-C，这使得它比惯用的 Objective-C 代码更快，因为它执行虚拟或更常见的是直接方法调用，而不是缓慢的 Objective C 消息分发。哪个好。
在 Android 上它也可能看起来快一点，因为在使用 Dalvik/Art 时，它不使用与 CN1 相比笨重的 Android 原生 UI。这可以在运行时更快地创建动态 UI，这很好。
CN1 方法的最强点之一是它的模拟器（在桌面 JavaFX 画布上实现），您可以使用它来开发软件。Emulator 使用与移动平台上相同的 UI 代码和可移植性 API，并允许您使用首选的 IDE 进行调试。它重启很快，与android相比，edit-compile-run循环非常可持续。哪个好。
第二个非常强的地方（主要的！）是他们的 UI 库、所有本地代码和字节码到 C 转换器的开放性。如果您花一些精力，您可以避免在他们的农场上构建 Android/iOS 端口，并从他们特定的产品版本中解脱出来（但不是从他们提供的许多增值服务中解脱出来，这些服务不是开源的！）。根据您的情况，这可能（也可能不会！）对您有好处！
Codenameone 的弱点在于其不够理想的成熟度，这意味着如果您以不打算使用它们的方式使用它们，那么您可以使用基本的 UI 组件轻松地击中自己的脚。也意味着它的java可移植层不够大（并且有漏洞）来满足每个人的需求，你可能不得不在某些地方使用native，并且还要移植其他纯java库。
此外，图形性能的当前状态是次优的；如果你在屏幕上看到一堆文本，你很容易错过 16 毫秒的流体动画/重绘时间限制，这可以通过双缓冲来解决，但它也有它的限制。幸运的是，两个主要平台上的实现仍有优化空间，希望他们能改进它。
总体而言，Codenameone 作为多类应用程序的跨平台框架具有很好的优势。您也可以在他们的服务中找到价值。