Блог

Я хочу решить, лучше ли использовать XIBs или полностью создавать свои представления с использованием кода.

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

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

Каким был ваш опыт, советы и т.д.?

Спасибо!

Вы должны уметь делать и то, и другое — бывают случаи, когда создание представления программно лучше / проще, и времена, когда использование .xib лучше / проще. Даже если вы когда-либо делаете что-то только одним способом, вы столкнетесь с кодом, который делает это другим, и вам нужно будет уметь с этим справляться.

Если вы не знаете, как использовать IB, то создавать свои представления в коде, безусловно, проще. Вот почему вам следует научиться использовать IB. Как только вы разберетесь в IB, гораздо быстрее можно будет собрать большую часть пользовательского интерфейса на основе view, который, вероятно, понадобится вашему приложению. IB помогает вам выстраивать объекты в линию, центрировать объекты, выравнивать базовые линии, связывать элементы управления с их целями и действиями и т.д. Я думаю, можно с уверенностью сказать, что каждый, кто эффективно использует IB, испытывает «реальный прирост скорости при использовании nibs».

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

Многие люди, новички в разработке iOS, ошибочно полагают, что nibs (xib-файлы) уступают программному созданию пользовательского интерфейса и что если вы используете IB, то вы плохой разработчик iOS. Это представление на 100% неверно. IB создан Apple и используется разработчиками Apple для создания собственных приложений для Mac OS X и iOS. Если IB (как инструмент) достаточно хорош, чтобы им могли пользоваться одни из лучших разработчиков в мире, то, вероятно, он достаточно хорош и для большинства из нас.

На практике я обнаружил, что комбинация этих двух обычно отвечает всем требованиям.

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

Затем, когда вам нужно сделать более продвинутые вещи, такие как добавление причудливых анимаций или перемещение views, для этого и существуют IBOutlets. На все, что вы помещаете в nib, можно ссылаться через IBOutlet. Это позволяет вам программно оживить свой view.

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

Кроме того, узнайте, как использовать .xibs инкапсулированным способом. Например, .xibs безумно полезны для таких вещей, как ячейки прототипов, и они позволяют сохранить вашу кодовую базу модульной (в гораздо большей степени, чем раскадровки). Кроме того, вам потребуется меньше кода пользовательского интерфейса в ваших контроллерах view.

Наконец, я всегда говорю, что люди должны думать о IB /.xibs как о jQuery. Это сэкономит вам много времени, но лучшие разработчики по-прежнему знают, как сделать все на javascript, если потребуется.

Удачи и получайте удовольствие!

Версия TL; DR

• Производительность не учитывается при принятии решения использовать .xibs или нет.
• Используйте .xibs, потому что они дают вам предварительный просмотр создаваемого вами представления и позволяют быстро выполнять итерации
• На практике большинство приложений будут использовать комбинацию обоих. Вы будете программно добавлять анимацию или перемещать views, но .xibs будет отправной точкой
• Полностью понять, что происходит, когда объекты в .xib размораживаются
• Вы будете более продуктивны, но убедитесь, что полностью понимаете, что происходит за кулисами.

Я бы всегда использовал XIB-файлы, если бы не было причины не делать этого. Это позволяет легко поддерживать ваши views в будущем.

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

• Размер элемента управления необходимо изменить, переместить или иным образом изменить в зависимости от чего-то еще
• Элементы управления необходимо добавлять или удалять динамически

Причин может быть больше, но их не слишком много.

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

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

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

Для простых элементов пользовательского интерфейса вам придется поддерживать больше строк кода, если вы создадите их программно.

IB и NIBS многое делают для оптимизации загрузки / выгрузки views, но в основном ориентированы на минимизацию использования памяти по сравнению с воспринимаемой пользователем скоростью. Например, отложенная загрузка, если что-либо еще, может немного замедлить пользовательский интерфейс приложения, но это должно снизить использование памяти. Это, в свою очередь, может повысить общую производительность приложения в большом приложении, и это очень поощряется, но трудно определить «производительность» в узком смысле. Также сложно сказать, когда вам следует или не следует использовать IB — будут моменты, когда вам будет намного лучше делать это в коде.

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

Я рассматриваю IB как основную часть платформы разработки для iOS. Это неправильное решение в любой ситуации, но незнание того, как использовать IB, будет реальным ограничивающим фактором.