Открыть список
Как стать автором
Обновить

Ручная верстка vs Storyboard/Nib

Разработка под iOS
Большинство разработчиков для iOS знакомы со Storyboard. Apple предлагает использовать его. Но в последнее время, удобство этого инструмента вызывает у меня сомнения.

Ниже я хочу сравнить различные методологии с использованием Storyboard или набора Xib-фалов, с ручной верстой (с использованием autolayout и без). Не претендую на полноту раскрытия темы и буду рад, если вы укажете мне на ошибки и/или предложите другие методологии и критерии сравнения.

Пост не содержит экспериментов, академических вычислений и основывается на моих знаниях и опыте в области iOS разработки. Был бы рад узнать мнения экспертов!

С теми или иными оговорками, существуют следующие методологии разработки:
  • Один Storyboard и все в нем (минимум кода верстки в коде) — используется в небольших проектах; очень неудобен при разработке командой разработчиков.
  • Несколько Storyobard-ов и все в них.
  • Забываем про Storybaord, все UI-контролы помещаем в xib-файлы (см. этот пост).
  • Забываем про Storyboard и Xib, но используем autolayout — привет PureLayouts.
  • Забываем про все Storyboard/Xib/AutoLayouts и настраиваем всем View фреймы в ручную.
  • Забываем про UIKit — используем сторонние решения AsyncDisplayKit от Facebook или ComponentsKit. (Такого опыта у меня нет, поэтому ничего путного не скажу).

Storyboard и Xib

Проблемы:
  1. Большую часть кода, связанного с анимациями туда не поместить.
  2. Если их несколько, то при переходе с одного на другой — создается нагрузка на main thread (NSKeyedArchiver должен распарсить сториборду, а он сам по себе медленный).
  3. Нельзя все сделать в Storybaord при все желании. Например, задать cornerRadius, shadowOffset и т.д.; на самом деле, можно — через user defined runtime attributes (@IBInspectable)

Плюсы:
  1. Верстка наглядна.
  2. User-story виден при просмотре.
  3. SizeClasses
  4. Используем Embedded Segue/Storyboard Reference и живем счастливо
  5. Мы абстрагируемся от типа перехода и для осуществления самого перехода достаточно знать segue identifier (см. RamblerSegues), также, при использовании автоматических dependency injection библиотек (см. typhoon), мы абстрагируемся от внедрения зависимостей.

Ручная верстка с использованием Autolayout-ов

Использовал различные тулы, наиболее, удобные — PureLayout и Cartography (для swift).

Проблемы:
  1. Больше кода (приблизительно в 1.2 раза).
  2. Нет наглядности
  3. Сложный layout превращается в ад

Плюсы:
  1. Немного быстрей — экономим на парсинге Xib/Storyboard файла NSKyedArchiver-ом.
  2. Декларативно и все в одном месте (не нужно постоянно переключаться между Storyboard и текстом).
  3. Удобней делать анимации (например, pan).

Ручная верстка

Проблемы:
  1. При неправильной реализации — есть hardcoded-значения (при правильной, только padding-и и прочее; причем это можно вынести в отдельных header).
  2. Больше кода (приблизительно в 1.5 раза).
  3. Нет наглядности
  4. Сами нужно заботиться об адекватном изменении frame-а при изменении параметров внешней view
  5. Нет SizeClasses

Плюсы:
  1. При правильной реализации все очень гибко.
  2. Работает быстрей.
  3. Можно рассчитать фреймы в background-потоке и просто их потом применить.

Итог

При отказе от каждого из [Stobyboard, Xib, Autolayout] работа усложняется и кода становится больше.

Имеет смысл не использовать Storyboard (не обязательно полностью), если:
  • Делаем сложные анимации (отпадает необходимость кидать кучу outlet-ов).
  • Время восстановления из архива становится критичным.
  • Возникает много костылей (обычно, большая их часть устраняется правильной архитектурой и/или method swizzling-ом).

Имеет смысл, требовательные к ресурсам TableView/CollectionView не делать ни в Storyboard, ни в Xib (мы теряем время на парсинге файла, теряем гибкость). При оптимизации, можно сначала сверстать с использованием autolayouts, но если лаги не проходят — замерить в инструментах, убедиться, что именно layout-ы тормозят, и потом уже переходить на ручной счет.

Иногда, похожее содержимое необходимо отображать как в TableViewCell так и в CollectionViewCell. При ручной верстке это не будет проблемой. А при использовании Xib-а решается, например, так: содержимое ячейки верстаем в xib-файле, а в init-е ячейки вызывать addSubview с данным view.

EDIT:

Подводя итог, можно сказать, что Storyboard имеет следующие преимущества перед ручной версткой:
  • Наглядность (верстка в коде, зачастую, «понятна» только ее автору — см. комментарий DmitrySpb79).
  • Использование нескольких Storyboard позволяет разделить различные user-story и уменьшает вероятность конфликтов при командной разработке.
  • При необходимости использовать в одном из сторибордов конроллер, из другого сториборда — с версии iOS 8 можем использовать Storyboard Reference и этот комментарий от visput; если нужно поддерживать iOS версий < 8, то можно использовать Xib-ы, либо самим как-то реализовать аналог Storyboard Reference


Ручную верстку используем там, где это необходимо, а на фреймы переходим — если autolayout становится узким местом (см. комментарий mish).
Теги:ios xib storyboard
Хабы: Разработка под iOS
Всего голосов 12: ↑9 и ↓3 +6
Просмотры23.1K

Похожие публикации

IOS разработчик
от 100 000 до 150 000 ₽ЭР-Телеком ХолдингМожно удаленно
iOS developer
от 200 000 до 300 000 ₽anonym.networkМожно удаленно
iOS Software Engineer
от 200 000 ₽NUTSonМоскваМожно удаленно
IOS Developer
от 260 000 до 370 000 ₽ТензорМожно удаленно
IOS developer
до 2 500 $G1 SoftwareМожно удаленно

Лучшие публикации за сутки