Appcelerator Hyperloop vs. Plain Titanium Modules

Question

Zacząłem grać z Appcelerator Hyperloop. Chociaż wydaje się, że dostęp do natywnych interfejsów API z JS jest świetny od dnia zerowego, powstaje kilka pytań dotyczących architektury platformy i wydajności.

Obecnie (AFAIK) aplikacja Titanium ma główny wątek UI (który uruchamia natywne kontrolery interfejsu użytkownika) oraz wątek JS (który uruchamia logikę JS). Każde wywołanie od JS do Native jest przekazywane za pomocą "Bridge" (co jest ekspansywną operacją w aplikacji).

Co więcej, Titanium API nie obejmuje wszystkich natywnych API i streszczeń, jak tylko może. Ale jeśli wprowadzimy nowe API, może to potrwać, zanim Appcelerator wdroży je na platformie.

Jedną z moich ulubionych rzeczy na temat Titanium jest możliwość jej rozszerzenia (za pomocą obiektywu c dla iOS i java dla Androida) - pozwalając na korzystanie z natywnych API, które nie są objęte tytanem, a także rozwijając bardzo natywne kontrole wydajności na wypadek, gdybyśmy musieli zrobić wszystko, co jest zbyt "ciężkie" dla JS. I, jak wspomniano, jest opracowany w 100% natywny dla każdej platformy.

Teraz Appcelerator wprowadzono Hyperloop Zrobiłem prostą aplikację testową i zobaczył, że Hyperloop nie przekłada się natywnego kodu, ale po prostu do normalnego kodu JS:

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

a inna rzeczą jest to, że masz uruchomić na głównym wątku.

Więc w zasadzie mieć kilka rzeczy przychodzą do głowy tutaj miarę Hyperloop architektura idzie:

1. Mamy jeszcze most? jeśli Hyperloop jest JS, który wymaga "specjalnego" Hyperloopa, to nadal mamy most, który teraz nie tylko działa jak most, ale także musi dokonać jakiegoś odbicia (który jest także ekspansywną operacją)?
2. Do tej pory JS działał w swoim wątku - więc teraz działa w jednym głównym wątku wydaje się być potencjalnym źródłem do większej blokowania interfejsu użytkownika.
3. Staroświeckie moduły były naprawdę natywne (bez mostkowania) - jak więc porównać aplikacje z Hyperloop?

Nie ma zbyt wiele dokumentacji i artykułów na temat Hyperloopa, które wyjaśniałyby wewnętrzną pracę - więc jeśli ktokolwiek ma jakieś odpowiedzi, próbował aplikacji z nim, może być bardzo pomocny.

Answer 1

Odpowiadając na pytania prosta:

1. Nie ma Kroll-proxy już zaangażowany, ponieważ rzeczywiste klasy są generowane na starcie. Odbywa się to za pomocą hiperloop-metabazy, która odzwierciedla (jak już wspomniano) budowanie AST, które pobiera rzeczywiste podpisy, typy, klasy, metody, właściwości itp.
2. Nie widzieliśmy żadnych problemów z wydajnością działa na głównej wątku na razie. Jeśli to zrobisz, złóż bilet JIRA, abyśmy mogli zbadać przypadek użycia.
3. Stare moduły były "mniej natywne" niż teraz, po prostu dlatego, że wszystkie były opakowane przez serwer proxy Kroll (przez rozszerzenie każdego widoku z TiUIView i każdego proxy od TiProxy/TiViewProxy. Hyperloop nie działa z tymi, czyniąc rozwój modułu jest o wiele szybszy, umożliwiając również programistom przetestowanie swojego procesu na żywo w aplikacji bez potrzeby pakowania i ręcznego tworzenia odwołania do modułu.Moduły Hyperloop to nic innego niż moduły CommonJS, które są już często używane w stopach i innych komponentach Ti.

Mam nadzieję, że daje to szybki przegląd tego, jak działa Hyperloop. Jeśli masz dodatkowe pytania, daj nam znać!

Hans

Answer 2

(jako szczegółowej odpowiedzi na powyższym komentarzu)

Więc powiedzmy masz tableview w iOS. Natywna klasa to UITableView, a Titanium-API to Ti.UI.TableView/Ti.UI.ListView.

Podczas gdy ListView zapewnia już znaczną poprawę wydajności w porównaniu do TableView przez abstrakcję użycia Child-API do szablonów, te API-child (Ti.UI.Label, Ti.UI.ImageView, ...) są nadal niestandardowymi klasami, które są zawijane i dostarczają niestandardowa logika (!) np śledzenie jego referencji rodziców, wewnętrznych struktur danych i blokad w celu przeskakiwania między wątkami.

Jeśli teraz sprawdzisz Hyperloop example natywnego UITableView, uzyskujesz bezpośredni dostęp do natywnych API, więc żadne proxy nie musi nimi zarządzać, szablony, elementy itp. Oczywiście dostarczamy to API za pośrednictwem proxy kroll w celu wyświetlaj go w Titanium, ale nie "przeskakuj między mostami" przy każdym wywołaniu z SDK.

Najprostszym sposobem, aby to zobaczyć, jest uruchomienie większego przykładu, takiego jak widok tabeli, widok kolekcji i animacja widoku. Jeśli wykonasz szybkie przewijanie, odczujesz już wzrost wydajności w porównaniu do "klasycznych" Titanium API, ponieważ jedyną komunikacją między twoim serwerem proxy a (takim jak Ti.UI.Window, do którego chcesz go dodać) jest .add() API typu HyperloopClass.

Nareszcie, oczywiście, nadal ma sens używanie na przykład Ti.UI.ListView, ponieważ zawiera wbudowane narzędzia, które Titanium devs love (zdarzenia, łatwa konfiguracja i obsługa układu). Ale także tam, gdzie pojawia się korzyść Hyperloop, umożliwiając programistom dostęp do samego API.

Mam nadzieję, że pomoże to nieco bardziej zrozumieć.