Appcelerator Hyperloop与普通Titanium模块

Question

我开始玩Appcelerator Hyperloop了.虽然从第0天开始从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

直接回答你的问题:

由于实际的类是在运行时生成的,因此不再涉及Kroll-Proxies.这是通过使用反射(如您已经说过)构建一个AST来捕获实际签名,类型,类,方法,属性等的超级循环元数据库来完成的.
我们目前没有看到在主线程上运行的任何性能问题.如果您这样做,请提交JIRA票据,以便我们调查用例.
现在,旧模块"本土化程度较低",仅仅是因为它们全部由Kroll代理包装(通过扩展每个视图TiUIView和来自TiProxy/的每个代理TiViewProxy.Hyperloop不能与那些一起使用,使模块开发更快通过允许开发人员在他们的应用程序中实时测试他/她的流程,而无需手动打包和引用模块.Hyperloop模块只不过是合金和其他Ti组件中经常使用的CommonJS模块.

我希望能够让您快速了解Hyperloop的工作原理.如果您还有其他问题,请告诉我们!

汉斯