我已经开始玩Appcelerator Hyperloop。从零开始就可以从JS访问本机API似乎很不错，但这确实引起了有关平台架构和性能的一些问题。
当前（AFAIK）Titanium应用程序具有一个主UI线程（运行本机UI控制器）和一个JS线程（运行JS逻辑）。从JS到Native的每次调用都通过“ Bridge”（这是应用程序中的扩展操作）传递。
此外，Titanium API并未涵盖所有本机API和摘要。但是，如果引入了新的API，Appcelerator可能需要一些时间才能将其实现到平台中。
我对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的文档或文章来解释其内部工作原理-因此，如果有人有任何答案，尝试使用它可能会很有帮助。
最佳答案
直接回答您的问题：
由于实际的类是在运行时生成的，因此不再涉及Kroll-Proxies。这是通过使用进行反射（如您已经说过的）的hyperloop-metabase来构建的，以获取实际的签名，类型，类，方法，属性等的AST。
目前，在主线程上运行没有发现任何性能问题。如果这样做，请提交JIRA机票，以便我们调查用例。
那时，旧模块现在“本地化程度较低”，这仅仅是因为它们全部由Kroll-proxy封装（通过扩展TiUIView中的每个视图和TiProxy / TiViewProxy中的每个代理）。Hyperloop不适用于那些模块，还允许开发人员在自己的应用程序中实时测试其过程，而无需手动打包和引用该模块，从而使模块的开发速度大大提高。Hyperloop模块只不过是Alloy上已经经常使用的CommonJS模块而已和其他钛成分。
我希望可以让您快速了解Hyperloop的工作原理。如果您还有其他问题，请告诉我们！
汉斯