Der Betriebskontext und die physischen Merkmale von mobilen Geräten erfordern sorgfältige Planung und Programmierung. So ist es zum Beispiel entscheidend, den Code effizient zu schreiben, damit er so schnell wie möglich ausgeführt werden kann. Auch die Codeoptimierung hat natürlich ihre Grenzen; ein intelligenter Entwurf, der innerhalb der Gerätegrenzen funktioniert, trägt auch dazu bei, dass die visuelle Umsetzung nicht das Renderingsystem überfordert.
Code
Code so zu schreiben, dass er schneller ausgeführt ist, hat immer Vorteile; die langsamere Prozessorgeschwindigkeit der meisten mobilen Geräte erhöht noch den Nutzen von „schlankem“ Programmcode. Dazu kommt noch, das mobile Geräte so gut wie immer im Akkubetrieb laufen. Dasselbe Ziel mit weniger Rechenarbeit zu erreichen schont auch den Akku.
Design
Faktoren wie der kleinere Bildschirm, die Interaktion über einen Touchscreen und sogar die ständig wechselnde Umgebung, in der sich Benutzer von mobilen Geräten bewegen, dürfen beim Entwerfen der Bedienung Ihrer Anwendung nicht vernachlässigt werden.
Code und Design
Werden in Ihrer Anwendung Animationen eingesetzt, ist die Optimierung des Renderings von großer Bedeutung. Die Codeoptimierung allein reicht häufig jedoch nicht aus. Sie müssen die visuellen Aspekte der Anwendung so entwerfen, dass der Code sie effizient darstellen kann.
Wichtige Optimierungstechniken werden im Handbuch
Leistungsoptimierung für die Flash-Plattform
vorgestellt. Die in diesem Handbuch beschriebenen Verfahren gelten für alle Flash- und AIR-Inhalte, sind jedoch besonders wichtig bei der Entwicklung von Anwendungen für mobile Geräte.
Lebenszyklus von Anwendungen
Wenn Ihre Anwendung den Fokus an eine anderen App verliert, verringert AIR die Bildrate auf 4 fps und stoppt das Rendern von Grafiken. Bei noch geringeren Bildraten werden Streaming-Netzwerk- und Socket-Verbindungen leicht getrennt. Wenn Ihre App keine solchen Verbindungen verwenden, können Sie Bildrate sogar noch weiter drosseln.
Gegebenenfalls sollten Sie die Audiowiedergabe beenden und Listener für die Ortungs- und Beschleunigungssensoren entfernen. Das AIR-Objekt „NativeApplication“ setzt activate- und deactivate-Ereignisse ab. Mit diesen Ereignissen können Sie den Übergang zwischen dem aktiven Status und dem Hintergrundstatus verwalten.
Die meisten mobilen Betriebssysteme beenden Hintergrundanwendungen ohne Warnung. Durch häufiges Speichern des Anwendungsstatus sollte Ihre Anwendung in der Lage sein, einen akzeptablen Status wiederherzustellen, wenn sie aus dem Hintergrund aktiviert oder neu gestartet wird.
Informationsdichte
Die reale Bildschirmgröße ist bei mobilen Geräte kleiner als bei Desktops, die Pixeldichte (Pixel pro Zoll) ist jedoch höher. Dieselbe Schriftgröße erzeugt auf einem mobilen Gerät Buchstaben, die physisch kleiner als sind als auf einem Desktopcomputer. Deshalb müssen Sie häufig eine größere Schrift verwenden, um die Lesbarkeit zu gewährleisten. Im Allgemeinen ist die kleinste gut lesbar Schriftgröße 14 Punkt.
Mobile Geräte werden häufig unterwegs und bei schlechten Lichtverhältnissen verwendet. Bedenken Sie, wie viele Informationen realistischerweise lesbar auf dem Bildschirm angezeigt werden können. Dies kann weniger sein, als Sie auf einem Bildschirm mit den gleichen Pixelabmessungen auf einem Desktop anzeigen können.
Denken Sie auch daran, dass ein Teil des Bildschirms vom Finger und der Hand des Benutzer verdeckt wird, wenn er den Touchscreen bedient. Platzieren Sie interaktive Elemente an den Seiten und am unteren Rand des Bildschirms, wenn der Benutzer länger als für ein kurzes Tippen damit arbeiten muss.
Texteingabe
Viele Geräte verwenden eine virtuelle Tastatur für die Texteingabe. Virtuelle Tastaturen verdecken einen Teil des Bildschirms und sind manchmal umständlich zu bedienen. Vermeiden Sie es, sich auf Tastaturereignisse zu verlassen (ausgenommen Softkeys).
Ziehen Sie die Implementierung von Alternativen zu Texteingabefeldern in Betracht. Wenn Benutzer zum Beispiel einen numerischen Wert eingeben sollen, brauchen Sie kein Textfeld. Sie können einfach zwei Schaltflächen zum Erhöhen oder Verringern des Werts bereitstellen.
Softkeys
Mobile Geräte verfügen über eine unterschiedliche Anzahl Softkeys. Softkeys sind programmierbare Taste, die verschiedene Funktionen haben können. Halten Sie sich in Ihrer Anwendung an die Konventionen der jeweiligen Plattform.
Änderungen der Bildschirmausrichtung
Mobile Inhalte lassen sich im Hochformat oder im Querformat betrachten. Bedenken Sie, wie Ihre Anwendung mit Änderungen der Bildschirmausrichtung umgeht. Weitere Informationen finden Sie unter
Bühnenausrichtung
.
Bildschirm-Dimmen
AIR verhindert nicht automatisch das Dimmen des Bildschirms, während ein Video abgespielt wird. Verwenden Sie die
systemIdleMode
-Eigenschaft des AIR-Objekts „NativeApplication“, um zu steuern, ob das Gerät in einen Energiesparmodus wechselt. (Bei einigen Plattformen müssen Sie die entsprechenden Berechtigungen anfordern, um diese Funktion zu verwenden.)
Ankommende Telefonanrufe
Die AIR-Laufzeitumgebung schaltet das Audio einer Anwendung automatisch stumm, wenn der Benutzer einen Anruf tätigt oder empfängt. Für Android sollten Sie die Android-Berechtigung READ_PHONE_STATE im Anwendungsdeskriptor festlegen, wenn Ihre Anwendung Audio abspielt, während sie sich im Hintergrund befindet. Andernfalls verhindert Android, dass die Laufzeitumgebung Anrufe erkennt und das Audio automatisch stummschaltet. Siehe
Android-Berechtigungen
.
Kollisionsbereiche
Überlegen Sie beim Entwerfen von Schaltflächen und anderen Elementen der Benutzeroberfläche, auf die der Benutzer tippt, wie groß der Kollisionsbereich (das Bedienziel) sein muss (dies ist der Bereich, den der Benutzer treffen muss, um die Schaltfläche zu aktivieren). Gestalten Sie diese Elemente groß genug, dass sie auf dem Touchscreen problemlos mit einem Finger bedient werden können. Achten Sie auch darauf, zwischen den Kollisionsbereichen genügend Platz zu lassen. Der Kollisionsbereich sollte bei einem typischen High-DPI-Display ungefähr 44 bis 57 Pixel auf jeder Seite betragen.
Installationsgröße des Anwendungspakets
Auf mobilen Geräten steht sehr viel weniger Speicherplatz für die Installation von Anwendungen und für Daten zur Verfügung als auf Desktopcomputern. Minimieren Sie die Paketgröße, indem Sie nicht verwendete Bestände und Bibliotheken entfernen.
Unter Android wird das Anwendungspaket nicht in separate Dateien extrahiert, wenn eine App installiert wird. Stattdessen werden Beständen in den temporären Speicher extrahiert, wo auf sie zugegriffen werden kann. Um den Speicherverbrauch dieser komprimierten Bestände zu minimieren, schließen Sie die Datei- und URL-Streams, nachdem die Bestände vollständig geladen wurden.
Zugriff auf das Dateisystem
In den unterschiedlichen Betriebssystemen für mobile Geräte gelten unterschiedliche Dateisystemeinschränkungen und diese Einschränkungen unterscheiden sich von denen der Desktopbetriebssysteme. Der richtige Ort zum Speichern von Dateien und Daten variiert deshalb von Plattform zu Plattform.
Eine Folge der unterschiedlichen Dateisysteme ist, dass die Verknüpfungen zu gemeinsamen Verzeichnissen, die von der AIR File-Klasse bereitgestellt werden, nicht immer verfügbar sind. In der folgenden Tabelle ist zu sehen, welche Verknüpfungen unter Android und iOS verwendet werden können:
|
Android
|
iOS
|
File.applicationDirectory
|
Schreibgeschützt über URL (kein nativer Pfad)
|
Schreibgeschützt
|
File.applicationStorageDirectory
|
Verfügbar
|
Verfügbar
|
File.cacheDirectory
|
Verfügbar
|
Verfügbar
|
File.desktopDirectory
|
Stammverzeichnis der SD-Karte
|
Nicht verfügbar
|
File.documentsDirectory
|
Stammverzeichnis der SD-Karte
|
Verfügbar
|
File.userDirectory
|
Stammverzeichnis der SD-Karte
|
Nicht verfügbar
|
File.createTempDirectory()
|
Verfügbar
|
Verfügbar
|
File.createTempFile()
|
Verfügbar
|
Verfügbar
|
Die Richtlinien von Apple für iOS-Anwendungen bietet spezifische Regeln zu Speicherorten für Dateien in unterschiedlichen Situationen. Eine Richtlinie legt etwa fest, dass nur Dateien mit benutzerdefinierten Daten bzw. mit Daten, die nicht neu generiert oder herunterladen werden können, in einem Verzeichnis gespeichert werden sollen, das für die Remote-Sicherung vorgesehen ist. Informationen zum Einhalten der Richtlinien von Apple für die Dateisicherung und -zwischenspeicherung finden Sie unter
Steuern der Dateisicherung und -zwischenspeicherung
.
UI-Komponenten
Adobe hat eine für mobile Geräte optimierte Version des Flex-Frameworks entwickelt. Weitere Informationen finden Sie unter
Entwickeln von Mobilanwendungen mit Flex und Flash Builder
.
Es sind auch Community-Komponentenprojekte verfügbar, die sich für mobile Anwendungen eignen. Dazu gehört Folgendes:
Beschleunigtes Grafikrendering mit Stage 3D
Ab AIR Version 3.2 unterstützt AIR für Mobilgeräte das beschleunigte Stage-3D-Grafikrendern. Die
Stage3D
-ActionScript-APIs sind mehrere GPU-beschleunigte APIs niedriger Ebene, die erweiterte 2D- und 3D-Fähigkeiten ermöglichen. Diese APIs auf niedriger Ebene geben Entwicklern die Flexibilität, die GPU-Hardwarebeschleunigung zu nutzen, um deutliche Leistungsverbesserungen zu erzielen. Sie können auch Gaming-Engines verwenden, die die Stage3D-ActionScript-APIs unterstützen.
Weitere Informationen finden Sie unter
Gaming engines, 3D, and Stage 3D
.
Videoglättung
Um die Leistung zu verbessern, wird Videoglättung auf AIR deaktiviert.
Native Funktionen
Viele mobile Plattformen stellen Funktionen bereit, auf die mit der standardmäßigen AIR-API noch nicht zugegriffen werden kann. Beginnend mit AIR 3, können Sie AIR mit eigenen nativen Codebibliotheken erweitern. Diese nativen Erweiterungsbibliotheken können auf Funktionen zugreifen, die vom Betriebssystem bereitgestellt werden oder sogar für ein bestimmtes Gerät spezifisch sind. Native Erweiterungen können unter iOS in C und unter Android in Java oder C geschrieben werden. Informationen zum Entwickeln von nativen Erweiterungen finden Sie unter
Introducing native extensions for Adobe AIR
.
|
|
|