Эффективность создания представлений программно против IB

Question

У меня есть большое количество UIViews, которые создаются в делегате приложения applicationDidFinishLaunching и добавляются в NSMutableArray. Пользователь просматривает эти представления, используя элементы управления страницей и прокрутки. Я создал UIView и его дочерние компоненты в IB. Они подключены к контроллеру. На создание 170 просмотров на iPhone уходит около 30 секунд. Со временем у меня будет более 1000 просмотров. Помимо того, что он медленный, он также убивает приложение из-за использования памяти. Насколько быстрее и эффективнее память создает все программно без представлений? Как могут это делать некоторые из 6000 приложений типа фактов?

Есть ли лучший подход вместо создания всего сразу? Пользователь может получить доступ к представлению в слоте # 400 и начать прокрутку оттуда. Любые предложения приветствуются.

Answer 1

UIViewКонтроллеры ленивы. Они загружаются только по запросу и автоматически выгружаются при нехватке памяти (и их легко выгрузить вручную, вызвав self.view=nil).

Здесь «загрузка» означает «читать NIB» или «строить программно». ViewControllers на самом деле все равно. Программная сборка может быть немного быстрее, поскольку вам не нужно нажимать на диск, но это редко является узким местом, поскольку вы одновременно отображаете только один контроллер представления.

Что делать, это скорее стиль, чем производительность (за исключением UITableViewCells, в большинстве случаев есть причины, по которым вам нужно строить программно).

Начните с изучения Руководства по программированию View Controller . Он покажет вам, как iPhone собирается это сделать.

К замечанию eJames о том, что NIB являются файлами XML, это может немного вводить в заблуждение. NIB - это двоичные файлы, сгенерированные путем компиляции файлов XIB в формате XML. Я бы сделал профилирование на телефоне, прежде чем предположить, что время загрузки NIB на самом деле является проблемой. Хотя я по натуре склонен к программной компоновке, на практике я обнаружил, что NIB значительно упрощают многие вопросы пользовательского интерфейса на практике, и я всегда возвращаюсь к ним для крупных проектов.

Answer 2

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

Если ваши страницы имеют общий макет, вы можете использовать UITableView для отображения содержимого каждой страницы и сохранять только данные для каждой страницы в NSMutableArray.

Отличное руководство по использованию UITableView можно найти здесь .

Если они не разделяют общий макет, то программная раскладка будет подходящим способом. Это не должно занимать больше памяти или процессорного времени, чем при использовании IB, и на самом деле это, вероятно, будет быстрее, поскольку устраняет необходимость чтения и анализа XML-файла (а именно это и есть файлы .NIB).