Я разрабатываю приложение для iPad на основе HTML, которое активно использует JavaScript для своего пользовательского интерфейса. GUI будет похож на журнал, т.е. разделен на экраны / представления, между которыми пользователь затем перемещается с помощью сенсорных событий и переходов webkit. Все это выполняется локально на iPad (через встроенную оболочку, такую как PhoneGap и т. Д.).
Допустим, в приложении будет 50-100 таких экранов, заполненных стандартными веб-элементами, такими как текст, изображения, таблицы и формы.
Как структурировать это для лучшей производительности? Какой из следующих двух методов предпочтительнее и почему?
имея только 3 немедленных (текущий, предыдущий, следующий) представления / экраны в DOM, а затем добавляя новые (и удаляя старые) в DOM, когда пользователь перемещается вперед / назад?
, сгенерированные при запуске целые 50-100 HTML-экранов, а затем скрывающие (не отображаемые) все из них, кроме указанных выше 3
Так в принципе, что работает лучше с памятью / производительностью? С одной стороны, непрерывные операции DOM могут быть дорогостоящими (и, что еще хуже, переходы между экранами приложений становятся прерывистыми), а с другой стороны, не знаю, будет ли иметь до 100 экранов HTML, предварительно сгенерированных в одном документе, DOM не будет заставит Mobile Safari захлебнуться до смерти. Конечно, даже несмотря на то, что эти экраны находятся в DOM, большинство из них являются отображаемыми: чаще всего нет - но так ли хорош мобильный сборщик мусора для сафари? Кто-нибудь пробовал это?
Кстати, обратите внимание, что это не проблема с памятью изображения / вопрос типа утечки. Я знаю об этой проблеме и буду решать ее с помощью хитрого трюка с разгрузкой изображений, независимо от того, каким путем я пойду. Это только о представлениях HTML - скелетах, если хотите.