Appcelerator HyperloopとPlain Titaniumモジュール

Question

私はAppcelerator Hyperloopを使い始めました。 0日目からJSのネイティブAPIにアクセスすることは素晴らしいようですが、プラットフォームのアーキテクチャーとパフォーマンスについて、いくつか質問があります。

現在（AFAIK）Titaniumアプリケーションには、メインのUIスレッド（ネイティブUIコントローラを実行するスレッド）とJSスレッド（JSロジックを実行するスレッド）があります。 JSからNativeへの各呼び出しは、 "Bridge"（これはアプリの広範な操作です）を通過します。

また、Titanium APIはすべてのネイティブAPIと抄録を可能な限りカバーしていません。しかし、新しいAPIが導入されると、Appceleratorがそれらをプラットフォームに実装するのに時間がかかる可能性があります。

Titaniumに関する私の大好きなことの1つは、Titaniumで扱われないネイティブAPIを使用できるようにすること（iOSとJava用のobjective-cを使用して）を拡張する機能であり、 JSのためにあまりにも重いことをする必要がある場合に備えて。そして、前述のように、各プラットフォームで100％ネイティブに開発されています。今

は、Appceleratorのは、私は簡単なテストアプリをやったハイパーループを導入し、ハイパーループがネイティブコードにちょうど通常のJSコードに変換されていないことを見たこと：

var UILabel = require('hyperloop/uikit/uilabel'); 
var label = new UILabel(); 
label.text = "HELLO WORLD!"; 
$.index.add(label); 

、それについて別の事あなたが持っているということですメインスレッドで実行します。

だから我々は、基本的には、いくつかのことは限りハイパーループ・アーキテクチャが行くように、ここで心に来た：

1. 我々はまだ橋がありますか？ハイパーループが "特別な"ハイパーループを必要とするJSなら、まだブリッジを持っているだけでなく、ブリッジとして機能するだけでなく、何らかのリフレクション（拡張オペレーションでもあります）を行う必要がありますか？
2. これまではJSが独自のスレッドで実行されていました。つまり、1つのメインスレッドで実行すると、より多くのUIブロック操作の潜在的なソースになるようです。
3. 旧式のモジュールは本当にネイティブで（ブリッジコールは含まれていませんでした）、ハイパーループ対応のアプリケーションとそれらのアプリケーションとの比較はどのようになっていますか？

にはまだ内部の作業を説明ハイパーループについて多くのドキュメントや記事はありません - 誰もが何らかの答えを持っている場合、それにアプリケーションをしようとしていることは非常に役に立つことができそう。ストレートなご質問に答える

Answer 1

：

1. 実際のクラスは、実行時に生成されているので、何のクロール・プロキシは、もはや関与はありません。これは、実際のシグネチャ、タイプ、クラス、メソッド、プロパティなどを取得するASTを構築するために、リフレクションを行うハイパーループメタベースを使用して行われます。
2. パフォーマンスに関する問題はありませんでした。今のところメインスレッドで走っています。その場合は、ユースケースを調べるためにJIRAチケットを提出してください。
3. これまでのKrollプロキシですべてのラップが処理されていたため、古いモジュールは「ネイティブではありませんでした」（TiUIViewおよびすべてのプロキシをTiProxy/TiViewProxyから拡張しています。開発者がモジュールを手作業でパッケージ化して参照する必要なく、自分のプロセスを自分のアプリでテストできるようにすることで、モジュール開発をより迅速に行うことができます。ハイパーループモジュールは、合金や他のTi部品で頻繁に使用されているCommonJSモジュールです。

HyperClopの仕組みについて簡単にご紹介します。さらなるご質問がある場合は、お知らせください。

ハンス

（上記のコメントに詳細な回答として）

Answer 2

それでは、あなたがiOS版でテーブルビューを持っているとしましょう。ネイティブクラスはUITableViewで、チタンAPIはTi.UI.TableView/Ti.UI.ListViewです。

ListViewは、Child-APIの使用方法をテンプレートに抽象化することによって、TableViewと比較して既に大幅なパフォーマンス向上を実現していますが、それらの子API（Ti.UI.Label、Ti.UI.ImageView、...）はラップされ、カスタムロジック（！）親参照、内部データ構造、スレッド間のジャンプをロックしています。

ネイティブUITableViewのHyperloop exampleを確認した場合は、ネイティブAPIに直接アクセスするため、セクション、テンプレート、アイテムなどを管理するプロキシはありません。もちろん、そのAPIをkrollプロキシ経由で配信しますそれをTitaniumに表示しますが、SDKから呼び出すたびに "ブリッジ間をジャンプ"しないでください。

実際には、tableview、collectionview、view-animationのような大きな例を実際に実行するのが最も簡単な方法です。これらを高速にスクロールすると、プロキシと（たとえばTi.UI.Windowを追加したい）唯一の通信がネイティブを受け取るための.add()であるため、従来の「Titanium API」に比べてパフォーマンスが向上していますAPIタイプはHyperloopClassです。

最後に、もちろん、Ti.UI.ListViewは、Titanium開発者が愛用する組み込みユーティリティ（イベント、簡単な設定、レイアウト処理）が付属しているので意味があります。しかし、開発者がこれらのAPIにアクセスできるようにすることで、Hyperloopの利点が生まれる場所もそうです。

もう少し理解していただければ幸いです。