Software ubiquitärer Systeme

Transkript

1 Software ubiquitärer Systeme Anwendungsentwicklung mit Java Olaf Spinczyk Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund 1

2 Motivation Probleme mit C und C++ effizienter Code aber unsicher eingeschränkte Portabilität - verschiedene Betriebssysteme und GUI-Bibliotheken: z.b. in Mobiltelefonen Symbian OS, Windows CE, Linux Varianten Sichere C++ Dialekte weniger effizienter Code mangelnde Verbreitung/Standardisierung Was ist die Alternative? Ein Ein Java Java für für eingebettete eingebettete Systeme! Systeme! 2

3 Die Java-Familie Je nach Anforderungen der Anwendungen bzw. Leistungsfähigkeit der Geräte bedient Oracle verschiedene Anwendungsdomänen mit unterschiedlichen Java Plattformen. Nicht Nicht nur nur die die Bibliotheken Bibliotheken sondern sondern auch auch die die virtuellen virtuellen Maschinen Maschinen unterscheiden unterscheiden sich. sich. Quelle: [1] 3

4 Inhalt Motivation Java Micro Edition Java Card Alternativen Android.NET Compact Zusammenfassung 4

5 Die Java Micro Edition Kurz: Java ME Sun Microsystems, Juni 1999 Zielmarkt Pager, PDAs Mobiltelefone, Smartphones Fernseher, Videorekorder, CD Player Java 2 Standard Edition API Java Micro Edition API Die meisten (klassischen) Mobiltelefone unterstützen heute Java ME Abgespeckte Version der Standard Edition (Java SE) Weniger Speicherverbrauch Keine schwergewichtigen Klassen (swing, awt, ) Optimierte virtuelle Maschine (KVM) 5

6 Java ME Architektur Die von Java ME abgedeckte Domäne ist riesig unterschiedlichste Geräte und Geräteklassen (Ressourcen) unterschiedlichste Anwendungen (Anforderungen) Um die Java ME zu strukturieren, wurden zwei grundlegende Konzepte definiert: Konfigurationen und Profile Leistungsstärkere Geräte Konfigurationen: Horizontale Aufteilung des Marktes... Leistungsschwache Geräte Profile: Vertikale Marktaufteilung 6

7 Java ME Konfigurationen Definiert Geräteklassen anhand verfügbarer Ressourcen CPU-Klasse, Speicher, Netzwerkanbindung Entscheidet über die verwendete virtuelle Maschine sowie APIs für elementare Funktionen. die Java Ausführungsumgebung Bisher wurden zwei Konfigurationen festgelegt CLDC: Connected Limited Device Configuration - z.b. Mobilfunkgeräte, um die 500 KB Speicher, einfache Applikationen - spezielle VM CDC: Connected Device Configuration - z.b. Smart Phones ab 2 MB Speicher, Set-Top-Boxes, High-End PDAs 7

8 Java ME Profile Hängen von der jeweiligen Anwendungsdomäne ab Definieren verfügbare APIs Sorgen für Portabilität Haben Abhängigkeiten Beispiele: MIDP (Mobile Information Device P.) - Netzwerk-Kommunikation - Einfache Benutzerschnittstelle - Datenspeicherung Personal Profile - Komplettes AWT - Ausführungsumgebung für Applets Quelle [1] 8

9 Java ME für Mobilgeräte MIDP Herstellerspezifische APIs CLDC Java VM (KVM) Betriebssystem KVM - Kilobyte Virtual Machine KB groß (je nach Compiler) Implementiert in C (ca Zeilen) Für Geräte mit mindestens KB Speicher und - 16 oder 32 Bit CPU 9

10 KVM: Was fehlt? Unterstützung für Object.finalize() Wird auch praktisch nicht verwendet Fehlerbehandlungsfähigkeiten (eingeschränkt) Es gibt lediglich 3 Fehler-Klassen - java.lang.error, java.lang.outofmemory und java.lang.virtualmachineerror Java Native Interface (JNI) Benutzerdefinierte Class Loader Reflection-Mechanismus Threading-Fähigkeiten (eingeschränkt) Zur Vermeidung von Sicherheitsproblemen und wegen des Overheads Keine Thread Groups und Daemon Threads) Verifikation von Class Files Einsatz eines Pre-Verifiers 10

11 Entwicklungsprozess Java-Quelltext Compile javac... Preverification preverify... Packaging jar... Deployment emulator... Java Class-Dateien Pre-verifizierte Class-Dateien JAR-Paket Anwendung auf dem Gerät 11

12 Java ME für Mobilgeräte MIDP Herstellerspezifische APIs CLDC Java VM (KVM) Betriebssystem CLDC - Connected Limited Device Configuration Low-Level Funktionalität - Umgang mit der Laufzeitumgebung, Ein-/Ausgabe Besteht aus of java.io, java.lang, java.util, java.microedition.io - Allerdings nur Teilmengen der aus Java SE bekannten Klassen! - Die Semantik bleibt aber erhalten 12

13 Java ME für Mobilgeräte MIDP Herstellerspezifische APIs CLDC Java VM (KVM) Betriebssystem MIDP Mobile Information Device Profile MIDP stellt Kernfunktionen für Mobilgeräte zur Verfügung - Netzwerkkommunikation - Datenhaltung - Benutzerschnittstelle 13

14 Mobile Information Device Profile Minimalanforderungen Bildschirmauflösung von mind. 96x54 Pixeln Keypad, Tastatur oder Touch Screen 256 KB nicht-flüchtiger Speicher 128 KB RAM 8 KB nicht-flüchtiger Speicher für persistente Daten Bi-direktionale Netzwerkverbindung MIDP 2.0 Packages javax.microedition.lcdui, javax.microedition.lcdui.game, javax.microedition.media, javax.microedition.media.control, javax.microedition.midlet, javax.microedition.pki, javax.microedition.rms Ausführung von Midlets Java ME-Applikationen bestehen aus 1 bis N MIDlets 14

15 Java ME: Midlet-Lebenszyklus MIDlets werden wie Applets von der Umgebung gesteuert Konstruktor Paused destroyapp() notifydestroyed() startapp() pauseapp() notifypaused() Destroyed Active destroyapp() notifydestroyed() 15

16 Java ME: Midlet-Beispiel Man Man erbt erbt von von MIDlet. MIDlet. // Zur Vereinfachung ohne Exceptions... public class HelloMIDlet extends MIDlet implements CommandListener { private Form mmainform; public HelloMIDlet() { mmainform = new Form("HelloMIDlet"); mmainform.append(new StringItem(null, "Hello, MIDP!")); mmainform.addcommand(new Command("Exit", Command.EXIT, 0)); mmainform.setcommandlistener(this); } protected void destroyapp(boolean arg0) { Diese Diese Methoden Methoden werden werden vom vom } Application Application Management Management System System protected void pauseapp() { (AMS) } (AMS) des des Mobilgeräts Mobilgeräts aufgerufen. aufgerufen. protected void startapp() { Display.getDisplay(this).setCurrent(mMainForm); } public void commandaction(command arg0, Displayable arg1) { notifydestroyed(); So So wird wird das das AMS AMS angewiesen angewiesen } das } das MIDlet MIDlet zu zu beenden. beenden. 16

17 Java ME: Demo Zum Bauen von Midlets benutzt man das Java ME SDK (aktuell 8.1) Demo-Applikationen Emulator Alle sonstigen Werkzeuge 17

18 Java ME: Fazit Pro Durch Konfigurationen und Profile wird eine Familie von JavaLösungen bereitgestellt - Damit skaliert der Ressourcenverbrauch Standardisierte domänenspezifische Bibliotheken Die kvm benötigt erstaunlich wenig Speicher Contra Die kvm ist leider langsam Leichte Einschränkungen bzgl. der Sprache müssen hingenommen werden - z.b. kein Reflection Entwickler müssen sich mit anderen Bibliotheken anfreunden 18

19 Inhalt Motivation Java Micro Edition Java Card Alternativen Android.NET Micro/Compact Framework Zusammenfassung 19

20 Java Card: Hardware Eine Java-Lösung für Smart Cards (Chipkarten mit Prozessor) Hardware-Eigenschaften Stromversorgung durch Lesegerät Interaktion lediglich mit dem Lesegerät - Serielle Schnittstelle, Standardprotokoll Enthalten Universalprozessor Bit, 3,5-5 MHz Extrem wenig Speicher KB ROM - 0,5-1 KB RAM KB EEPROM Vcc Reset Clock RFU C1 C2 C3 C4 C5 C6 C7 C8 Ground Vpp I/O RFU Definitiv zu klein für Java ME! 20

21 Java Card: Anwendungen Einsatzgebiete Krankenkassenkarten Bankkarten (EC) Handy-SIM-Karten Ausweise Ziel: nur eine Karte für viele Applikationen Anforderungen an die Java Card Plattform Sicherheit und Zuverlässigkeit - Verwaltung und Isolierung der Applikationen auf der Karte Extrem geringer Ressourcenverbrauch Für die Domäne passende standardisierte Packages Portabilität Kompatibilität mit existierenden Standards 21

22 Java Card: Was fehlt? Dynamisches Klassenladen Security Manager Garbage Collection Threads Klonen von Objekten Mehrdimensionale Felder Datentypen char, double, float und long Die Java Card API beschränkt sich auf folgende Pakete java.lang, javacard.framework, javacard.security, javacardx.crypto 22

23 Java Card: Applets... sind persistente Zustandsautomaten, die auf Nachrichten des Lesegeräts reagieren. haben (mindestens) folgende Methoden install - Erzeugung und Registrierung der Applet-Instanz select - Das Lesegerät spricht das Applet an process - Interpretation der Nachrichten (APDUs) vom Lesegerät deselect - Das Lesegerät beendet die Kommunikation mit dem Applet 23

24 Java Card: Fazit Pro Plattformunabhängige Entwicklung für Smart Cards Unterstützung mehrerer Applikationen auf einer Karte Dynamische Installation/Deinstallation von Applets Standardisierte Bibliotheken Nutzbarkeit von Java Know-How Contra Die Sprache ist zwar Java, das Programmiermodell aber nicht. Essentielle Sprachelemente fehlen Deutliche Nachteile hinsichtlich der Performance Vergleichsweise hohe Ressourcenanforderungen 24

25 Inhalt Motivation Java 2 Micro Edition Java Card Alternativen Android.NET Micro/Compact Framework Zusammenfassung 25

26 Android Open Handset Alliance (primär Google), 2007 T-Mobile, Motorola, Samsung,... Vision:... accelerate innovation in mobile and offer consumers a richer, less expensive, and better mobile experience. Infrastruktursoftware-Plattform für Smartphones Open Source Diverse Produkte inzwischen verfügbar 26

27 Android: Architektur Linux und Java aber anders... 27

28 Android: Architektur Linux und Java aber anders... Die Die Dalvik-VM Dalvik-VM führt führt Java-Programme Java-Programme aus, aus, deren deren Bytecode Bytecode in in Dalvik-Bytecode Dalvik-Bytecode übersetzt übersetzt wurde. wurde. 28

29 Android: Die Dalvik-VM Benannt nach einer isländischen Stadt Hauptunterschiede Java-Bytecode ist stapelbasiert, Dalvik-Bytecode ist registerbasiert - Java-Bytecode lässt sich nicht (direkt) ausführen - Ein Übersetzungschritt ist erforderlich Dalvik Code wurde bis Android 2.2 nur interpretiert - Heute Trace-basierter JIT-Compiler Gründe Kompaktheit des Codes JIT-Compiler wurde als unnötig erachtet, da die Performancekritischen Teile nativ ausgeführt werden (Kernel/Libraries) - inzwischen können Anwendungen auch native code verwenden - JIT darf nicht zu viel Speicher benötigen Lizenzrechte? 29

30 Android: Größen (statisch) common system libraries (U) % (J) % (D) % (U) (U) unkomprimierte unkomprimierte jar-datei jar-datei (J) (J) komprimierte komprimierte jar-datei jar-datei (D) (D) unkomprimierte unkomprimierte dex-datei dex-datei web browser app (U) % (J) % (D) % alarm clock app (U) % (J) % (D) % Der Der Grund Grund ist ist allerdings allerdings nicht nicht nur nur der der kompaktere kompaktere Bytecode, Bytecode, sondern sondern auch auch eine eine schlaueres schlaueres Dateiformat. Dateiformat. Quelle: Dan Bornstein, Dalvik VM Entwickler 30

31 Android: Größen (dynamisch) Quelle: A JIT Compiler for Android s Dalvik VM Ben Cheng, Bill Buzbee, May 2010 JIT arbeitet Trace-basiert Übersetzung auf Ebene von Basisblöcken (statt ganzen Prozeduren) Ein Translation Cache pro Prozess (VM-Instanz) Trade-off zwischen Performance und Speicherbedarf akzeptabel 31

32 Android: ART (1) Kompilierung von Android Apps in Maschinencode zum Installationszeitpunkt ab Android 4.4 möglich Vorteile Dalvik-VM und JIT werden nicht mehr benötigt wenige Speicher Kein Tracing/Übersetzen zur Laufzeit weniger Energie Linux lädt Programme inkrementell starten schneller Alle Programmeteile liegen in Maschinencode vor laufen schnell Nachteile Keine dynamischen Optimierungen teilweise auch langsamer 32

33 Android: ART (2) Partielle Code-Spezialisierung in JIT-Compiler nicht bei ART Basierend Basierend auf auf der der Ausführungshäufigkeit Ausführungshäufigkeit von von Funktionen Funktionen mit mit bestimmten bestimmten Parametern (ermittelt Parametern (ermittelt vom vom Trace-JIT) werden Trace-JIT) werden Funktionen Funktionen spezialisiert. spezialisiert. Entsprechende EntsprechendeAufrufe Aufrufe werden umgeleitet. werden umgeleitet. int myfunc(int par1, int par2, int par3) { int r = 47; if (par1*par2 > 5) { int i; for (i=0; i<par1*par2;i++) { r+=par3*i; } } else r = par1+par2+par3 return r; } myfunc(7,5,2) int myfunc(int par1, int par2, int par3) { int r = 47; int i = 35; while (--i) r += i + i; return r; } myfunc(2,2,12) int myfunc(int par1, int par2, int par3) { return 16; } Quelle: c't 13/2015 Endlich kompiliert 33

34 Android: ART(3) Und wie steht's nun mit der Performance? In c't 13/2015 wurden 9 Benchmarks verglichen (relative Performance im Vergleich zu Dalvik) Android 4.4/ARM: 99% bis 184%, Durchschnitt 133% Android 5.1/ARM: 65% bis 238%, Durchschnitt 149% Android 4.4/Intel: 28% bis 179%, Durchschnitt 74% Android 5.1/Intel: 47% bis 176%, Durchschnitt 106% Fazit ART hat das Potential die Performance deutlich zu verbessern Kinderkrankheit auf Intel-basierten Android-Geräten 34

35 Android: Fazit Android ist für Smartphones ausgelegt Skalierbarkeit ist kein Thema Annahme: typische MB Speicher, MHz CPU - heute viel mehr vorhanden! Android zeigt, dass die Java-VM nicht unbedingt perfekt geeignet ist, um kleine Systeme zu bauen - Dalvik-Bytecode ist signifikant kleiner Ausführung von kompiliertem Maschinencode und Portabilität kein Widerspruch sein müssen - Übersetzung zum Installationszeitpunkt bei ART 35

36 .NET Framework für eingeb. Systeme? Microsoft Ermöglicht.NET auf Windows CE/Mobile-Geräten Quelle: msdn.microsoft.com Moderne Zwischensprache (MSIL) für mehrere Quellsprachen - C#, VB, J#, C++, - Ausgelegt auf JIT-Compiler Anwendungsentwicklung in MS Visual Studio Diverse Bibliotheken - Benutzerschnittstelle, Kommunikation, - Allerdings an diversen Stellen beschnitten Größenreduktion des.net Frameworks Compact: erfordert 12 MB Micro: erfordert 256 KB Flash, 64KB RAM (läuft ohne OS, kein JIT) 36

37 Inhalt Motivation Java Micro Edition Java Card Alternativen Android.NET Micro/Compact Framework Zusammenfassung 37

38 Zusammenfassung Java-Umgebungen bilden eine Produktlinie Bei den kleineren Varianten gibt es Einschränkungen Skalierbarkeit von 8 Bit Chipkarten bis 64 Bit Serversystemen z.b. keine Garbage Collection bei Java Card Es gibt auch Alternativen Dalvik- und MSIL-Programme haben kompakteren Code Klassische Mobiltelefone und damit auch Java ME werden Smartphones verdrängt 38

39 Literatur [1] [2] M. de Jode, Programming Java 2 Micro Edition on Symbian OS, ISBN , Wiley, Java Card Platform Specification 2.2.2, Sun Microsystems. 39