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价值。