Fenstergrößenklassen sind eine Reihe von vorgegebenen Haltepunkten für den Darstellungsbereich, mit denen Sie responsive/adaptive Layouts entwerfen, entwickeln und testen. Haltepunkteausgleich für ein einfaches Layout und die Flexibilität, deine App für besondere Fälle zu optimieren.
Mithilfe von Fenstergrößenklassen wird der für Ihre App verfügbare Anzeigebereich kategorisiert als compact, medium oder expanded. Verfügbare Breite und Höhe werden klassifiziert Das heißt, Ihre App hat zu jedem Zeitpunkt zwei Fenstergrößen Klassen – eine für die Breite und eine für die Höhe. Die verfügbare Breite beträgt in der Regel mehr aufgrund der Allgegenwärtigkeit des vertikalen Scrollens wichtiger als die verfügbare Höhe. ist die Breite der Fenstergrößen-Klasse wahrscheinlich relevanter für die Benutzeroberfläche Ihrer App.
![](https://developer.android.com/static/develop/ui/compose/images/layouts/adaptive/window-size-classes/window_size_classes_width.png?authuser=6&hl=de)
![](https://developer.android.com/static/develop/ui/compose/images/layouts/adaptive/window-size-classes/window_size_classes_height.png?authuser=6&hl=de)
Wie in den Abbildungen dargestellt, können Sie anhand der Haltepunkte weiter nachdenken. über Layouts in Bezug auf Geräte und Konfigurationen. Jeder Haltepunkt der Größenklasse die meisten der Fälle bei typischen Geräteszenarien, die sehr hilfreich sein können, Bezugsrahmen für das Design der Haltepunkt-basierten Layouts.
Klasse Größe | Haltepunkt | Gerätedarstellung |
---|---|---|
Kompakte Breite | Breite < 600dp | 99,96% der Smartphones im Hochformat |
Mittlere Breite | 600 dp ≤ Breite < 840dp | 93,73% der Tablets im Hochformat,
Die meisten großen aufgeklappten inneren Displays im Hochformat |
Breite nach Expansion | Breite ≥ 840 dp | 97,22% der Tablets im Querformat,
Die meisten aufgeklappten inneren Displays im Querformat |
Kompakte Höhe | Höhe < 480dp | 99,78% der Smartphones im Querformat |
Mittlere Größe | 480 dp ≤ Höhe < 900dp | 96,56% der Tablets im Querformat,
97,59% der Smartphones im Hochformat |
Höhe bei Maximierung | Höhe ≥ 900 dp | 94,25% der Tablets im Hochformat |
Obwohl die Visualisierung von Größenklassen als physische Geräte nützlich sein kann, Klassen werden nicht explizit durch die Größe des Gerätebildschirms bestimmt. Fenster Größenklassen sind nicht für Logik vom Typ isTablet vorgesehen. Stattdessen sollten Sie Größenklassen werden durch die Fenstergröße bestimmt, die Ihrer Anwendung zur Verfügung steht. unabhängig vom Gerätetyp, auf dem die App ausgeführt wird. Auswirkungen:
Physische Geräte garantieren keine bestimmte Fenstergrößenklasse. Die der für deine App verfügbaren Bildschirmgröße von der Bildschirmgröße des gibt es viele Gründe. Auf Mobilgeräten kann der Splitscreen-Modus den Bildschirm zwischen zwei Anwendungen aufteilen. Unter ChromeOS können Android-Apps werden in Freiform-Fenstern angezeigt, deren Größe beliebig geändert werden kann. Auf faltbaren Geräten können zwei Bildschirme mit unterschiedlicher Größe einzeln aufgerufen werden indem Sie das Gerät zu- oder aufklappen.
Die Fenstergrößenklasse kann sich im Laufe der Lebensdauer deiner App ändern. Während die App ausgeführt wird, ändert sich die Ausrichtung des Geräts, Multitasking und Durch Zusammen- oder Zuklappen kann sich der verfügbare Platz auf dem Bildschirm verändern. Als ist die Fenstergrößenklasse dynamisch und die Benutzeroberfläche Ihrer App sollte sich entsprechend anpassen.
Die Fenstergrößenklassen werden den Haltepunkten „Kompakt“, „Mittel“ und „Maximiert“ in der Material Design-Layout Anleitung. Sie können Fenstergrößenklassen verwenden, um Anwendungslayout-Entscheidungen z. B. ob Sie ein bestimmtes kanonisches Layout verwenden, und mehr Platz auf dem Bildschirm.
Sie können den aktuellen WindowSizeClass
mit der WindowSizeClass#compute()
-Funktion der Jetpack WindowManager-Bibliothek berechnen. Das folgende Beispiel zeigt, wie die Fenstergrößenklasse berechnet wird und Aktualisierungen erhalten, wenn sich die Fenstergrößenklasse ändert:
Kotlin
class MainActivity : Activity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // ... // Replace with a known container that you can safely add a // view to where the view won't affect the layout and the view // won't be replaced. val container: ViewGroup = binding.container // Add a utility view to the container to hook into // View.onConfigurationChanged(). This is required for all // activities, even those that don't handle configuration // changes. You can't use Activity.onConfigurationChanged(), // since there are situations where that won't be called when // the configuration changes. View.onConfigurationChanged() is // called in those scenarios. container.addView(object : View(this) { override fun onConfigurationChanged(newConfig: Configuration?) { super.onConfigurationChanged(newConfig) computeWindowSizeClasses() } }) computeWindowSizeClasses() } private fun computeWindowSizeClasses() { val metrics = WindowMetricsCalculator.getOrCreate().computeCurrentWindowMetrics(this) val width = metrics.bounds.width() val height = metrics.bounds.height() val density = resources.displayMetrics.density val windowSizeClass = WindowSizeClass.compute(width/density, height/density) // COMPACT, MEDIUM, or EXPANDED val widthWindowSizeClass = windowSizeClass.windowWidthSizeClass // COMPACT, MEDIUM, or EXPANDED val heightWindowSizeClass = windowSizeClass.windowHeightSizeClass // Use widthWindowSizeClass and heightWindowSizeClass. } }
Java
public class MainActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // ... // Replace with a known container that you can safely add a // view to where the view won't affect the layout and the view // won't be replaced. ViewGroup container = binding.container; // Add a utility view to the container to hook into // View.onConfigurationChanged(). This is required for all // activities, even those that don't handle configuration // changes. You can't use Activity.onConfigurationChanged(), // since there are situations where that won't be called when // the configuration changes. View.onConfigurationChanged() is // called in those scenarios. container.addView(new View(this) { @Override protected void onConfigurationChanged(Configuration newConfig) { super.onConfigurationChanged(newConfig); computeWindowSizeClasses(); } }); computeWindowSizeClasses(); } private void computeWindowSizeClasses() { WindowMetrics metrics = WindowMetricsCalculator.getOrCreate() .computeCurrentWindowMetrics(this); int width = metrics.getBounds().width int height = metrics.getBounds().height() float density = getResources().getDisplayMetrics().density; WindowSizeClass windowSizeClass = WindowSizeClass.compute(width/density, height/density) // COMPACT, MEDIUM, or EXPANDED WindowWidthSizeClass widthWindowSizeClass = windowSizeClass.getWindowWidthSizeClass() // COMPACT, MEDIUM, or EXPANDED WindowHeightSizeClass heightWindowSizeClass = windowSizeClass.getWindowHeightSizeClass() // Use widthWindowSizeClass and heightWindowSizeClass. } }
Fenstergrößenklassen testen
Wenn Sie Layoutänderungen vornehmen, testen Sie das Layoutverhalten für alle Fenstergrößen, insbesondere bei den Haltepunktbreiten "Kompakt", "Mittel" und "Maximiert".
Wenn Sie bereits ein Layout für kompakte Bildschirme haben, optimieren Sie zunächst Ihr Layout. für die Klassenklasse nach maximierter Breite, da diese Klasse den meisten Platz . Entscheiden Sie dann, welches Layout der Größenklasse mittlerer Breite, ein spezielles Layout hinzufügen.
Nächste Schritte
Weitere Informationen zur Verwendung von Fenstergrößenklassen zum Erstellen responsiv/adaptiv finden Sie hier:
Für auf dem E-Mail-Editor basierende Layouts: Unterstützung verschiedener Bildschirmgrößen
Für ansichtsbasierte Layouts: Responsives/adaptives Design mit Ansichten
Weitere Informationen dazu, warum eine App für alle Geräte und Bildschirmgrößen geeignet ist, Siehe: