Question

我开始玩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是JS，称为“特殊”Hyperloop需要，那么我们仍然有一个桥梁，现在不仅可以作为一个桥梁，还需要做某种反射（这也是一个扩展的操作）？
直到现在JS运行它自己的线程 - 所以现在在单个主线程中运行似乎是更多UI阻塞操作的潜在来源。
老式模块是真正原生的（不包括桥接调用） - 那么启用Hyperloop的应用程序与那些应用程序相比如何呢？

没有太多关于Hyperloop的文档或文章可以解释内部工作 - 所以如果有人有任何答案一直在尝试使用它可能会非常有帮助。

Answer 1

（作为对上述评论的详细解答）

因此，假设你在iOS中有一个tableview。本机类为UITableView，Titanium-API为Ti.UI.TableView / Ti.UI.ListView。

虽然通过将Child-API用法抽象为模板，ListView已经提供了与TableView相比的巨大性能提升，但那些子API（Ti.UI.Label，Ti.UI.ImageView，...）仍然是包装的自定义类并提供自定义逻辑（！），例如跟踪它的父引用，内部数据结构和锁在线程之间跳转。

如果您现在查看原生UITableView的{{3}}，则直接访问本机API，因此其背后的代理不需要管理部分，模板，项目等。当然，我们提供该API通过kroll代理以便在Titanium中显示它，但是你不会在每次从SDK中调用时“在桥之间跳转”。

最简单的方法是实际运行一些更大的例子，如tableview，collectionview和view-animation。如果你快速滚动这些，你已经感觉到与“经典”Titanium API相比性能的提升，只是因为你的代理与你想要添加它的Ti.UI.Window之间的唯一通信是{ {1}}以接收.add()类型的本机API。

最后，当然使用HyperloopClass仍然有意义，因为它带有Titanium开发人员喜爱的内置实用程序（事件，简单配置和布局处理）。但这也是Hyperloop带来好处的地方，允许开发人员自己访问这些API。

我希望这有助于理解它。

Appcelerator Hyperloop与普通Titanium模块

1 个答案: