Codename One如何工作？
我正在寻找替代多种移动平台的开发方法，并且发现Codename One ，它使用Java作为通用语言 ，而不是HTML / CSS / JS或脚本语言。
我找不到的是它是如何工作的。 它是否将JVM与iOS和Win7的应用程序捆绑在一起，并在Android中使用Dalvik？ 它是否将源代码转换为本地代码，并且我们是否可以访问此源代码？ 有没有其他的魔法，考虑到他们承诺“不妥协”？ 在编写不可知的Java代码时应该注意哪些限制？
先发制人：这是一个关于Codename One的问题， 而不是我应该select哪个跨平台，或者我应该去哪里，或者如果我应该去networking。
Codename One使用基于SaaS的方法，所以这可能（也可能会）将来改变以适应改进的体系结构。 请注意，Codename One还提供了离线构build选项，这意味着具有禁止这种云架构的策略的企业仍然可以使用Codename One，但会带来一些额外的开销/复杂性。
目前在Android上，标准Java代码是按原样执行的。 在使用Java 8语法时，所有平台都使用retrolambda进行翻译。 这使得它可以兼容所有Android版本以及其他端口。
iOS上的代号一个内置的开源ParparVM ，这是一个非常保守的虚拟机。 ParparVM具有并发（非阻塞）GC，并且完全用Java / C编写。 这实际上意味着xcode项目在构build服务器上生成并编译，因此它的效果就好像您手动编写本机应用程序一样，因此对于Apple所做的更改提供了“未来certificate”。 例如，最近对iOS版本的64位和位码更改ParparVM不需要修改来遵守这些更改。
过去，Codename一个使用XMLVM以非常相似的方式生成本地代码，但是XMLVM解决scheme对于Codename One的需求来说过于通用。
iOS版本是使用xcode（官方Apple构build工具）在云中的Mac上进行编译和签名的。 这使得它们与苹果当前/未来的变化兼容，并允许开发人员在面向iOS的情况下使用Windows / Linux。 您可以在这里阅读更多关于ParparVM与iOS兼容的信息 。
在过去的代码名称一个支持的Windows Phone使用C＃翻译器依赖于XMLVM，但它不是一个理想的方法。 请注意，转换为C＃的XMLVM后端与之前用于转换为iOS的后端非常不同。 Codename Oneselect停止旧的后端，因为它不像新的UWP后端那样强大，并且不符合微软目标前进的重点是UWP（通用Windows平台） 。
对于Windows 10桌面和移动支持，Codename One使用iKVM来定位UWP（通用Windows平台），并且已经将Codename One github存储库中的原始iKVM代码更改为开放源代码。
请注意，UWP构build是在云中的Windows 10机器上完成的，因此开发人员在构build本地Windows应用程序时可以使用Mac / Linux或较旧版本的Windows。
在企业级用户可用的JavaScript构build目标使用TeaVM静态地进行翻译。 TeaVM通过以相当复杂的方式打破应用程序，为使用JavaScript的线程提供支持。 为了支持复杂的UI Codename One，使用了HTML5 Canvas API，它可以为构build应用程序提供绝对的灵活性。
对于桌面构buildCodename One使用javafxpackager ，因为Mac和Windows机器都可以在云中使用，所以javafxpackager的平台特定性质不成问题。
使得Codename One脱颖而出的方法就是使用UI的方式，使用“轻量级架构”来让UI在所有平台上无缝工作，并几乎完全用Java开发。 它通过在“轻量级”之间embedded“重量级”小部件的能力而得到增强。 您可以在此博客文章中了解更多。 请注意，此时， 对等正在进行一些改进 ，现在支持更复杂的用法，如分层。
一个轻量级组件是完全用Java编写的，这允许开发人员在模拟器和GUI构build器中准确地预览应用程序。
Codename One通过使用大多数平台的本地游戏API进行绘图，例如iOS上的OpenGL ES，可以实现快速的性能。
Codename One背后的核心技术都是开源的，包括Codename One本身开发的大部分工具 ，例如ParparVM ，还有完整的库，平台端口，devise工具 ， 设备外观等。您可以在这里了解更多关于使用Codename One源代码的信息 。
FYI Shai Almog，这个答案的作者，是Codename One的首席执行官。
Codename对可移植性采取了非常均衡的方法。 我想添加一个实用的评论。
从用户界面方面看，CN1在平台提供的canvas上绘制了所有的UI。 它试图模仿平台原生的外观和感觉，如果你select它，但是与Swing“原生平台外观和感觉”一样成功，因为本地平台不断变化，而“本地I＆F”总是缺乏和最案件感觉不太对。
但是，如果您select与平台无关的外观和感觉（这是今天的趋势），那么您不受Codenameone的默认组件集合的任何限制：它就像Swing具有跨平台的外观和感觉（“金属“等）。 哪个好。
从语言方面来说：在iOS上，java编译为C，然后绑定到手写的Objective-C，而不是绑定虚拟机，只绑定可移植性层。 这里最重要的事实是，java被编译为C而不是Objective-C，这使得它更快，然后使用惯用的Objective-C代码，因为它实际上是虚拟的，或者更常见的是直接方法调用，而不是缓慢的Objective C消息调度。 哪个好。
在Android上它也可能看起来好一点，因为在使用Dalvik / Art的时候，它并不使用比CN1更笨重的Android原生UI。 这可以使运行时更快地创builddynamicUI，这很好。
CN1方法的最强点之一是它的模拟器（通过桌面JavaFXcanvas实现），用于开发软件。 仿真器使用与移动平台上相同的UI代码和可移植性API，并允许您使用IDE进行debugging。 它很快重启，编辑 – 运行循环相对于android来说是非常可持续的。 哪个好。
第二个非常强大的（主要的！）是他们的UI库的开放性，所有的本地代码和字节码到C的翻译器。 如果你花费一些努力，你可以避免在他们的农场build立Android / iOS端口，并解除自己对产品的特定修改版本（但不是来自它提供的一些非开源的增值服务）。 根据你的情况，这可能会（或可能不会）对你很好！
Codenameone的弱点在于它不太理想的成熟度，这意味着你可以使用基本的用户界面组件轻松地拍摄自己的脚，如果你使用它们的方式不被使用。 而且这意味着它的Java可移植性层不够大（并且存在漏洞）以满足每个人的需求，而且您可能必须在某些地方使用本机，并移植其他纯Java库。
而且，graphics性能的当前状态是次优的; 如果你在屏幕上看到一堆文字，你很容易就会错过16毫秒的stream体animation/重绘时间限制，这可以通过双缓冲来解决，但也有其局限性。 幸运的是，在两个主要平台上仍然有优化实施的空间，希望能够改善。
总体而言，Codenameone作为多个应用程序类的跨平台框架具有良好的利基; 你也可以在他们的服务中find价值。
