我正在探索为多个移动平台开发的替代方案，并找到Codename One，它使用Java作为通用语言，而不是HTML / CSS / JS或脚本语言。
我找不到的是它是如何工作的。它是否将JVM与iOS和Win7的应用程序捆绑在一起，并在Android中使用Dalvik？它是否将源代码转换为本机代码，我们是否可以访问此源代码？还有其他魔法，考虑到他们承诺“不妥协”吗？编码不可知的Java时我应该注意哪些限制？
抢先罢工：这是一个关于Codename One的问题，不我应该选择哪个跨平台，或者我应该去当地还是应该上网。
答案 0 :(得分：71)
Codename One使用基于SaaS的方法，因此将来可能（并且可能会）更改以适应改进的体系结构。请注意，Codename One还为build offline提供了一个选项，这意味着拥有禁止此类云架构的策略的公司仍然可以使用带有一些额外开销/复杂性的Codename One。
目前在Android上，标准Java代码按原样执行。当使用后，所有平台都使用retrolambda翻译Java 8语法。这使它可以兼容所有Android版本以及其他端口。
在iOS Codename One内置和放大器开源ParparVM这是一个非常保守的VM。 ParparVM具有并发（非阻塞）GC，它完全用Java / C编写。这实际上意味着在构建服务器上生成和编译xcode项目，因此它就像您手动编码本机应用程序一样有效，因此可以“进一步证明”Apple所做的更改。例如。随着最近对iOS构建的64位和bitcode更改，ParparVM无需修改即可遵守这些更改。
在过去，Codename One使用XMLVM以非常类似的方式生成本机代码，但XMLVM解决方案对于Codename One的需求来说过于通用。
使用xcode（官方Apple构建工具）在云端的Mac上编译和签署iOS版本。这使它们与Apple当前/未来的变化兼容，并允许开发人员在定位iOS时使用Windows / Linux。您可以阅读有关ParparVM与iOS here的兼容性的更多信息。
过去，Codename One使用依赖XMLVM的C＃转换器支持Windows Phone，但这不是一种理想的方法。请注意，转换为C＃的XMLVM后端与以前用于转换为iOS的后端非常不同。 Codename One选择了discontinue that old backend，因为它不像新的UWP后端那样强大，并且不能与微软目标相提并论，并且专注于UWP (Universal Windows Platform)。
对于Windows 10桌面和移动支持，Codename One使用iKVM target UWP (Universal Windows Platform)并已开放Codename One github repository中对原始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开发。它通过在“轻量级”中嵌入“重量级”小部件的能力得到增强。您可以在此blog post中详细了解相关信息。请注意，此时peering is undergoing some improvements现在支持更精细的用法，例如分层。
轻量级组件完全用Java编写，这使开发人员能够在模拟器和计算机中准确地预览应用程序。 GUI构建器。
Codename One通过使用大多数平台的原生游戏API进行绘制，从而实现快速性能，例如： iOS上的OpenGL ES。
Codename One背后的核心技术都是开源的，包括由Codename One自身开发的大部分内容，例如： ParparVM以及full library, platform ports, designer tool，device skins等。您可以详细了解如何使用Codename One来源here。
FYI Shai Almog，这个答案的作者，是Codename One的首席执行官。
答案 1 :(得分：9)
Codename采用非常均衡的便携性方法。我想补充一个实用的评论。
从用户界面来看，CN1会在平台提供的画布上绘制其所有UI。它试图模仿平台原生的外观和感觉，如果你选择它，但与Swing的原生平台外观和感觉一样有成功，因为原生平台不断变化，并且本土平台L＆安培; F＆＃34;总是缺乏背后，在大多数情况下感觉不太正确。
但是，如果您选择与平台无关的外观（这是当今的趋势），您不受任何方式的Codenameone默认组件集限制：它就像Swing具有跨平台的外观（＆＃34; Metal＆＃34;等）。哪个好。
从语言方面来说：在iOS上，它被java编译为C，然后绑定到手写的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作为几类应用程序的跨平台框架具有良好的市场空间;你也可以在他们的服务中找到一个价值。