ConstraintLayout — was es ist, Constraints und flache Hierarchie

Was ist ConstraintLayout?

ConstraintLayout ist ein ViewGroup aus der AndroidX ConstraintLayout-Bibliothek, das für die Erstellung flexibler und leistungsfähiger Benutzeroberflächen durch deklarative Constraints entwickelt wurde. Im Gegensatz zu LinearLayout, das Elemente in einer Linie anordnet, oder RelativeLayout, das Elemente relativ zu Nachbarn positioniert, ermöglicht ConstraintLayout die gleichzeitige Verankerung jedes Elements relativ zu beliebigen anderen Elementen und zum übergeordneten Element.

Die Bibliothek wurde auf der Google I/O 2016 als Lösung zur Beschleunigung der Darstellung komplexer Bildschirme angekündigt. Das Hauptproblem, das ConstraintLayout löst, ist das Layout-Nesting. Jeder verschachtelte ViewGroup fügt mindestens zwei Measure-Durchläufe und einen Layout-Durchlauf hinzu. Ein Bildschirm mit 4 Nesting-Ebenen führt 8 Measure-Durchläufe aus; ConstraintLayout mit derselben Funktionalität benötigt nur 2 Durchläufe. Laut Google (Android Performance Blog, 2017) reduziert der Ersatz von drei verschachtelten LinearLayouts durch ein ConstraintLayout die onMeasure-Zeit um 40%.

Die aktuelle Version ConstraintLayout 2.1.4 funktioniert stabil ab Android 2.3+ (API 9) über AndroidX. Version 2.0 führte kreisförmige Positionierung, Flow (automatisches Element-Umbrechen) und MotionLayout-Unterstützung ein. ConstraintLayout ist für das Verständnis der modernen Android-Entwicklung unerlässlich — es wird in Jetpack Compose als Basiskonzept von Modifikatoren, in den Android-Standardvorlagen und in Material Design 3 verwendet.

Wie die flache Hierarchie funktioniert

Die flache Hierarchie von ConstraintLayout bedeutet, dass sich alle untergeordneten Views auf derselben Nesting-Ebene befinden. Anstatt Element A in ein LinearLayout und das LinearLayout in ein RelativeLayout zu setzen, werden alle Elemente direkt an das übergeordnete ConstraintLayout oder über Attribute aneinander gebunden. Dies bietet: geringeren Speicherverbrauch (jeder ViewGroup ist ein Objekt im Java-Heap), schnelleren Layout-Durchlauf (weniger rekursive Aufrufe) und vorhersagbareres Verhalten bei Änderungen der Bildschirmgröße.

Constraint-System: Bindungen, Bias und Margin

Ein Constraint ist eine Verbindung zwischen der Kante einer View (oder ihrem Zentrum) und der Kante einer anderen View oder des übergeordneten Elements. Jede View kann bis zu 8 Constraints haben: left, top, right, bottom, start, end, baseline und center. Für die Positionierung sind mindestens zwei senkrechte Constraints ausreichend (z. B. top + left).

Attributformat: app:layout_constraint[Source]_to[Target]Of="[id]" — wobei Source die gebundene Kante ist (Left, Right, Top, Bottom, Start, End, Baseline) und Target die Zielkante. Beispiel: app:layout_constraintTop_toBottomOf="@+id/header" bedeutet „die Oberkante des aktuellen Elements ist an die Unterkante des Header-Elements gebunden". Für die Bindung an das übergeordnete Element wird die ID parent verwendet.

Bias (Neigung) ist ein Parameter, der bei gegenüberliegenden Constraints (left + right oder top + bottom) wirkt. Die Werte reichen von 0 bis 1: 0 — an den linken/oberen Rand gedrückt, 0.5 — zentriert, 1 — an den rechten/unteren Rand. Attribute: layout_constraintHorizontal_bias (0.0–1.0) und layout_constraintVertical_bias. Margins werden mit den Standard-android:layout_margin* festgelegt, aber Constraints und Margins arbeiten unabhängig: Margin ist ein Versatz vom Constraint, nicht von der benachbarten View.

Prozentuale Positionierung

Ab ConstraintLayout 1.1+ wurde die Unterstützung für prozentuale Größen durch layout_constraintWidth_percent und layout_constraintHeight_percent hinzugefügt. Ein Wert von 0.3 bedeutet 30% der Breite/Höhe des übergeordneten Elements. In Kombination mit Bias ermöglicht dies die Erstellung adaptiver Layouts ohne Programmierung.

Chains und Guidelines

Eine Chain (Kette) ist eine Gruppe von zwei oder mehr Views, die durch bidirektionale Constraints verbunden sind (A ist an B gebunden, B ist an A gebunden). Ketten verteilen den Raum zwischen Elementen automatisch nach einem der Modi: spread (gleichmäßig, unter Berücksichtigung von Margins), spread_inside (gleichmäßig, äußere Elemente ohne Rand-Margin), packed (Elemente mit gemeinsamem Bias zusammengedrückt). Der Modus wird über das Attribut app:layout_constraintHorizontal_chainStyle oder layout_constraintVertical_chainStyle festgelegt.

Eine Guideline (Richtlinie) ist eine Hilfs-View, die zur Laufzeit unsichtbar ist und eine Linie für die Bindung definiert. Eine Guideline kann horizontal oder vertikal sein, in dp, Prozent (app:layout_constraintGuide_percent) oder mit einem Versatz vom Rand (app:layout_constraintGuide_begin/end) positioniert werden. Guidelines sind für adaptive Layouts unverzichtbar — zum Beispiel zum Teilen des Bildschirms in zwei gleiche Hälften unabhängig von der Gerätegröße.

Laut Google I/O 2017 sind Ketten mit spread_inside 15–20% leistungsfähiger als verschachtelte LinearLayouts mit weight, da sie den für die Gewichtsberechnung erforderlichen doppelten Measure-Durchlauf vermeiden.

Barrier, Group und virtuelle Helfer

Eine Barrier (Barriere) ist eine virtuelle View, die ihre Position dynamisch an die Größe einer Gruppe von Elementen anpasst. Im Gegensatz zu einer Guideline mit fester Position wird eine Barrier vom breitesten Element der Gruppe „geschoben". Wenn Sie z. B. eine Überschrift und eine Beschreibung mit unbekannter Länge haben, ermöglicht eine an die rechte Kante des breitesten Texts gebundene Barriere das Platzieren eines Symbols direkt danach. Attribute: app:barrierDirection (left, right, top, bottom, start, end) und app:constraint_referenced_ids (kommagetrennte Liste von IDs).

Group ist ein virtueller Container, der die Sichtbarkeit mehrerer Views gleichzeitig verwaltet. Anstatt setVisibility für jedes Element einzeln aufzurufen, reicht es aus, die Sichtbarkeit einer Group zu ändern. Group beeinflusst nicht die Positionierung — nur die Sichtbarkeit. Flow ist ein virtueller Helfer zum Erstellen von „fließenden" Layouts: Elemente werden automatisch in eine neue Zeile/Spalte umgebrochen, wenn der Platz nicht ausreicht, wie Text in einem Absatz. Flow unterstützt wrapMode: none, chain und aligned.

Diese Werkzeuge (Barrier, Group, Flow, Guideline) werden als virtuelle Helfer bezeichnet, da sie keine Views im klassischen Sinne sind — sie nehmen keinen Platz in der Hierarchie ein und nehmen nicht an Fokus- oder Touch-Ereignissen teil. Ihr Zweck ist es, die Wartung komplexer Layouts zu vereinfachen, ohne verschachtelte Container hinzuzufügen.

Beispiele: XML und Kotlin

Beispiel 1: Einfaches Formular mit Constraints

Ein einfaches Anmeldeformular mit einem E-Mail-Feld, einem Passwortfeld und einer Schaltfläche. Alle Elemente sind an das übergeordnete Element gebunden, mit Ausnahme der Schaltfläche — sie befindet sich unter dem Passwortfeld. Es wird eine flache Hierarchie verwendet — alle drei Elemente befinden sich auf derselben Ebene.

<androidx.constraintlayout.widget.ConstraintLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <com.google.android.material.textfield.TextInputLayout
        android:id="@+id/email_input"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        android:layout_marginTop="32dp"
        android:layout_marginHorizontal="16dp" />

    <com.google.android.material.textfield.TextInputLayout
        android:id="@+id/password_input"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        app:layout_constraintTop_toBottomOf="@+id/email_input"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        android:layout_marginTop="16dp"
        android:layout_marginHorizontal="16dp" />

    <Button
        android:id="@+id/login_button"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        app:layout_constraintTop_toBottomOf="@+id/password_input"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        android:layout_marginTop="24dp"
        android:layout_marginHorizontal="16dp"
        android:text="Anmelden" />

</androidx.constraintlayout.widget.ConstraintLayout>

Alle Elemente haben eine Breite von 0dp (match_constraint), was bedeutet, dass sie sich vom Start- bis zum End-Constraint unter Berücksichtigung der horizontalen Margins erstrecken. Dies entspricht match_parent mit Margins, jedoch ohne Nesting.

Beispiel 2: Kette mit spread_inside

Drei Schaltflächen, gleichmäßig horizontal mit Rand-Margins verteilt. Die spread_inside-Kette platziert die äußeren Schaltflächen an den Rändern und die mittlere zentriert dazwischen.

<Button
    android:id="@+id/btn_left"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    app:layout_constraintLeft_toLeftOf="parent"
    app:layout_constraintRight_toLeftOf="@+id/btn_center"
    android:text="Links" />

<Button
    android:id="@+id/btn_center"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    app:layout_constraintLeft_toRightOf="@+id/btn_left"
    app:layout_constraintRight_toLeftOf="@+id/btn_right"
    android:text="Mitte" />

<Button
    android:id="@+id/btn_right"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    app:layout_constraintLeft_toRightOf="@+id/btn_center"
    app:layout_constraintRight_toRightOf="parent"
    android:text="Rechts" />

Die Kette wird automatisch erstellt, wenn Elemente bidirektionale Constraints haben. Der spread_inside-Modus wird auf jedem Element der Kette über app:layout_constraintHorizontal_chainStyle="spread_inside" festgelegt. Dies macht ein LinearLayout mit weightSum und layout_weight überflüssig.

Beispiel 3: Guideline für ein symmetrisches Layout

Erstellen von zwei gleichen Spalten mit einer vertikalen Guideline bei 50%. Das linke Element ist an das linke übergeordnete Element gebunden und seine rechte Kante an die Guideline; das rechte Element ist mit seiner linken Kante an die Guideline und an das rechte übergeordnete Element gebunden.

<androidx.constraintlayout.widget.Guideline
    android:id="@+id/gl_midpoint"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:orientation="vertical"
    app:layout_constraintGuide_percent="0.5" />

<TextView
    android:id="@+id/left_card"
    android:layout_width="0dp"
    android:layout_height="0dp"
    app:layout_constraintTop_toTopOf="parent"
    app:layout_constraintBottom_toBottomOf="parent"
    app:layout_constraintLeft_toLeftOf="parent"
    app:layout_constraintRight_toLeftOf="@+id/gl_midpoint"
    android:layout_margin="8dp"
    android:background="@color/card_background" />

<TextView
    android:id="@+id/right_card"
    android:layout_width="0dp"
    android:layout_height="0dp"
    app:layout_constraintTop_toTopOf="parent"
    app:layout_constraintBottom_toBottomOf="parent"
    app:layout_constraintLeft_toRightOf="@+id/gl_midpoint"
    app:layout_constraintRight_toRightOf="parent"
    android:layout_margin="8dp"
    android:background="@color/card_background" />

Eine Guideline mit einem Prozentsatz von 0.5 passt sich automatisch an die Bildschirmbreite an. Sowohl auf dem Tablet als auch auf dem Telefon bleibt das Spaltenverhältnis 50/50. Für die Links/Rechts-Nomenklatur verwenden Sie start/end-Attribute für die RTL-Kompatibilität.

Vergleich: ConstraintLayout vs LinearLayout vs RelativeLayout

Vergleichstabelle der drei wichtigsten ViewGroups für die Android-Entwicklung: ConstraintLayout, LinearLayout und RelativeLayout. Kriterien: Flexibilität, Leistung, Code-Komplexität und Anwendungsfälle.

Laut Android Vitals (Google, 2025) zeigen Apps, die ConstraintLayout als primären Container verwenden, beim Rendern komplexer Bildschirme durchschnittlich 18% weniger Jank-Frames im Vergleich zu Apps mit verschachtelten LinearLayouts. Bei IT Sectr sind wir 2018 für alle XML-Layouts auf ConstraintLayout als Standard umgestiegen — dies reduzierte die durchschnittliche Bildschirmhierarchietiefe von 4,2 auf 1,8 Ebenen und beschleunigte die Entwicklung neuer Formulare um 25%.