есть не только про стороны раскадровки, но и минусы-только потому, что вы попросили ввода:

• нелегко работать с SBs в команде, так как только один участник может работать с SB сразу (потому что это один файл).

- следующее не соответствует действительности: - если вам нужно делать то, что SB не предлагает, не совсем легко смешать SB с программными созданными представлениями (ну, это возможно)

основное правило кажется: чем сложнее ваш проект, тем больше вам лучше не ходить в СБ.

изменить: - еще один недостаток SB: работа вокруг всех раздражающих ошибок XCode в отношении SB. Например, необходимость часто очищать папку DerivedData из-за нескольких несоответствий. Иногда файлы раскадровки или ссылка на них повреждаются. Тогда у вас может быть радость искать проблему. Взгляните на это поток, чтобы получить идея

EDIT 2 (март 2013): между тем раскадровки и Xcode работают намного лучше, а документация и лучшие практики широко распространены. Я думаю, что работа с раскадровкой может быть рекомендована для большинства проектов, даже если есть еще некоторые глюки.

EDIT 3 (Sept 2013): теперь с новым форматом Xcode 5 Работа в командах с SB может стать еще лучше, так как это, кажется, стало возможным объединить SB-код намного проще сейчас.

другое редактирование: ну, если у вас есть час времени, сядьте, расслабьтесь и послушайте, как эти ребята обсуждают эту тему (Ray Wenderlich & Co)

Edit 2016.1: после того, как долгое время был адвокатом раскадровки, у меня было так много хлопот с ним в последние месяцы, что я решил отказаться от раскадровки, насколько это возможно. Причина этого заключается в том, что Apple добавляет функцию, как глупо, но не заботится об ошибках и недостатках. Производительность имея множество ограничений автоматической компоновки действительно плохо (в то время как время разработки), и подверженность ошибкам стала огромной. Пример: еще менее сложные раскадровки, как правило, попадают в "грязный режим" сразу после открытия проекта в Xcode (см. Состояние git). Совет: как новичок вы будете любить раскадровки, так как вы можете прототип быстро и получить вещи, работающие без большого количества кода. Когда вы вводите промежуточное состояние, вы добавляете больше кода GUI в свой проект. Теперь вы начинаете ходить взад и вперед между кодом и SB-и все начинает работать еще хуже. Рано или поздно вы будете склонны делать большую часть графического интерфейса в коде, потому что результат более предсказуем, чем наличие нескольких источников.

резюме

Крупка/.файлы xib и раскадровки-это файлы Interface Builder, которые используются для визуального создания пользовательского интерфейса для приложений iOS и Mac в Xcode (я буду использовать терминологию iOS для классов, поскольку этот вопрос помечен iOS, но он также относится к программированию Mac).

различия

наконечники предназначены для использования с одним UIView. Они также могут быть подключены к UIViewController подкласс по настройкам класс владельца файла к любому подкласс UIViewController и подключите вид розетки (перетащите для подключения с помощью инспектора соединений в дальней правой панели Xcode).

раскадровки предназначены для размещения пользовательского интерфейса для 1 или более UIViewController. Вы можете построить весь свой пользовательский интерфейс в одной раскадровке или разделить его на более мелкие части.

преимущества

раскадровки всегда должны использоваться в пользу .xib файлы/наконечники (по мнению контролеров). Раскадровки имеют больше возможностей и активно разрабатываются Apple.

каждый аргумент в пользу перьев полагается на то, что они используются индивидуально, в то время как раскадровки содержат много сцен. Вы можете использовать одну раскадровку для каждого UIViewController так же легко, как вы можете с перьями (см. примеры кода ниже). Продолжайте читать для подробного объяснения и примеров кода.

полная

почему Storboards превосходят Nibs?

ответ в основном сводится чтобы Apple поощряла использование раскадровок и вкладывала в них больше усилий по разработке.

1. раскадровки имеют возможность масштабирования, которой не хватает перьев. Серьезно, вы не можете увеличить вообще в перьях, которые отстой при проектировании для больших экранов на маленьком ноутбуке.
2. наконечники отсутствуют ключевые функции, такие как:
   • прототип и динамические ячейки для UITableView (подробнее)
   • The top layout guide собственность (см. комментарий)
   • есть, вероятно, больше, пожалуйста, редактировать или комментировать, если у вас есть что-то добавить в этот список
3. вам не нужно возиться с установкой класса владельца файлов.

основной аргумент против раскадровки заключается в том, что наличие всех ваших контроллеров представления в одном месте приводит к слиянию конфликтов, медленному Xcode, медленному времени сборки и общей боли в заднице для поддержания. Следовательно, общий совет-использовать перо для каждого UIViewController.

но... Вы можете просто создать раскадровку для каждого UIViewController. Обычная практика (по крайней мере для меня) заключается в том, чтобы скрыть всю инициализацию UIViewController в методе класса (поскольку ни один другой класс не должен знать имя файла, в котором находится перо/раскадровка контроллера). Давайте сравним соответствующие фрагменты кода, которые можно использовать для создания такого метода. Одна строка кода-это вся разница между два.

С

раскадровка

+ (ViewController *)create
{
    UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"ViewController" bundle:nil];
    return [storyboard instantiateInitialViewController];
}

Сиб

+ (ViewController *)create
{
    return [super initWithNibName:@"ViewController" bundle:nil];
}

использование

- (void)showMyViewController
{
    ViewController *vc = [ViewController create];
    [self presentViewController:vc animated:YES completion:nil];
}

Свифт

раскадровка

static func create() -> ViewController {
    let storyboard = UIStoryboard(name: "ViewController", bundle: NSBundle.mainBundle())
    return storyboard.instantiateInitialViewController() as! ViewController
}

Сиб

static func create() -> ViewController {
    return ViewController(nibName: "ViewController", bundle: nil)
}

использование

func showMyViewController() {
    let vc = ViewController.create()
    self.presentViewController(vc, animated: true, completion: nil)
}

Аргументы

я рассмотрю все обычные аргументы для Nibs; как я уже упоминал раньше, в основном в пользу отдельных файлов, а не в качестве аргумента для перьев над раскадровками

1. команды и слияния

аргумент: наличие раскадровки с большим количеством контроллеров вида будет вызвать конфликты слияния, если вы работаете в команде с несколькими люди, вносящие изменения

ответ: одна раскадровка вызывает не больше конфликтов слияния, чем одна Перо

1. сложности

аргумент: очень сложные приложения имеют много сцен в раскадровке, что приводит к гигантской раскадровке, которая занимает вечность для загрузки и едва понятна из-за ее размера.

ответ: это отличный момент, но вы можете легко разбить раскадровки на более мелкие части. Раскадровка Ссылок выглядит как отличная функция, которая может быть использована для связи раскадровки вместе, но они доступны только в Xcode 7 и iOS 9+. Кроме того, все еще не причина выбирать отдельные перья над раскадровками.

1. Reuseability

аргумент: создание наконечника для каждого UIViewController подкласс позволяет повторно использовать код, поэтому вам не нужно настраивать все свои ограничения и выходы для каждой сцены в вашей раскадровке.

ответ: опять же, не причина выбирать отдельные перья над отдельными раскадровками.

было хорошая презентация о раскадровке дано на заседании LiDG пару месяцев назад.

лично я бы сказал, что это путь в новое приложение. Есть некоторые пробелы, особенно для очень сложных приложений, но в основном плюсы перевешивают минусы.

еще несколько преимуществ раскадровки:

• раскадровки имеют лучшую поддержку для просмотра таблиц. То есть вы можете использовать "Динамические "и" прототипные " клетки.
• проще создавать экземпляры контроллеров представления с помощью раскадровки. Вы можете делать такие вещи, как: [se lf.раскадровка instantiateViewControllerWithIdentifer:]
• раскадровки поддерживают контейнеры контроллера вида, так что вы можете иметь дочерние контроллеры представления выложены графически.

минусов являются:

• раскадровки медленно отображаются в XCode, когда они содержат много контроллеров вида

• режим не может быть включен один вид контроллера в раскадровке.

будьте осторожны, если вы используете раскадровки ваше приложение не обратно совместимо со старыми установками ОС.

раскадровка в основном устройство, чтобы сделать вашу работу в качестве разработчика проще. Он соответствует серии файлов nib, поэтому производительность в значительной степени эквивалентна, но это здорово, как разработчик, чтобы иметь возможность посмотреть на краткий обзор всего потока приложений.

Я начинаю переходить к использованию раскадровок в новых проектах, если я могу убедить клиента принять iOS 5 в качестве минимальной версии. Это просто потому, что я предпочитаю делать это таким образом, и это занимает меня меньше времени на выполнение одних и тех же задач.

раскадровки имеют гораздо больше проблем, чем преимуществ. Вот список их проблем, скопированный из iraycd:

• раскадровки сбой во время выполнения, а не во время компиляции: у вас есть опечатка в имени segue или он неправильно подключен в вашей раскадровке? Он взорвется во время выполнения. Вы используете пользовательский подкласс UIViewController, который больше не существует в вашей раскадровке? Он взорвется во время выполнения. Если вы делаете такие вещи в коде, вы будете поймать их на ранней стадии, во время компиляции. обновление: мой новый инструмент StoryboardLint в основном решает эту проблему.

• раскадровки быстро запутываются: по мере роста вашего проекта, ваша раскадровка становится все труднее ориентироваться. Кроме того, если несколько контроллеров вида имеют несколько сегментов для нескольких других контроллеров вида, ваша раскадровка быстро начинает выглядеть как чаша спагетти, и вы обнаружите, что масштабирование и прокрутка по всему месту, чтобы найти контроллер вида, который вы ищете, и узнать, какие точки перехода где. обновление: эта проблема в основном может быть решена путем разделения раскадровки на несколько раскадровок, как описано в эта статья Pilky и эта статья Роберта Брауна.

• раскадровки делают работу в команде сильнее: поскольку у вас обычно есть только один огромный файл раскадровки для вашего проекта, наличие нескольких разработчиков, регулярно вносящих изменения в этот файл, может быть головной болью: изменения должны быть объединены и разрешены конфликты. Когда возникает конфликт, трудно сказать, как его решить: Xcode генерирует XML-файл раскадровки, и он на самом деле не был разработан с целью, чтобы человек должен был читать, не говоря уже о его редактировании.

• раскадровки делать код отзывы трудно или почти невозможно: Peer code reviews-это отличная вещь для вашей команды. Однако, когда вы вносите изменения в раскадровку, практически невозможно просмотреть эти изменения с другим разработчиком. Все, что вы можете вытащить, это разница в огромном XML-файле. Расшифровка того, что действительно изменилось, и если эти изменения верны или если они сломали что-то действительно трудно.

• раскадровки мешают повторному использованию кода: в моих проектах iOS я обычно создайте класс, который содержит все цвета и шрифты, поля и вставки, которые я использую во всем приложении, чтобы придать ему согласованный внешний вид: это изменение одной строки, если мне нужно настроить любое из этих значений для всего приложения. Если вы устанавливаете такие значения в раскадровке, вы дублируете их и должны будете найти каждое отдельное событие, когда вы хотите их изменить. Велика вероятность, что вы пропустите один, потому что нет поиска и замены в раскадровках.

• раскадровки заставляют вас делать все дважды: вы создаете Универсальное приложение, которое работает как на iPad, так и на iPhone? Когда вы используете раскадровки, у вас обычно будет одна раскадровка для версии iPad и одна для версии iPhone. Чтобы поддерживать синхронизацию, вы должны выполнять каждое изменение пользовательского интерфейса или рабочего процесса приложения в двух местах. Ура. обновление: в iOS 8 и Xcode 6, Вы можете использовать одну раскадровку для iPhone и устройство iPad.

• раскадровки требуют постоянных переключателей контекста: я обнаружил, что работаю и перемещаюсь гораздо быстрее в коде, чем в раскадровках. Когда ваше приложение использует раскадровки, вы постоянно переключаете свой контекст: "О, я хочу нажать на эту ячейку представления таблицы, чтобы загрузить другой контроллер представления. Теперь мне нужно открыть раскадровку, найти правильный контроллер вида, создать новый сегмент для другого контроллера вида (который я также должен найти), дать сегменту имя, запомните это имя (я не могу использовать константы или переменные в раскадровках), вернитесь к коду и надеюсь, что я не ошибусь с именем этого segue для моего метода prepareForSegue. Как бы я хотел просто ввести эти 3 строки кода прямо здесь, где я нахожусь!"Нет, это не весело. Переключение между кодом и раскадровкой (и между клавиатурой и мышью) быстро устаревает и замедляет вас.

• раскадровки трудно рефакторинг: при рефакторинге кода, Вы должны убедитесь, что он по-прежнему соответствует тому, что ожидает ваша раскадровка. Когда вы перемещаете вещи в своей раскадровке, вы узнаете только во время выполнения, если он все еще работает с вашим кодом. Мне кажется, что я должен держать два мира в синхронизации. Он чувствует себя хрупким и обескураживает изменения в моем скромном мнении.

• раскадровки не доступны для поиска: поиск по всему проекту в Xcode на самом деле не является поиском по всему проекту, когда вы используете раскадровки. Они не входят в состав поиск. Поэтому, когда вы удаляете пользовательский класс из своего кода или переименовываете его, вам придется вручную пройти через раскадровку или посмотреть на его необработанный XML, чтобы убедиться, что он соответствует вашим изменениям кода. Нет, сэр, мне это не нравится. обновление: раскадровки доступны для поиска в Xcode 6.

• раскадровки менее гибкие: в коде, вы можете в основном делать все, что вы хотите! С раскадровками вы ограничены подмножеством того, что вы можете сделать в коде. Особенно, когда вы хотите сделать некоторые продвинутые вещи с анимацией и переходами, вы обнаружите, что "боретесь с раскадровкой", чтобы заставить ее работать.

• раскадровки не позволяют изменять тип специальных контроллеров вида: вы хотите изменить a UITableViewController на UICollectionViewController? Или в равнину UIViewController? Невозможно в раскадровке. Вы должны удалить старый контроллер вида и создать новый и повторно подключить все сегменты. Это намного проще чтобы сделать такое изменение в код.

• раскадровки добавляют два дополнительных обязательства к вашему проекту: (1) Инструмент редактора раскадровки, который создает XML раскадровки и (2) компонент среды выполнения, который анализирует XML и создает объекты пользовательского интерфейса и контроллера из него. Обе части могут иметь ошибки, которые вы не можете исправить.

• раскадровки не позволяют добавлять подвиды в UIImageView: кто знает почему.

• раскадровки не позволяют включить автоматическую компоновку для отдельного вида (- контроллер)s: при установке / снятии флажка с опции Auto Layout в раскадровке изменение применяется ко всем контроллерам в раскадровке. (Спасибо Саве Мазаре за этот момент!)

• раскадровки имеют более высокий риск нарушения обратной совместимости: Xcode иногда изменяет формат файла раскадровки и не гарантирует в любом случае, вы сможете открыть файлы раскадровки, которые вы создаете сегодня через несколько лет или даже месяцев. (Спасибо thoughtadvances за этот момент. смотрите оригинальный комментарий)

• это Макдональдс: чтобы сказать это словами Стива Джобса о Microsoft:это Макдональдс (видео)!

Ваше отношение к автоматической компоновке также может повлиять на то, хотите ли вы использовать раскадровки. С помощью xibs вы можете включить или отключить автоматическую компоновку на per .xib basis, что позволяет смешивать в вашем приложении, в то время как раскадровки применяют ваш выбор ко всем представлениям, которые они содержат.

вы видите большую картину в одну секунду. Имея много файлов NIB, ну, вы не видите общую картину. Легче поддерживать ваши программы. Легче понять другие программы... среди прочего.

плюсы:

1) Очень приятно проектировать интерфейсы

2) Вы можете использовать раскадровку сегменты для идентификации навигации/модальных отношений в прохладной манере.

3) Если ваше приложение поддерживает несколько устройств, это хороший способ организовать разные взгляды.

4) прототипирование является еще одним дополнительным преимуществом.

5) прототип UITableViewCell может сэкономить время и уменьшить количество кода тоже.

6) вы можете увидеть все экраны приложения в одном месте с помощью раскадровки.

7) Вы можете легко просмотреть отношения между ними

8) Если вы работаете над чьим-то кодом, вы можете лучше понять поток приложения.

9) вы можете настроить пользовательский интерфейс для iPhone 4 и iPhone 5, применив форм-фактор retina из раскадровки, не запуская приложение снова и снова.

10) клиенты могут увидеть прототип приложение, прежде чем начать его разработку, здесь раскадровка поможет вам много.

недостатки:

1) он доступен только в iOS 5+

2) раскадровки являются своего рода жесткими, и вы можете использовать prepareForSegue много раз.

4) Как IB, не очень дружелюбный с другими двигателями дисплея и toolkits.

4) затрудняет совместное использование конструкций для одного вида или набора видов - вы должны отправить все или ничего.

5) для раскадровки вам понадобится большой экран специально в случае iPad.

6) Сложность при копировании представлений из других приложений в раскадровку.

7) проблемы в раскадровке, когда несколько разработчиков работают над одним проектом с помощью репозитория git

скопировано с какого-то ресурса

до iOS 7 раскадровки были довольно аккуратными, но не обязательными. Они вводили столько же проблем, сколько и решали. iOS 7 наклонила баланс в сторону раскадровки.

С iOS 8 и 9 это уже не вопрос: используйте раскадровки!

основной недостаток раскадровки заключается в том, что вы полностью зависите от XCode, и вы можете потратить часы, вращая свои колеса на ошибках XCode. Но XCode стал намного лучше, и преимущества с Раскадровки теперь слишком многочисленны, чтобы игнорировать. Прототипы ячеек табличного представления, классы размеров, поддержка автоматической компоновки и т. д.

Несколько Советов:

• подумайте о каждой раскадровке как о контейнере для контроллеров вида, которые принадлежать друг другу. Не думайте об этом как о грандиозном макете всего вашего приложение.
• вы, возможно, потребуется больше, чем одна раскадровка
• сегменты действительно полезны только для самых тривиальных случаев использования - они отлично подходят для этого. Но в реальном мир приложение многие переходы будут происходить из кода. И это нормально.
• написать категорию для программного создания экземпляров контроллеров представления из раскадровки(с) так что все, что вам нужно сделать, это позволить vc=SomeViewController.create (), где метод обрабатывает все подробности (тянуть историю правления, извлеките контроллер из истории Совет прием.)