Что происходит после вызова requestLayout

Обзор процесса requestLayout

Вызов метода requestLayout() — это механизм, с помощью которого View уведомляет систему о необходимости пересчитать свою позицию и размеры (layout). Это запускает цепочку событий, которая в конечном итоге приводит к выполнению measure и layout проходов для обновления иерархии представлений. Процесс затрагивает всю цепочку родительских представлений вплоть до корневого View (обычно DecorView).

Последовательность событий после requestLayout()

1. Пометка View как "требующей перераспределения" При вызове requestLayout() текущая View устанавливает внутренние флаги PFLAG_FORCE_LAYOUT и PFLAG_INVALIDATED. Эти флаги указывают системе, что представление и его родители должны пройти этапы измерения и размещения в следующем цикле макета.

   public void requestLayout() {
       // Устанавливаем флаги
       mPrivateFlags |= PFLAG_FORCE_LAYOUT;
       mPrivateFlags |= PFLAG_INVALIDATED;
       
       if (mParent != null && !mParent.isLayoutRequested()) {
           // Рекурсивно запрашиваем layout у родителей
           mParent.requestLayout();
       }
   }
   

2. Распространение запроса вверх по иерархии Метод рекурсивно вызывает requestLayout() у родительского представления (mParent), пока не достигнет корневого View (ViewRootImpl). Это гарантирует, что вся цепочка родителей будет перерассчитана, так как изменение одного дочернего элемента может повлиять на расположение других.

3. Планирование выполнения в ViewRootImpl ViewRootImpl — это связующее звено между WindowManager и иерархией View. При получении requestLayout() он планирует выполнение traversal (прохода) через Choreographer на следующий кадр отрисовки.

   // Во ViewRootImpl
   void scheduleTraversals() {
       if (!mTraversalScheduled) {
           mTraversalScheduled = true;
           // Запрос на выполнение в следующем кадре
           mChoreographer.postCallback(
               Choreographer.CALLBACK_TRAVERSAL,
               mTraversalRunnable,
               null
           );
       }
   }
   

4. Выполнение traversal в следующем цикле отрисовки Когда наступает время отрисовки кадра, Choreographer запускает запланированный traversal. ViewRootImpl выполняет три ключевых этапа в строгом порядке:

   • performMeasure(): вычисление размеров для всех View.
   • performLayout(): определение позиций для всех View.
   • performDraw(): отрисовка (может быть отложена, если не было invalidate).

Ключевые этапы traversal

1. Этап измерения (measure)

Система проходит по всем View, вызывая measure() для каждого. Внутри measure() View вычисляет свои размеры на основе:

• MeasureSpec от родителя (ограничения и режимы)
• Собственных требований (минимальные размеры, padding, размеры содержимого)

protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    // Пример: измерение с учетом фона и минимальных размеров
    int minWidth = getSuggestedMinimumWidth();
    int minHeight = getSuggestedMinimumHeight();
    
    int width = resolveSizeAndState(minWidth, widthMeasureSpec, 0);
    int height = resolveSizeAndState(minHeight, heightMeasureSpec, 0);
    
    setMeasuredDimension(width, height);
}

2. Этап размещения (layout)

После измерения система вызывает layout() для каждого View, передавая вычисленные координаты (left, top, right, bottom).

public void layout(int l, int t, int r, int b) {
    // Сравниваем с текущими координатами
    if (changed || (mPrivateFlags & PFLAG_FORCE_LAYOUT) != 0) {
        // Вызываем onLayout (для ViewGroup размещает дочерние элементы)
        onLayout(changed, l, t, r, b);
        // Сбрасываем флаги
        mPrivateFlags &= ~PFLAG_FORCE_LAYOUT;
    }
}

Важные аспекты производительности

• Оптимизация через флаги: Система отслеживает, какие View действительно нуждаются в перерасчете, используя внутренние флаги (PFLAG_MEASURED_DIMENSION_SET, PFLAG_LAYOUT_REQUIRED).
• Отмена избыточных запросов: Если requestLayout() вызывается несколько раз до следующего кадра, система объединяет их в один traversal.
• Связь с invalidate(): requestLayout() не гарантирует немедленную перерисовку. Для этого нужно вызвать invalidate(), который помечает область как "грязную" и запускает performDraw().
• Рекурсивная природа: Изменение размера одного View может вызвать цепную реакцию, затрагивающую всех его соседей и родителей.

Типичные сценарии использования

Вызов requestLayout() необходим когда:

• Изменяется содержимое View, влияющее на её размеры
• Модифицируются параметры макета (margin, padding, visibility)
• Динамически изменяется размер на основе контента
• Происходит изменение в ConstraintLayout или других сложных layout-менеджерах

Понимание внутренней работы requestLayout() критически важно для оптимизации производительности UI, так как необоснованные вызовы этого метода могут привести к "layout thrashing" — многократным перерасчетам макета в одном кадре, что вызывает заметные лаги в интерфейсе.