Я теряю производительность при помощи .xib файлов для обеспечения GUI приложения для iPhone?

(Примечание: Прослушивая это на моем телефоне, я заранее извиняюсь за любое странное форматирование или грамматику - если есть проблемы, я исправлю их, когда вернусь к своему ноутбуку. )

Я сделал несколько быстрых, грязных и крайне неформальных тестов, чтобы проверить это для себя, и вот что я нашел (обратите внимание, что приложение, которое я создал для тестов было просто царапина и не обязательно является представителем "реального" приложения):

• Время запуска было быстрее, когда начальный экран был пером

• Для всех последующих экранов производительность увеличивалась при ручном кодировании пользовательского интерфейса

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

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

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

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

Плюс, потому что iPhone UI так специфичен, ну, iPhone (сюрприз!), кодирование UI вручную не трудно, как это бывает при написании приложений для настольных компьютеров. Вы используете одни и те же компоненты пользовательского интерфейса снова и снова - как только вы получили это вниз, взбивание пользовательского интерфейса в коде легко. У вас нет восьми миллиардов виджетов на выбор, так как вы разрабатываете Windows/OS X/независимое приложение. Консистенция iPhone делает его самой простой платформой, против которой я разрабатывал на протяжении веков, когда речь заходит о ручном кодировании пользовательского интерфейса.

Я также обнаружил, что NSCoding (который я использую для сохранения состояния во время работы приложений) намного проще работать, когда я вручную кодирую пользовательский интерфейс. Я сталкивался с проблемами, когда nib-экран не мог корректно архивировать из-за экземпляров UIImage. UIImage (по крайней мере, последний раз, когда я проверял) не соответствует NSCoding, поэтому процесс архивирования умирает (и это довольно неприятная смерть). Я использовал UIImage в качестве примера здесь, но всё, что архиватор пытается хранить, что не соответствует NSCoding, испортит процесс, так что есть над чем задуматься.

В другой раз я всегда кодирую UI вручную всякий раз, когда я использую динамическую таблицу. Если я создаю статическую таблицу - ту, ячейки которой в принципе никогда не изменятся, - наконечники в порядке. Для любого другого типа таблиц, и особенно для тех, в которых есть, скажем, эскизы и другие ресурсоемкие биты, контроль, который я получаю, когда кодирую вручную, позволяет получить производительность, которую вы не получите с ячейками таблиц на основе пера. Для этого вам do придется пропустить CocoaTouch и работать непосредственно с CoreGraphics, но улучшения производительности, которые вы можете сделать, стоят каждой последней строки кода, которую вы должны написать. Примеры производительности таблиц из проектов, над которыми я работал, смотрите в Barnes and Noble Store (не читатель электронных книг) и Style.com. Мы создали фреймворк для этих (и других) приложений, и секрет плавной прокрутки таблиц в том, что мы ни разу не использовали ячейки, загруженные из пера (это сложнее, но пропустить пера было первым шагом к получению производительности, которую вы увидите в этих приложениях).

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

Для дальнейшего пояснения: если у вас приложение с пятью контроллерами вида, засуньте каждый контроллер в свое перо. Вы не захотите ничего загружать до тех пор, пока это не понадобится. Исключения есть, но такова простота кодирования - если дать достаточно времени, вы найдете причину сделать что-то "не так", но подход a-nib-for-each-screen - это то, как вы должны это делать, если только у вас нет веских причин не делать этого.

Я оставлю его там - надеюсь, это немного поможет.

Просто помните:

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

• После запуска производительность, казалось бы, улучшилась для UI с ручным кодированием.

• Если все сделано правильно, и если вы не пишете игру или что-то в этом роде, перо не должно приводить к ощутимым проблемам с производительностью.

• По моему опыту, таблицы разные - это одно из мест, где я редко использую перо.

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

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

Хорошо. На этот раз остановимся по-настоящему.

Надеюсь это поможет :)