Всем привет! Месяц назад
Apple провела митап с глубоким разбором производительности
SwiftUI. Сегодня обсудим самое важное, что вы могли пропустить.
Суть проблемы:
SwiftUI не тормозит сам по себе. Проблемы начинаются, когда логика обновлений UI выходит из-под контроля. Каждая лишняя перерисовка
View - это работа для системы, которая копится и превращается в лаги.
Что важно знать:
- Observable - новая базовая модель для состояния. Забудьте о @StateObject для разделяемых данных. Класс с @Observable дает точный контроль: вью обновится только если она читает конкретное измененное свойство. Это резко снижает количество нежелательных перерисовок.
- Замыкания во View - это новые зависимости. Передавая ViewBuilder (замыкание), которое захватывает, например self, вы создаете новую зависимость при каждом обновлении родителя. Это заставляет SwiftUI пересчитывать дочернюю вью, даже если ее внешний вид не изменился. Решение: по возможности передавайте уже готовую вью, а не замыкание для ее построения.
- Обработчики скролла, анимаций, жестов - это зона повышенного внимания для оптимизации. Прямое изменение @State или запись в Environment в таких местах запускает каскад проверок и перерисовок по всему дереву вьюх. Вместо этого выносите часто меняющиеся данные в отдельные, минимальные по объему вьюхи или передавайте их через Observable‑классы - это ограничит зону обновления только теми компонентами, которые действительно зависят от этих данных.
Вывод:
Для достижения плавного интерфейса недостаточно проектировать только внешний вид, необходимо сознательно проектировать поток обновлений данных. Ключевая задача - сделать так, чтобы каждое изменение состояния затрагивало минимально необходимый набор вьюх, а не вызывало каскадную перерисовку.
Как проверить: используйте
Instruments с шаблоном
SwiftUI. Ваш главный ориентир не общее время выполнения, а столбец
Updates. Если видите, что какая-либо вьюха обновляется десятки раз без визуальных изменений - вы нашли точку для немедленной оптимизации.
