XML Layouts

Why XML Layouts?

Android separates UI definition from business logic. XML files declare what the screen looks like, and Kotlin/Java code handles behavior. This separation means designers can work on layouts while developers write logic, and the same layout can adapt to different screen configurations without code changes.

The Activity–Layout Relationship

When an Activity starts, it calls setContentView() with a layout resource ID. The Android framework inflates the XML into a hierarchy of View and ViewGroup objects at runtime.

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

The generated R.layout.activity_main reference points to res/layout/activity_main.xml.

Anatomy of an XML Layout

Every layout XML file has a root element—typically a ViewGroup—that contains child views:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:padding="16dp">

    <TextView
        android:id="@+id/title"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Hello World"
        android:textSize="24sp" />

    <Button
        android:id="@+id/submitBtn"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Submit" />
</LinearLayout>

Every view requires two layout attributes:

• layout_width — how wide the view should be (match_parent, wrap_content, or a fixed dp value)
• layout_height — how tall the view should be (same options)

Key Dimensions in Android

Always use dp for layout and sp for text. Android runs on devices with wildly different pixel densities; these units ensure consistent physical sizing.

LinearLayout

LinearLayout arranges children in a single direction—either horizontal or vertical. Each child occupies one slot, and you control distribution with layout_weight.

<LinearLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="horizontal">

    <Button
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:text="Left" />

    <Button
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_weight="1"
        android:text="Right" />
</LinearLayout>

Set layout_width="0dp" with layout_weight="1" on each child to split space equally. Weight distributes remaining space after measured sizes, so the first child's weight allocation depends on what space is left.

Common mistake: Setting layout_height="wrap_content" with layout_weight in a vertical LinearLayout. This forces a double measurement pass, which slows down inflation on complex screens.

FrameLayout

FrameLayout stacks children on top of each other. Each child is positioned relative to the parent's edges. This makes FrameLayout ideal for overlays—progress indicators floating on content, badges on icons, or single-child containers that need a background.

<FrameLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <ImageView
        android:layout_width="match_parent"
        android:layout_height="200dp"
        android:scaleType="centerCrop"
        android:src="@drawable/hero_image" />

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom|start"
        android:layout_margin="12dp"
        android:text="Featured"
        android:background="#80000000"
        android:padding="8dp"
        android:textColor="@android:color/white" />
</FrameLayout>

Use layout_gravity to position a child within the FrameLayout (as opposed to gravity, which positions content inside the view itself).

ConstraintLayout

ConstraintLayout positions views by defining relationships (constraints) between views and the parent. It replaces deeply nested LinearLayout hierarchies with a flat structure, which Android inflates faster.

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

    <ImageView
        android:id="@+id/avatar"
        android:layout_width="80dp"
        android:layout_height="80dp"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        android:layout_margin="16dp" />

    <TextView
        android:id="@+id/name"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        app:layout_constraintStart_toEndOf="@id/avatar"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintTop_toTopOf="@id/avatar"
        android:layout_marginStart="12dp"
        android:text="Jane Smith" />
</androidx.constraintlayout.widget.ConstraintLayout>

Every view needs at least one horizontal and one vertical constraint. A missing constraint causes the view to jump to position 0,0 at runtime.

When to Use Which

Why Nesting Hurts

Every time you nest a ViewGroup inside another ViewGroup, Android performs an extra measurement pass during layout inflation. Two levels of nesting isn't a problem, but five levels of LinearLayout inside LinearLayout inside FrameLayout creates a combinatorial explosion of measure calls.

A layout with depth 5 and three children per level requires 3^5 = 243 measure passes. The same UI built with a flat ConstraintLayout hierarchy requires a single pass.

Flattening with ConstraintLayout

Before ConstraintLayout, you might build a login screen like this:

<!-- BAD: Deep nesting -->
<LinearLayout vertical>
    <FrameLayout>
        <LinearLayout horizontal>
            <LinearLayout vertical>
                <EditText />
                <EditText />
            </LinearLayout>
        </LinearLayout>
    </FrameLayout>
</LinearLayout>

The equivalent ConstraintLayout version eliminates every intermediate container:

<!-- GOOD: Flat hierarchy -->
<androidx.constraintlayout.widget.ConstraintLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <EditText
        android:id="@+id/email"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        android:hint="Email" />

    <EditText
        android:id="@+id/password"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintTop_toBottomOf="@id/email"
        android:hint="Password"
        android:inputType="textPassword" />
</androidx.constraintlayout.widget.ConstraintLayout>

Layout Inspector

When performance feels sluggish, use Android Studio's Layout Inspector (Tools → Layout Inspector) to see the actual view hierarchy at runtime. It shows:

• The nesting depth of your views
• How long each view took to measure and draw
• The actual runtime layout bounds

Key Best Practices

1. Keep hierarchy under 10 levels deep — measured in real device time, not just nesting count
2. Use ViewStub for optional sections — they inflate only when needed, keeping initial load fast
3. Prefer ConstraintLayout over nested LinearLayouts — flat is always faster
4. Use merge tags when inflating reusable components — avoids an unnecessary wrapper ViewGroup
5. Test on low-end devices — a 200ms inflation penalty is invisible on a Pixel 8 but brutal on a $50 device