Introduction

invalidate, requestLayout, and forceLayout affect different stages of Android view rendering, and using the wrong one often causes unnecessary work or visual bugs. The core distinction is simple: redraw versus remeasure and relayout. Understanding when each call is appropriate helps you keep UI smooth and avoid layout thrashing.

Android Rendering Pipeline Refresher

A typical frame pipeline has three phases:

• measure, where views compute desired sizes
• layout, where parent assigns positions and bounds
• draw, where view content is rendered

Each method signals a different pipeline need. Choosing the smallest required signal improves performance.

invalidate: Request Redraw Only

Use invalidate when geometry is unchanged but visual content changed.

1class ProgressRingView(context: Context, attrs: AttributeSet?) : View(context, attrs) {
2    var progress: Float = 0f
3        set(value) {
4            field = value
5            invalidate() // redraw only
6        }
7
8    override fun onDraw(canvas: Canvas) {
9        super.onDraw(canvas)
10        // draw arc based on progress
11    }
12}

No measure or layout pass is requested here.

requestLayout: Request Measure and Layout

Use requestLayout when content change may affect view size or child positions.

1fun updateLabel(newText: String) {
2    label.text = newText
3    requestLayout() // text size may change measured width
4    invalidate()    // redraw with updated text
5}

Many standard widgets call requestLayout internally when size-impacting properties change.

forceLayout: Mark View Dirty for Layout

forceLayout marks a view as requiring layout even if optimization might skip it. It is mostly relevant in advanced custom container code.

1override fun requestLayout() {
2    super.requestLayout()
3    childView.forceLayout()
4}

Overuse can increase layout cost significantly, so reserve it for cases where standard invalidation logic is insufficient.

Decision Guide in Practice

Quick rule:

• style or paint change only: invalidate
• possible size or position change: requestLayout plus usually invalidate
• custom container needing forced subtree re-layout: forceLayout

This rule prevents most accidental over-triggering.

Performance Considerations

Frequent requestLayout calls inside animation loops can cause dropped frames. For high-frequency updates, prefer draw-only changes where possible and batch geometry updates.

If many properties change together, set them first and request layout once. Batching avoids repeated measure and layout passes.

Debugging Layout Problems

Useful debugging techniques:

• Android Studio Layout Inspector
• frame metrics from adb shell dumpsys gfxinfo
• temporary logs in onMeasure, onLayout, and onDraw

If onMeasure fires too often, inspect code for repeated requestLayout calls from observers or text updates.

Avoid Recursive Layout Loops

Calling requestLayout unconditionally from onLayout or onDraw can create loops and jank. Guard calls with state checks and only request layout when geometry-related values actually changed.

1if (newWidth != lastWidth) {
2    lastWidth = newWidth
3    requestLayout()
4}

Defensive checks keep custom view logic stable.

Custom ViewGroup Scenario

In custom containers, one child size change can affect all siblings. In such cases, requesting parent relayout is correct, but forcing every child every frame is not. Use targeted invalidation where possible.

Structure your layout code so expensive recomputation runs only when constraints changed.

Team-Level UI Performance Rules

Set team conventions for when custom views may call requestLayout versus invalidate. Shared rules reduce accidental regressions and make performance reviews faster during UI feature development.

Animation and Layout Tradeoffs

For animations, prefer property updates that avoid full layout passes when possible. Geometry recalculation during every frame can quickly consume rendering budget on lower-end devices.

Common Pitfalls

• Using requestLayout for color or alpha changes that need only redraw.
• Calling only invalidate when size has changed.
• Using forceLayout in normal app code without clear reason.
• Triggering layout requests inside tight animation loops.
• Creating implicit layout recursion from callbacks in onLayout or onDraw.

Summary

• 'invalidate triggers redraw, while requestLayout triggers measure and layout.'
• 'forceLayout is an advanced tool for forced layout dirtiness.'
• Pick the smallest rendering signal that matches actual change.
• Batch geometry updates and avoid unnecessary layout passes.
• Profile rendering behavior to confirm assumptions in custom UI code.