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

Большинство разработчиков для 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 и т.д.

Плюсы:

1. User-story виден при просмотре.
2. Мы абстрагируемся от типа перехода и для осуществления самого перехода достаточно знать segue identifier (см. RamblerSegues), также, при использовании автоматических dependency injection библиотек (см. typhoon), мы абстрагируемся от зависимостей.

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

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

Проблемы:

1. Больше кода (приблизительно в 1.2 раза).
2. Ваши предложения?

Плюсы:

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

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

Проблемы:

1. При неправильной реализации — есть hardcoded-значения (при правильной, только padding-и и прочее; причем это можно вынести в отдельных header).
2. Больше кода (приблизительно в 1.5 раза).
3. Ваши предложения?

Плюсы:

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

Итог

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

Имеет смысл не использовать Storyboard (не обязательно полностью), если:

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

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

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

Буду рад комментариям!

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.