В чем минусы Auto Layout в iOS

Что проверяют

Работали ли вы с Auto Layout достаточно глубоко, чтобы видеть его цену. Следом обычно спрашивают, как вы чинили конфликт констрейнтов и чем заменили бы Auto Layout в тяжёлом списке.

Как отвечать

Минусы стоит называть вместе с тем, как с ними жить:

• производительность: раскладка решается как система линейных уравнений (алгоритм Cassowary), и стоимость растёт с числом связанных констрейнтов. Заметно это в ячейках UICollectionView с десятками вьюх при быстром скролле. Помогают плоская иерархия, кеш высот и отказ от пересоздания констрейнтов: вместо удаления и добавления меняют constant или isActive;
• отладка: конфликт даёт в консоли «Unable to simultaneously satisfy constraints» со списком адресов. Выручают identifier у констрейнтов, символьный брейкпоинт UIViewAlertForUnsatisfiableConstraints, View Debugger в Xcode и hasAmbiguousLayout;
• многословность: без обёрток вроде SnapKit код раздувается, а забытый translatesAutoresizingMaskIntoConstraints = false порождает конфликты с автоматически созданными констрейнтами;
• приоритеты: content hugging и compression resistance решают, какой лейбл сожмётся, и без их понимания вёрстка разъезжается на длинном тексте или крупном шрифте;
• сторибоарды: их XML плохо мерджится, поэтому многие команды верстают кодом.

Альтернативы: ручной расчёт фреймов в layoutSubviews для самых горячих экранов, библиотеки вроде PinLayout, для нового кода SwiftUI со своей системой раскладки. Хорошо оговорить, что с iOS 12 Apple заметно ускорила движок, и сейчас тормоза чаще дают не сами констрейнты, а их постоянная пересборка.

Где спотыкаются

Повторяют, что Auto Layout не поддерживается на старых устройствах. Он есть с iOS 6, вопрос совместимости давно закрыт.

Обвиняют Auto Layout в любом лаге скролла, не открыв Instruments. Часто виноваты декодирование картинок или тяжёлая работа на главном потоке.

Не знают, как анимировать констрейнты: поменять constant, затем вызвать layoutIfNeeded() у родителя внутри UIView.animate.