Geschichten von 1001 Pixel – Wie Android mit verschiedenen Auflösungen umgeht

Firmware und OS

[Gastbeitrag] Ich bin regelmäßiger mobiFlip.de-Leser und freue mich immer über neue Artikel. In letzter Zeit gab es jedoch öfter Themen bei denen es in den Kommentaren hoch her ging, da vielen Lesern einfach das entsprechende Hintergrundwissen zu Android fehlt. Dem will ich mit einer Artikelserie, welche ich freundlicherweise als Gastautor hier veröffentlichen darf, versuchen entgegen zu steuern.

Im ersten Artikel will ich euch näher bringen, wie Android mit verschiedenen Auflösungen umgeht. In der Android Welt gibt es mittlerweile unzählige Geräte, mit unzähligen Formfaktoren und dem entsprechend vielen verschiedenen Auflösungen. Wie werden also Apps programmiert damit sie auf jedem Gerät „richtig“ dargestellt werden können? Wie handhabt Android verschiedene Auflösungen damit der Benutzer nichts davon merkt?

Als erstes muss man sich die unterschiedliche Herangehensweise klar machen. Hier schauen wir uns erst iOS an, um den Unterschied dann später deutlicher zu sehen. Bei iOs gibt es fest definierte Auflösungen die wohl bekannt sind.

  • das erste iPhone Auflösung bis zum 3GS mit 480 x 320 px
  • „Retina“ Auflösung ab dem iPhone 4 mit genau der Doppelten 960 x 640 px
  • iPad 1 und 2 Auflösung mit 1024 x 768 px
  • iPad 3 Auflösung mit wieder genau der Doppelten 2048 x 1536 px

Wie man erkennt wurde bei iOs die Auflösung immer verdoppelt, nur wieso? Diese Vorgehensweise hat ganz praktische Gründe. Die Bedienoberfläche wird in iOS absolut definiert, d. h. pixelgenau. Wenn also die linke obere Ecke eines Buttons bei der ersten iPhone Auflösung, bei Pixel 30 in der Breite und Pixel 50 in der Höhe festgelegt wird, dann befindet sich diese Ecke bei der iPhone 4 Auflösung einfach bei Pixel 60 in der Breite und Pixel 100 in der Höhe. Immer der doppelte Wert.

Wenn man sich diesen Button auf beiden Geräten nebeneinander anschaut, dann hat man den Eindruck, dass beide Buttons an der Gleiche stelle auf dem Display dargestellt werden. Das hat den Vorteil, dass es recht einfach ist eine UI (Bedieneroberfläche) in iOS zusammenzubauen und für „alle“ Geräte auszulegen.

Bei Android funktioniert das alles ganz anders. Dem Android-System is die Auflösung des Gerätes, auf dem es läuft, erstmal egal. In Android zählen die Werte:

  • Diagonale des Displays
  • Pixeldichte DPI des Displays

Um jedoch die Pixeldichte zu berechnen, braucht man die Auflösung und die Diagonale. Es gibt vier Unterteilungen für die Displaygröße und vier für die Pixeldichte. Als Beispiel hat ein Samsung Galaxy S eine Diagonale von 4 Zoll und eine Auflösung von 800 x 480 Pixel. Damit wird es in die Displaygröße „normal screen“ und „hdpi“ eingeteilt.

Ein Asus Transformer (egal ob TF101 oder TF201) mit 10,1 Zoll und einer Auflösung von 1280 x 800 Pixel entspricht der Displaygröße „extra large screen und „mdpi“. Die neuen Full-HD Tablets werden mit 10,1″ und 1920 x 1200 Pixel in „extra large screen“ und „hdpi“ eingeteilt. (wir kommen später dazu, wieso das super ist)

Nachdem für einen Bildschirm diese zwei Eigenschaften festgelegt worden sind, wird es im System auf dem Gerät hinterlegt. Das Gerät kennt nun also seine Displaygröße und Pixeldichte. Nur wofür ist das gut?

Dafür will ich erstmal erklären welche Auswirkung die Pixeldichte auf die Darstellung hat. Man stelle sich vor, dass man drei Bildschirme hätte, welche alle die gleiche Größe haben (normal screen size) jedoch unterschiedliche Auflösungen und somit auch Pixeldichten. Der erste Screen ist „ldpi“, der Zweite „mdpi“ und der Dritte „hdpi“. Wenn man nun also ein Bild mit z.B. 100 x 100 Pixel hat, dann werden bei jedem Screen 100 x 100 Pixel ausgefüllt. Wie das dann aussieht wird auf dem nächsten Bild dargestellt.

Man erkennt wie unterschiedlich groß die Elemente dargestellt werden. Das liegt daran, dass bei „low density“ (ldpi) die Breite in Pixel 240 beträgt und 100 Pixel davon sehr viel sind. Beim mittleren Bild (mdpi) liegt die Breite in Pixel bei 320 und beim dritten Bild (hdpi) bei 480 Pixel. Die 100 Pixel aus unserem Beispiel nehmen auf den Bildschirmen also unterschiedlich viel physikalischen Platz ein. Wenn man ein Lineal anlegt, würde man bei jedem Bildschirm unterschiedliche Werte in mm bzw. cm messen.

Um dieses Prolem zu lösen, wurden zwei Konzepte eingeführt.

1. Verschiedene Resourcen Ordner

Um bei unserem Beispeil zu bleiben, gehen wir davon aus, dass wir ein Bild haben, welches auf jedem Bildschirm, egal welches Pixeldichte es hat, gleich groß dargestellt werden soll. Zum Beispiel soll es 1 x 1 cm auf dem Bildschirm füllen. Man erstellt also in einem Bildbearbeitungsprogramm 3 Dateien welche 1 x 1 cm groß sein sollen, jedoch unterschiedliche Pixeldichten haben (140, 160 und 240).

Wenn eine Android-App programmiert wird, steht dem Programmierer ein Resource-Ordner zur Verfügung. In diesem werden Bilder und Layouts (XML Daten) in Unterordnern hinterlegt. Bei Bildern stehen 3 bzw. 4 Unterordner zur verfügung.

  • „/drawable-ldpi“
  • „/drawable-mdpi“
  • „/drawable-hdpi“
  • (- „/drawable-xhdpi“)

Wenn nun also die drei erstellten Bilder in den entsprechenden Ordnern hinterlegt werden, dann sucht sich das System das richtige Bild für seine Pixeldichte aus und stellt es dar. Das Bild hat jetzt auf jedem Bildschirm die gleiche Größe.

Der Vorteil dieses Systems ist, dass ein Bild, welches im mdpi-Ordner hinterlegt ist, für Handys mit kleinen Auflösungen verwendet werden kann, aber ebenso für Tablets. Wenn wir also davon ausgehen, dass hdpi die gebräuchlichste Pixeldichte ist und die allermeisten Apps Bilder in hdpi hinterlegt haben, dann werden FullHD Tablets darauf zugreifen können und die Programmierer müssen nicht alle Bilder nochmal überarbeiten.

2. Der Pixeldichte unabhängige Pixel

Da Buttons zum Beispiel jedoch keine Bilder im eigentlichen Sinne sind, hat man in Android eine neue Einheit eingeführt: Den „dip“ density independent pixel, also den Pixeldichte unabhängigen Pixel. Ein dip ist definiert als:

  • 1 Pixel bei mdpi
  • 0,75 Pixel bei ldpi
  • 1,5 Pixel bei hdpi
  • 2 Pixel bei xhdpi

Wie kann man sich das vorstellen? Es wird also ein Button in der Größe 100 x 100 dip definiert. Die dip-Werte werden nun von System je nach Pixeldichte umgerechnet. Dieser Button belegt bei:

  • mdpi 100 x 100 Pixel
  • ldpi 75 x 75 Pixel
  • hdpi 150 x 150 Pixel
  • xhdpi 200 x 200 Pixel

Damit belegen Elemente die in „dip“ definiert wurden, auf jedem Bildschirm die gleiche physikalische Größe.

Und nun zum letzten Teil: Layouts für verschiedene Geräte bzw. Auflösungen oder Ausrichtungen

Layouts werden in Android im XML Format erstellt, ich werde in diesem Artikel aber nicht auf die unterschiedlichen Möglichkeiten eingehen, ein Layout zu erstellen. Dazu kommt dann eventuell in einem weiteren Beitrag mehr. Ein erstelltes Layout wird im Ressourcen-Unterordner „layout“ abgelegt. In diesem Ordner sucht das Android-System beim Start einer Anwendung als Erstes nach dem definierten Layout.

Wenn man jetzt noch zusätzliche Ordner anlegt wie z.B. „layout-land“ kann man dort Layoutdaten hinterlegen die den gleichen Namen haben, jedoch das Layout für den Bildschirm in horizontaler Orientierung beinhalten. Man definiert also das Layout „main.xml“ und legt es in beide Ordner ab. Der Name der Datei bleibt gleich, aber der Inhalt kann sich unterscheiden. Beim Drehen des Gerätes schaut das System in den richtigen Ordner und baut das Layout so auf, wie in der entsprechenden main.xml hinterlegt.

Das hat in der Anfangszeit von Android ausgereicht, um eine App richtig auszulegen, da es noch nicht so viele verschiedene Auflösungen gab. Mittlerweile ist das jedoch zu wenig. Somit hat man angefangen ab Android 3.2 (API 13) noch mehr Layoutordner-Bezeichnungen einzuführen, um ein Layout in noch mehr verschiedenen Variationen hinterlegen zu können.

Hier ein Beispiel für eine App, die Layouts hinterlegt hat für Smartphones mit mdpi- und hdpi-Bildschirm jeweils in „portrait“ und „landscape“, ein Tablet mit 7 Zoll Diagonale und 1024 x 600 Pixel, ein Tablet mit 10,1 Zoll Diagonale und 1280 x 800 Pixel und noch ein Tablet mit 10,1 Zoll Diagonale und 1920 x 1200 Pixel jeweils in beiden Bildschirmausrichtungen.

  • /layout #Geräte die nicht definiert werden in portrait
  • /layout-land #Geräte die nicht definiert werden in landscape
  • /layout-mdpi #Smartphone mit mdpi in portrait
  • /layout-mdpi-land #Smartphone mit mdpi in landscape
  • /layout-hdpi #Smartphone mit hdpi in portrait
  • /layout-hdpi-land #Smartphone mit hdpi in landscape
  • /layout-sw600dpi #Tablet mit Bildschirmbreite von mindestens 600dip für portrait (7″ Tablet im portrait Modus)
  • /layout-sw600dpi-land #Tablet mit Bildschirmbreite von mindestens 600dp für landscape (7″ Tablet im landscape Modus)
  • /layout-sw720dpi #Tablet mit Bildschirmbreite von mindestens 720dp für portrait (10,1″ Tablet mit 1280x800px oder 1920x1200px im portrait Modus)
  • /layout-w720dpi-land #Tablet mit Bildschirmbreite von mindestens 720dp für landscape (10,1″ Tablet mit 1280x800px oder 1920x1200px im portrait Modus)

In all diese Ordner kann eine Layout-XML-Datei mit dem selbem Namen hinterlegt werden und das System lädt je nach Gerät und Fall die richtige Version. Somit kann eine App mit nur einer APK (ausführbares Android-Programm) auf jedem Gerät, welches mit Android läuft, richtig dargestellt werden.

Ich hoffe, ich konnte ein wenig Klarheit in den Auflösungsdschungel bringen und auch den nicht „Pixelfreaks“ verständlich erklären was da so alles im Hintergrund passiert. Dieser Artikel ist nicht ganz komplett. Ich habe versucht das Thema auf ein Minimum herunter zu brechen, um nicht zu überfordern. ;) Wer es ganz genau wissen will, sollte einfach mal auf dieser Seite für Android-Entwickler vorbeischauen.

Bei Fehlern im Text bitte im Kommentar eine Bemerkung mit Quelle hinterlassen und dann wird es natürlich ausgebessert. Ebenso sind Wünsche für weitere Beiträge dieser Artikelserie und Fragen, Kritik sowie Lob gern gesehen. Dieser Text wurde mit einem Asus TF101 mit Bluetooth-Tastatur und USB-Maus erstellt, was erstaunlich gut funktioniert hat.

Info

Über den Autor: Ich bin der Michael, 27 Jahre alt und studiere Technische Redaktion an der HS Merseburg. In diesem Studiengang lernt man technische Sachverhalte einfach und verständlich wiederzugeben. Als kleine Übung verfasse ich ab und an Artikel. Ich programmiere seit ca. einem halben Jahr für die Android Plattform.

Meine Music Mixer HD App wurde bei mobFlip.de auch schon vorgestellt. Das Thema ist für mich Hobby und Leidenschaft zugleich. Wer Fragen an mich persönlich hat, kann mir einfach eine Mail schicken. Wer mehr über dieses Studiengang erfahren will, kann sich auch gerne bei mir melden.


Fehler melden37 Kommentare

  1. Das DISQUS-Kommentarsystem verarbeitet personenbezogene Daten. Das System wird aus diesem Grund erst nach ausdrücklicher Einwilligung über nachfolgende Schaltfläche geladen. Es gilt die Datenschutzerklärung.

Du bist hier:
mobiFlip.de / Devs und Geeks / Firmware und OS / ...