+49 40 608 12 460 (Development)
+49 175 5611694 (Kommunikation)

Einführung in Hyperloop

Appcelerator aus Mountain View arbeitet seit einigen Monaten an einer neuen Systemarchitektur für das mobile Crossplattformentwicklungssystem Titanium.

Dieses neue System nennt sich Hyperloop und ist mittlerweile als Beta verfügbar und soll hier vorgestellt werden .

Ti.Current (klassisches Titanium)

Das klassische Titanium (mittlerweile Ti.Current genannt) interpretiert zur Laufzeit der App auf dem Gerät den JS-Code des Projektes. Auf Android-getriebene Geräten übernimmt diese Aufgabe V8, auf den Applegeräten werkelt  der JavaScriptCore – auch Squirrelfish oder Nitro genannt.

In Zusammenspiel mit der Titanium-API werden zur Laufzeit aus dem prekompilierten JS-Code auf der nativen Plattform Objekte geschaffen. Da der JS-Namensraum jetzt Referenzen  auf diese nativen Objekte hält, kann von JS aus auf diese Objekte zugegriffen werden. Das heisst, es können weitere Properties zugefügt, Methoden aufgerufen und und Event empfangen werden.

Mehr als eine halbe Million Entwickler arbeiten mit dem Titanium-Entwicklungssystem und TitaniumApps laufen derzeit auf ca. 200 Mio. Telefonen. Dennoch gilt: „Gut ist der Feind von Besser“ – und so kann auch Titanium verbessert werden. Das Konzept hat drei Probleme:

  1. Die Titanium-API ist monolitisch. Das heisst bei Hinzufügung einer weiteren Plattform wie beispielsweise das Windows8-Phone treten keine Synergieeffekte auf. Die komplette API muss überarbeitet werden.
  2. Reicht die Titanium-API zur Realisierung einer Funktionalität  nicht aus, muss ein sogenanntes Modul geschrieben werden. Normalerweise gibt es schon eine Library in der nativen Welt. Dieses Modul programmiert dann die Brücke zwischen der Library und Javascript. Das ist zwar keien Hexerei, muss aber dennoch erledigt werden.
  3. Bei suboptimalem Programmierstil kann es zu Performanceverlusten kommen. Das betrifft insbesondere die Abarbeitung von Schleifen.

Paradigmenwechsel zu Hyperloop (Ti.Next)

Hyperloop ist ein Next-Generation-Compiler. Worin besteht der Paradigmenwechsel? Der JS-Code wird nicht mehr zur Laufzeit, sondern zur Kompilationszeit interpretiert und in nativen Code (Objectiv-C bzw. Java) überführt.

Zu diesem Zwecke wird der JS-Code um Komileranweisungen erweitert. Im Gegensatz zu Typescript oder Coffeescript wird also keine neue Syntax erdacht, sondern der gewohnte Javascript kann weiterverwendet werden. Dieser erweiterte JS-Dialekt wird  Hyperloop-JS genannt.  HJS fügt eine kleine Anzahl von Keywörter in den Code. Diese Kompileranweisungen steuert den JavaScript-Kompiler.

Nehmen wir dieses sehr einfach Beispiel aus der ObjectivC-Welt von iOS: 

@import("UIKit");
@import("CoreGraphics");
var view = new UIView();
view.frame = CGRectMake(0,0,100,100);

Der obige Code teilt dem Kompiler mit, dass er das UIKit-Framework einbinden  soll und die JS-Variablen in dem entsprechenden Namensraum auflösen soll. In diesem Fall ist UIView ein Interface, das in dem Objective-C UIKit-Framework definiert ist.

Dieses CGRectMake ist eine normale  C-Function  aus dem Framework CoreGraphics . Wie also leicht zu sehen ist, wird ganz  einfache JS-Syntax verwendet. Im Gegensatz zu „stinknormalem“ Javascript wird dieser Code vom Hyperloop-Kompiler direkt in ObjectivC übersetzt.

Architektur von Hyperloop

Wie viele Kompiler besteht auch Hyperloop aus zwei Teilen: Backend und Frontend. Das Frontend ist für das Parsen des HJS-Quellcodes verantwortlich. Es erzeugt einen Abstract Syntax Tree (AST) und führt auch einige Optimierungen durch. Das Backend wandelt dann dieses AST in den eigentlichen nativem Code um.

Das Frontend ist also plattformunabhängig. In der derzeitigen Entwicker-Preview wird ObjectivC für iOS unterstützt. Zur Zeit arbeitet Appcelerator an der Umsetzung für Android und WindowsPhone. Die jetzige Version ist noch experimentell und noch nicht für produktive Zwecke geeignet. Dennoch lohnt sich natürlich ein Blick in diese Richtung.

Was hat das mit Titanium zu tun?

Ein Nachteil des bisherigen Titaniums ist der hohe Aufwand seitens von Apppcelerator bei Erweiterung um neue Betriebssysteme (beispielsweise Windows). Deshalb hat Appcelerator folgerichtig beschlossen, eine neue Architektur zu bauen. Sie trennt das System in einen plattfomunabhängigen und einen plattformabhängigen Teil auf. Titanium wird also völlig umgestaltet und nennt sich Ti.Next . Der eigentliche Nutzeffekt ist nicht nur die bessere Skalierbarkeit über verschiedene Plattformen, sondern der Geschwindigkeitsgewinn zur Laufzeit, da nun nicht mehr JS-Code interpretiert wird.

Ein weiterer Vorteil der neuen Architektur besteht darin, dass man sich jetzt neue Funktionalitäten durch schieres Einbinden nativer Module erschließen kann. Das Thema „Entwicklung von Titaniummodulen“ gehört damit der Vergangenheit an. titanium wird dadurch wesentlich agiler und kann damit noch schneller auf Marktanforderungen reagieren. Hyperloop ist aber nicht an Titanium gebunden, sondern kann auch eigenständig eingesetzt werden.

Erste praktische Schritte (Hallo Welt!)

Hyperloop ist bislang nicht im Titanium-Studio integriert. Es gibt zwei Möglichkeiten dennoch mit Hyperloop zu starten:

  1. Arbeit auf der Kommandozeile (Shell)
  2. Hyperloop als Titaniummodul und Einbindung in das klassische Titanium

In diesem Artikel beschreiteten wir den ersten Weg.

Der zweite Weg über das Modul ist in dem Artikel Hyperloop als Modul in Ti.Current beschrieben.


Impressum