Ответ
Преимущества:
- Производительность и простота: Прямое присвоение
CGRectне требует вычислительно дорогого процесса разрешения констрейнтов (layout pass). - Полный контроль: Точное управление позицией и размером, что идеально для кастомных, нестандартных анимаций.
- Прозрачность: Значения
originиsizeзаданы явно, что упрощает понимание и отладку. - Минимальный оверхед: Отсутствие дополнительных объектов (
NSLayoutConstraint) и связанных с ними вычислений.
Недостатки:
- Отсутствие адаптивности: Необходимо вручную пересчитывать фреймы для разных размеров экранов, ориентаций и контента.
- Трудоемкость поддержки: Любое изменение в дизайне или добавление нового размера экрана требует ручных правок во многих местах кода.
- Абсолютные координаты: Нет встроенной поддержки относительного позиционирования (например, "растянуть по ширине родителя").
- Поворот устройства: Требуется ручная обработка изменений bounds в методах вроде
viewWillLayoutSubviews().
Пример:
// Просто, быстро, но абсолютно не адаптивно
view.frame = CGRect(x: 20, y: 100, width: 200, height: 50)Ответ 18+ 🔞
А, слушай, вот эта ваша хвалёная ручная расстановка фреймов! Ну, типа, классика жанра, старый добрый способ, когда ты сам, как бог, указываешь каждому виду его священные координаты. Прям как в старые добрые времена, когда интерфейсы рисовали в Interface Builder'е мышкой, блядь.
Что тут, сука, хорошо, а что — пиздец как плохо:
Плюсы, их, блядь, раз-два и обчёлся:
- Быстро и без мозгоёбства: Ты просто пишешь
CGRect(x: 20, y: 100, width: 200, height: 50), и система, не раздумывая, ставит вид именно туда. Никаких этих ваших констрейнтов, которые надо решать, как систему уравнений, блядь. Просто хуяк — и готово. Для анимаций, где надо прыгать по пикселям, — вообще идеально, ёпта. - Ты тут главный: Хочешь поставить кнопку ровно на 3.14 пикселя левее — пожалуйста. Полный контроль, как у сапёра с миноискателем. Всё прозрачно:
originиsizeлежат перед тобой, как на ладони. - Лёгкий, как пёрышко: Никаких лишних объектов констрейнтов в памяти не болтается, система не тратит время на их расчёты. Минимальный оверхед, чистая математика.
А теперь, блядь, ложка дёгтя размером с лопату:
- Адаптивность? Не, не слышал: Это главная, блядь, проблема. Ты написал
width: 200для iPhone 8. А потом приходит заказчик и говорит: "А на iPad'е чтобы было красиво". И ты сидишь, блядь, и высчитываешь: "Так, ширина экрана 1024, отнять 20 пикселей слева, 20 справа...". А потом приходит iPhone SE 1-го поколения, и всё едет к ебеням, в рот меня чих-пых! - Поддержка — адский труд: Захотел дизайнер передвинуть лейбл на 5 пикселей вниз. А у тебя этот лейбл в десяти местах кода упомянут, и в каждом нужно менять
y. Пиздец, а не работа. Добавить поддержку новой ориентации экрана? Да ты издеваешься! - Всё абсолютно: Нет тут никакого "растянись по ширине родителя" или "встань по центру". Всё, блядь, вручную. Хочешь центрировать — готовь калькулятор:
(parentWidth - childWidth) / 2. Ёперный театр! - Поворот устройства — отдельная песня: Тебе самому, вручную, в методах вроде
viewWillLayoutSubviews()нужно ловить момент, когда bounds поменялись, и заново, блядь, всё пересчитывать и переставлять. Удовольствие ниже плинтуса.
Короче, пример, на котором всё видно:
// Сделано. Быстро. Но если экран поменяется — вид останется тут, как памятник, и будет смотреться как хуй в пальто.
view.frame = CGRect(x: 20, y: 100, width: 200, height: 50)Вот и думай теперь, нужна тебе эта скорость и контроль, или же, блядь, спокойная жизнь с адаптивными констрейнтами.