Вопрос проверяет понимание производительности списков и умение проектировать UI для высоконагруженных экранов.
Сложные коллекции часто делают на фреймах из-за производительности и предсказуемости layout. Ячейки в коллекциях пересчитываются очень часто, и Auto Layout в таких условиях становится дорогим. Фреймы позволяют точно контролировать размеры и минимизировать вычисления при reuse. Это особенно важно для лент, каталогов и экранов с большим количеством элементов.
Коллекции — одно из самых чувствительных мест UI с точки зрения производительности. Именно здесь слабые решения проявляются быстрее всего.
UICollectionView и UITableView:
постоянно переиспользуют ячейки
часто вызывают layout
активно работают во время скролла
При этом:
каждая лишняя операция повторяется десятки и сотни раз
даже небольшая задержка масштабируется
Auto Layout в ячейках означает:
пересчёт констрейнтов при каждом reuse
вызовы systemLayoutSizeFitting
возможный layout при каждом изменении контента
Особенно тяжело, если:
ячейка сложная и глубокая
используется несколько UIStackView
включён self-sizing
Фреймовая верстка в ячейках даёт несколько ключевых преимуществ.
Дешёвый layout
простые вычисления
без constraint solving
Предсказуемый размер
высота и ширина известны заранее
меньше сюрпризов при reuse
Контроль над жизненным циклом
layout выполняется один раз в layoutSubviews
легко оптимизировать под конкретный дизайн
Часто используют гибрид:
размеры ячейки считаются в layout’е коллекции
внутри ячейки используется фреймовая верстка
Auto Layout остаётся на уровне экранов
Использование фреймов требует:
ручных расчётов
поддержки dynamic type
аккуратной работы с локализацией
Поэтому фреймы выбирают не “везде”, а именно там, где это оправдано.
Сложные коллекции делают на фреймах, потому что это самый дешёвый и предсказуемый способ верстки при частом reuse и скролле. Производительность здесь важнее удобства декларативного описания.
