Что более эффективно? StoryBoard или XIB?

Мой вопрос немного отличается от моего названия. Я работал с xib. Теперь я пытаюсь работать с раскадрой. Мой вопрос в том, что если мы перемещаемся через один класс из другого класса, это StoryBoard дает преимущество для лучшего управления памятью. Предположим, у нас есть 2 ViewControllers: ViewControllerA и ViewControllerB. Мы пытаемся пройти через ViewControllerA → ViewControllerB. Теперь, в Xib наш подход ниже;

ViewControllerB *VCB = [ [ViewControllerB alloc] init];
[self.navigationController pushViewController: VCB Animated: YES];

Где в Истории,

-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    if ([segue.identifier isEqualToString:@"Second"])
    {
        SecondViewController *objSecond = (SecondViewController*)[segue destinationViewController];

    }
}

И сделай,

[self performSegueWithIdentifier:@"Second" sender:self];

Итак, Мой вопрос: мы выделяем наш класс в Xib, где в storyBoard нет. Так есть ли преимущества распределения памяти в раскадровке?

Ответ 1

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

Если вы один разработчик, полезно использовать раскадровку, потому что он потребляет меньше времени. Если команда состоит из многих разработчиков, используйте xib, в противном случае нелегко объединить модули/задачи.

xcode-using-storyboards-and-xibs-versus-creating-views-programmatically

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

<сильные > Преимущества:

Вы можете быстро создать пользовательский интерфейс
Прямая реализация для небольших приложений с минимальным количеством экранов
У вас могут быть отдельные XIB для разных локализаций (например, языки или страны)
Великолепно выделять элементы и визуально определять несоосности. Легко сделать небольшую корректировку макета

Недостатки:

Трудно слить конфликты при работе в командной среде (трудно разложить, слить и прочитать)
Очень динамические представления невозможно описать как XIB
Производительность мудрая, медленнее, чем создание представлений через код, потому что xib нужно читать с диска и анализировать/анализировать
XIBs не имеют настроек, которые вы можете использовать в коде, например, в материалах Quartz (тени, круглые углы)
Сложнее отлаживать (т.е. если вы забудете сделать соединение в Interface Builder или сделать неправильное соединение)

Раскадровка

<сильные > Преимущества:

Раскадранты хороши для приложений с небольшим или средним количеством экранов, а требования к навигации относительно просты между представлениями
Вы можете макетировать поток приложения, не пиши много, если таковые имеются, код

Недостатки:

Кадры не совместимы с pre-iOS 5, поэтому он делает невозможным поддержку iOS 4.3
Его трудно работать параллельно в командной среде, потому что каждый, изменяющий один и тот же файл
В то же время слияние конфликтующих раскадровки в GIT будет больно
Люди столкнулись с ошибками в Xcode с использованием раскадровки (например, для частой очистки папки DerivedData из-за несоответствий)

Ответ 2

Моя точка зрения, что профессиональный разработчик MUST use xibs, но любитель, новый для программирования, разработчик может помочь, если он использует раскадровку.

Раскадровка

После трехлетней работы над проектом с одним раскадровкой я могу сказать lot of disadvantages:

1) Это ДЕЙСТВИТЕЛЬНО становится ОЧЕНЬ ОЧЕНЬ медленным, чтобы строить даже для очень очень маленького мышления (каждый вид в нем должен быть перестроен). Также очень сложно отредактировать даже с iMac с 8 или 16 ГБ оперативной памяти, если раскадровка становится больше. Его даже трудно открыть.

2) Нет повторного использования. Невозможно сразу импортировать View/ViewController с его представлением в другой проект. Он будет связан с другими ViewControllers, Views or Segues, и это сделает его похожим на "не трогайте" мысли.

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

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

Преимущество:

1) Автоматические ячейки (но это также является недостатком, поскольку ячейку нельзя повторно использовать, как и в другом представлении)

2) Segues и т.д. облегчили бы для кого-то понимание с одной точки зрения, что происходит.

Xibs:

1) Полностью портативный.

2) Open/Edit/Build SO MUCH MUCH MUCH быстрее, чем раскадровка, которая становится больше

Вывод:

Если вы являетесь разработчиком-любителем, который сделает приложение для своего бизнеса для удовольствия, вам следует использовать раскадровку, потому что легче понять вещи. НО, если вы профессиональный разработчик, вы ДОЛЖНЫ использовать xibs для VC, Cells и т.д., Потому что это единственный способ сделать их действительно многоразовыми и переносимыми, чтобы получить так много времени для следующего проекта или даже когда сделайте небольшое изменение или снова создайте раскадровку.

Объяснение, почему xibs более "многоразовые и переносимые" для меня: Вещи в программировании должны храниться в разных моделях, файлах, сущностях, модулях. Человек должен быть как минимум зависим от другого, поскольку он может получить

Ответ 3

Сравнивая XIB и storyBoard, StoryBoard работает быстро.

Но на самом деле быстрый, весь проект выполнен программно.

в раскадровке, когда мы скомпилируем весь файл истории, архивируем в файл. и unArchive, затем запустите приложение. Но в программном плане классы выделяются только во время выполнения.

Ответ 4

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

Ответ 5

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