Responsive/adaptive Layouts sorgen unabhängig von der Bildschirmgröße für eine optimierte Nutzererfahrung. Implementieren Sie responsive/adaptive Layouts, damit Ihre ansichtbasierte App alle Displaygrößen, Ausrichtungen und Konfigurationen unterstützt, einschließlich konfigurierbarer Größen wie dem Multi-Window-Modus.
Responsives Webdesign
Der erste Schritt zur Unterstützung verschiedener Geräteformfaktoren besteht darin, ein Layout zu erstellen, das auf Änderungen des für Ihre App verfügbaren Anzeigebereichs reagiert.
ConstraintLayout
Am besten erstellen Sie ein responsives Layout, indem Sie ConstraintLayout als Basislayout für Ihre Benutzeroberfläche verwenden. Mit ConstraintLayout können Sie die Position und Größe jeder Ansicht entsprechend den räumlichen Beziehungen zu anderen Ansichten im Layout angeben. Alle Ansichten können dann gemeinsam verschoben und in der Größe angepasst werden, wenn sich der Anzeigebereich ändert.
Am einfachsten lässt sich ein Layout mit ConstraintLayout mit dem Layout-Editor in Android Studio erstellen. Mit dem Layout-Editor können Sie neue Ansichten in das Layout ziehen, Einschränkungen relativ zu übergeordneten und gleichgeordneten Ansichten anwenden und Ansichtseigenschaften festlegen, ohne XML manuell bearbeiten zu müssen.
ConstraintLayout.
Weitere Informationen finden Sie unter Responsive UI mit ConstraintLayout erstellen.
Responsive Breite und Höhe
Damit Ihr Layout auf unterschiedliche Displaygrößen reagiert, verwenden Sie für die Breite und Höhe von Ansichtskomponenten wrap_content, match_parent oder 0dp (match constraint) anstelle von fest codierten Werten:
wrap_content: Die Ansicht wird so angepasst, dass sie den Inhalt der Ansicht aufnehmen kann.match_parent: Die Ansicht wird so weit wie möglich innerhalb der übergeordneten Ansicht erweitert.0dp (match constraint): In einemConstraintLayout, ähnlich wiematch_parent. Die Ansicht nimmt den gesamten verfügbaren Platz innerhalb der Einschränkungen der Ansicht ein.
Beispiel:
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="@string/lorem_ipsum" />
In Abbildung 4 ist zu sehen, wie sich die Breite und Höhe von TextView an die Displaybreite anpassen, wenn sich die Ausrichtung des Geräts ändert.
TextView.
Die Breite des TextView wird so festgelegt, dass der gesamte verfügbare Platz ausgefüllt wird (match_parent). Die Höhe wird genau so festgelegt, wie es durch die Höhe des enthaltenen Texts erforderlich ist (wrap_content). So kann sich die Ansicht an unterschiedliche Displayabmessungen und unterschiedliche Textmengen anpassen.
Wenn Sie ein LinearLayout verwenden, können Sie die untergeordneten Ansichten auch basierend auf dem Layoutgewicht erweitern, damit sie den verfügbaren Platz proportional ausfüllen. Wenn Sie jedoch Gewichte in einem verschachtelten LinearLayout verwenden, muss das System mehrere Layoutdurchläufe ausführen, um die Größe für jede Ansicht zu bestimmen. Das verlangsamt die UI-Leistung.
Mit ConstraintLayout lassen sich fast alle mit LinearLayout möglichen Layouts erstellen, ohne dass sich dies auf die Leistung auswirkt. Wandeln Sie daher Ihre verschachtelten LinearLayout in ConstraintLayout um. Anschließend können Sie gewichtete Layouts mit Constraint-Chains definieren.
Adaptives Design
Das Layout Ihrer App sollte immer auf unterschiedliche Displaygrößen reagieren. Auch ein responsives Layout kann jedoch nicht auf jedem Gerät oder in jedem Multi-Window-Modus für eine optimale Nutzerfreundlichkeit sorgen. Die Benutzeroberfläche, die Sie für ein Smartphone entwickelt haben, bietet auf einem Tablet wahrscheinlich keine optimale User Experience. Mit adaptivem Design werden alternative Layouts bereitgestellt, die für verschiedene Anzeigedimensionen optimiert sind.
SlidingPaneLayout für Listen-Detailansichten
Eine Listen-Detailansicht-Benutzeroberfläche bietet in der Regel auf unterschiedlich großen Bildschirmen eine andere Nutzererfahrung. Auf großen Bildschirmen werden die Listen- und Detailbereiche in der Regel nebeneinander angezeigt. Wenn ein Element in der Liste ausgewählt ist, werden die zugehörigen Informationen im Detailbereich angezeigt, ohne dass sich die Benutzeroberfläche ändert. Die beiden Bereiche bleiben nebeneinander. Auf kleinen Bildschirmen werden die beiden Bereiche jedoch separat angezeigt und nehmen jeweils den gesamten Anzeigebereich ein. Wenn ein Element im Listenbereich ausgewählt wird, ersetzt der Detailbereich (mit den Informationen des ausgewählten Elements) den Listenbereich. Bei der Rückwärtsnavigation wird der Detailbereich durch die Liste ersetzt.
SlidingPaneLayout
verwaltet die Logik, mit der bestimmt wird, welche der beiden Nutzererfahrungen für die aktuelle Fenstergröße geeignet ist:
<?xml version="1.0" encoding="utf-8"?>
<androidx.slidingpanelayout.widget.SlidingPaneLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">
<androidx.recyclerview.widget.RecyclerView
android:id="@+id/recycler_view"
android:layout_width="280dp"
android:layout_height="match_parent"
android:layout_gravity="start" />
<androidx.fragment.app.FragmentContainerView
android:id="@+id/nav_host_fragment"
android:name="androidx.navigation.fragment.NavHostFragment"
android:layout_width="300dp"
android:layout_height="match_parent"
android:layout_weight="1"
app:defaultNavHost="true"
app:navGraph="@navigation/item_navigation" />
</androidx.slidingpanelayout.widget.SlidingPaneLayout>
Die Attribute layout_width und layout_weight der beiden Ansichten in SlidingPaneLayout bestimmen das Verhalten von SlidingPaneLayout. Wenn das Fenster in diesem Beispiel breit genug ist (mindestens 580 dp), um beide Ansichten darzustellen, werden die Bereiche nebeneinander angezeigt. Wenn die Fensterbreite jedoch kleiner als 580 dp ist, werden die Bereiche übereinander geschoben, sodass sie jeweils das gesamte App-Fenster einnehmen.
Wenn die Fensterbreite größer als die insgesamt angegebene Mindestbreite (580 dp) ist, können layout_weight-Werte verwendet werden, um die beiden Bereiche proportional zu dimensionieren. Im Beispiel ist der Listenbereich immer 280 dp breit, da er kein Gewicht hat.
Der Detailbereich füllt jedoch aufgrund der layout_weight-Einstellung der Ansicht immer den horizontalen Bereich über 580 dp hinaus aus.
SlidingPaneLayout
Alternative Layoutressourcen
Um Ihr UI-Design an sehr unterschiedliche Displaygrößen anzupassen, verwenden Sie alternative Layouts, die durch Ressourcenqualifizierer identifiziert werden.
Sie können adaptive, bildschirmbezogene Layouts bereitstellen, indem Sie im Quellcode Ihrer App zusätzliche res/layout/-Verzeichnisse erstellen. Erstellen Sie für jede Bildschirmkonfiguration, die ein anderes Layout erfordert, ein Verzeichnis. Hängen Sie dann dem Verzeichnisnamen layout einen Qualifikator für die Bildschirmkonfiguration an, z. B. layout-w600dp für Bildschirme mit einer verfügbaren Breite von 600 dp.
Die Konfigurationsqualifizierer stellen den sichtbaren Anzeigebereich dar, der für die Benutzeroberfläche Ihrer App verfügbar ist. Das System berücksichtigt alle Systemdekorationen (z. B. die Navigationsleiste) und Änderungen an der Fensterkonfiguration (z. B. Multifenstermodus), wenn das Layout für Ihre App ausgewählt wird.
Informationen zum Erstellen alternativer Layouts in Android Studio finden Sie unter Layoutvarianten verwenden, um für verschiedene Bildschirme zu optimieren in Benutzeroberfläche mit Ansichten entwickeln.
Qualifikator für die geringste Breite
Mit dem Größenqualifizierer geringste Breite können Sie alternative Layouts für Displays mit einer Mindestbreite in dichteunabhängigen Pixeln (dp) angeben.
Wenn Sie die Bildschirmgröße als Maß für dp angeben, können Sie mit Android Layouts erstellen, die für bestimmte Displayabmessungen konzipiert sind, ohne sich um unterschiedliche Pixeldichten kümmern zu müssen.
Sie können beispielsweise ein Layout mit dem Namen main_activity erstellen, das für Smartphones und Tablets optimiert ist, indem Sie verschiedene Versionen der Datei in verschiedenen Verzeichnissen erstellen:
res/layout/main_activity.xml # For phones (smaller than 600dp smallest width) res/layout-sw600dp/main_activity.xml # For 7" tablets (600dp wide or wider)
Der Qualifikator für die kleinste Breite gibt die kürzere der beiden Seiten des Displays an, unabhängig von der aktuellen Ausrichtung des Geräts. So können Sie die für Ihr Layout verfügbare Gesamtgröße des Displays angeben.
So entsprechen andere Werte für die kleinste Breite typischen Bildschirmgrößen:
- 320 dp: Kleiner Smartphone-Bildschirm (240 × 320 ldpi, 320 × 480 mdpi, 480 × 800 hdpi usw.)
- 480 dp: Großer Smartphone-Bildschirm, ca. 5 Zoll (480 × 800 mdpi)
- 600 dp: 7‑Zoll-Tablet (600 × 1.024 mdpi)
- 720 dp: 10‑Zoll-Tablet (720 × 1.280 mdpi, 800 × 1.280 mdpi usw.)
Die folgende Abbildung zeigt genauer, wie verschiedene Bildschirmbreiten in Geräte-Pixeln unterschiedlichen Bildschirmgrößen und ‑ausrichtungen entsprechen.
Werte für den Qualifikator smallest width sind dp, da es auf den verfügbaren Anzeigebereich ankommt, nachdem das System die Pixeldichte berücksichtigt hat (nicht die Rohpixelauflösung).
Die Größen, die Sie mit Ressourcenqualifizierern wie „smallest width“ angeben, entsprechen nicht den tatsächlichen Bildschirmgrößen. Die Größen geben vielmehr die Breite oder Höhe in dp-Einheiten an, die für das Fenster Ihrer App verfügbar sind. Das Android-System verwendet möglicherweise einen Teil des Bildschirms für die System-UI, z. B. die Systemleiste unten auf dem Bildschirm oder die Statusleiste oben. Daher ist möglicherweise nicht der gesamte Bildschirm für Ihr Layout verfügbar. Wenn Ihre App im Mehrfenstermodus verwendet wird, hat sie nur Zugriff auf die Größe des Fensters, das die App enthält. Wenn die Größe des Fensters geändert wird, wird eine Konfigurationsänderung mit der neuen Fenstergröße ausgelöst, sodass das System eine geeignete Layoutdatei auswählen kann. Die von Ihnen deklarierten Größen für Ressourcenqualifizierer sollten also nur den von Ihrer App benötigten Speicherplatz angeben. Das System berücksichtigt den von der System-UI verwendeten Speicherplatz, wenn es Speicherplatz für Ihr Layout bereitstellt.
Verfügbarer Breitenqualifikator
Anstatt das Layout basierend auf der kleinsten Breite des Displays zu ändern, sollten Sie es vielleicht basierend auf der verfügbaren Breite oder Höhe ändern. Sie können beispielsweise ein Layout mit zwei Bereichen verwenden, wenn der Bildschirm mindestens 600 dp breit ist. Das kann sich je nach Ausrichtung des Geräts (Hoch- oder Querformat) ändern. In diesem Fall sollten Sie den Qualifikator available width (verfügbare Breite) so verwenden:
res/layout/main_activity.xml # For phones (smaller than 600dp available width)
res/layout-w600dp/main_activity.xml # For 7" tablets or any screen with 600dp available width
# (possibly landscape phones)
Wenn die verfügbare Höhe für Ihre App ein Problem darstellt, können Sie den Qualifier available height verwenden. Beispiel: layout-h600dp für Bildschirme mit einer Höhe von mindestens 600 dp.
Ausrichtungskennzeichner
Auch wenn Sie möglicherweise alle Größenvariationen nur mit Kombinationen der Qualifizierer kleinste Breite und verfügbare Breite unterstützen können, sollten Sie die Nutzerfreundlichkeit möglicherweise ändern, wenn der Nutzer zwischen Hoch- und Querformat wechselt.
Dazu können Sie den Namen Ihrer Layoutverzeichnisse die Qualifizierer port oder land hinzufügen. Die Orientierungsqualifizierer müssen nach den Größenqualifizierern stehen.
Beispiel:
res/layout/main_activity.xml # For phones res/layout-land/main_activity.xml # For phones in landscape res/layout-sw600dp/main_activity.xml # For 7" tablets res/layout-sw600dp-land/main_activity.xml # For 7" tablets in landscape
Weitere Informationen zu allen Qualifizierern für die Bildschirmkonfiguration finden Sie unter App-Ressourcen – Übersicht.
Klassen für Fenstergrößen
Fenstergrößenklassen sind Breakpoints für den Darstellungsbereich, mit denen Sie adaptive Layouts erstellen können. Die Haltepunkte geben den für Ihre App verfügbaren Anzeigebereich als kompakt, mittel oder erweitert an. Breite und Höhe werden separat angegeben, sodass Ihre App immer eine Fenstergrößenklasse für die Breite und eine Fenstergrößenklasse für die Höhe hat.
So wenden Sie adaptive Layouts programmatisch an:
- Layoutressourcen basierend auf den Haltepunkten für die Fenstergrößenklasse erstellen
- Berechnen Sie die Breiten- und Höhen-Fenstergrößenklassen Ihrer App mit der Funktion
WindowSizeClass#compute()aus der Jetpack WindowManager-Bibliothek. - Layoutressource für die aktuellen Fenstergrößenklassen aufblähen
Weitere Informationen finden Sie unter Klassen für Fenstergrößen.
Modularisierte UI-Komponenten mit Fragmenten
Wenn Sie Ihre App für mehrere Displaygrößen entwickeln, sollten Sie Fragmente verwenden, um die UI-Logik in separate Komponenten zu extrahieren. So vermeiden Sie unnötige Duplikate des UI-Verhaltens in verschiedenen Aktivitäten. Anschließend können Sie Fragmente kombinieren, um Layouts mit mehreren Bereichen auf großen Bildschirmen zu erstellen, oder Fragmente auf kleinen Bildschirmen in separaten Aktivitäten platzieren.
Das Muster „Liste – Details“ (siehe SlidingPaneLayout oben) könnte beispielsweise mit einem Fragment implementiert werden, das die Liste enthält, und einem anderen Fragment, das die Details des Listenelements enthält. Auf großen Bildschirmen können die Fragmente nebeneinander angezeigt werden, auf kleinen Bildschirmen einzeln und bildschirmfüllend.
Weitere Informationen finden Sie in der Übersicht zu Fragmenten.
Aktivitätseinbettung
Wenn Ihre App aus mehreren Aktivitäten besteht, können Sie mit dem Einbetten von Aktivitäten ganz einfach eine adaptive Benutzeroberfläche erstellen.
Bei der Einbettung von Aktivitäten werden mehrere Aktivitäten oder mehrere Instanzen derselben Aktivität gleichzeitig im Aufgabenfenster einer Anwendung angezeigt. Auf großen Bildschirmen können Aktivitäten nebeneinander angezeigt werden, auf kleinen Bildschirmen werden sie übereinander gestapelt.
Sie legen fest, wie Ihre App ihre Aktivitäten anzeigt, indem Sie eine XML-Konfigurationsdatei erstellen, anhand derer das System die geeignete Darstellung basierend auf der Anzeigegröße ermittelt. Alternativ können Sie die Jetpack WindowManager API aufrufen.
Das Einbetten von Aktivitäten unterstützt Änderungen der Geräteausrichtung und faltbare Geräte. Aktivitäten können gestapelt und entstapelt werden, wenn das Gerät gedreht oder gefaltet und entfaltet wird.
Weitere Informationen finden Sie unter Aktivitäten einbetten.
Bildschirmgrößen und Seitenverhältnisse
Testen Sie Ihre App mit verschiedenen Bildschirmgrößen und Seitenverhältnissen, um sicherzustellen, dass die Benutzeroberfläche richtig skaliert wird.
Android 10 (API-Level 29) und höher unterstützen eine Vielzahl von Seitenverhältnissen. Faltbare Formfaktoren können von hohen, schmalen Displays wie 21:9 im zusammengeklappten Zustand bis hin zu einem quadratischen Seitenverhältnis von 1:1 im aufgeklappten Zustand variieren.
Um die Kompatibilität mit möglichst vielen Geräten zu gewährleisten, sollten Sie Ihre Apps mit möglichst vielen der folgenden Seitenverhältnisse testen:
Wenn Sie keinen Zugriff auf Geräte mit allen Bildschirmgrößen haben, die Sie testen möchten, können Sie mit dem Android-Emulator fast jede Bildschirmgröße simulieren.
Wenn Sie lieber auf einem echten Gerät testen möchten, aber kein entsprechendes Gerät haben, können Sie Firebase Test Lab verwenden, um auf Geräte in einem Google-Rechenzentrum zuzugreifen.
Zusätzliche Ressourcen
- Material Design – Layout verstehen