我已经开始玩 Appcelerator Hyperloop。虽然从零开始从 JS 访问本机 API 似乎很棒,但它确实引发了一些关于平台架构和性能的问题。
目前(AFAIK)一个 Titanium 应用程序有一个主 UI 线程(运行本机 UI 控制器)和一个 JS 线程(运行 JS 逻辑)。从 JS 到 Native 的每个调用都通过“Bridge”(这是应用程序中的扩展操作)传递。
此外,Titanium API 并没有尽可能多地涵盖所有本机 API 和抽象。但是,如果引入了新的 API,Appcelerator 可能需要一些时间才能将这些 API 实施到平台中。
我最喜欢 Titanium 的一件事是能够扩展它(iOS 使用 Objective-c,Android 使用 java)——允许使用 Titanium 未涵盖的本机 API,并开发真正的本机性能控件以防万一做任何对 JS 来说太“重”的事情。而且,如前所述,它是为每个平台开发的 100% 原生的。
现在 Appcelerator 引入了 Hyperloop,我做了一个简单的测试应用,发现 Hyperloop 没有被翻译成原生代码,而只是被翻译成普通的 JS 代码:
var UILabel = require('hyperloop/uikit/uilabel');
var label = new UILabel();
label.text = "HELLO WORLD!";
$.index.add(label);
另一件事是你必须在主线程上运行。
因此,就 Hyperloop 架构而言,我们基本上想到了一些事情:
- 我们还有桥吗?如果 Hyperloop 是调用“特殊”Hyperloop 要求的 JS,那么我们还有一个桥,它现在不仅充当桥,还需要进行某种反射(这也是一个扩展操作)?
- 到目前为止,JS 在它自己的线程中运行 - 所以现在在单个主线程中运行似乎是更多 UI 阻塞操作的潜在来源。
- 老式模块是真正的原生模块(不包括桥接调用)——那么启用 Hyperloop 的应用程序与那些相比如何?
目前还没有太多关于 Hyperloop 的文档或文章来解释内部工作 - 所以如果有人有任何答案一直在尝试使用它的应用程序可能会非常有帮助。