Какие существуют способы хранения ресурсов в мобильном HTML5-приложении?

Question

[anmipo]

Ситуация: Есть Blackbery PlayBook, под который пишется приложение на HTML+JS (WebWorks фреймворк). Приложению требуется около 20 тыс. файлов ресурсов (картинки png), средний размер каждого ~8 килобайт.
Проблема: В SDK есть баг, из-за которого невозможно собрать приложение, состоящее из более чем 5000 файлов.
Задача: уменьшить количество используемых файлов.


Возможные решения:

1. Сгруппировать ресурсы в бóльшие файлы, читать по мере необходимости.

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

2. Создать локальную БД (HTML5 storage), загружать в неё ресурсы с сервера при первом старте.

— Хотелось бы избежать необходимости загрузки чего-либо из сети.

3. Архивировать ресурсы в большой файл, разархивировать в БД при первом запуске.

— Приложение будет занимать вдвое больше места, чем ему нужно.


Может, я что-то упускаю из вида?

Answer 1

[SabMakc]

А в чем проблема действовать по 1му варианту?
Объединяем по 4 файла в один, объем увеличивается до 32КБ, не так уж и критично.
И можно ли использовав часть большого фала, выгрузить его из памяти совсем?

P.S. 20 000 картинок на проект? А не много ли? Если так разбита анимация — то имеет смысл объединить анимацию в 1 файл для каждой группы.
P.S.S. а что за проект такой? Возможно, есть способ просто сократить количество файлов? А то их нереально много (почти 160 метров если считать 8КБ на файл).

Comments

[anmipo]

Картинки — отрендеренные кусочки карты. 20 тыс картинок — это небольшой город при разных масштабах, нарезанный на кусочки 256×256.
Можно, конечно, увеличить размер до 512×512; количество файлов уменьшится в четыре раза, — но всё равно будет очень близко к пределу. Чуть покрупнее карта — и всё.
Если увеличить размер ещё — планшет будет жонглировать полудюжиной картинок 768×768 и приложение станет заметно задумчивее.

А это обидно, учитывая, что проблема, в общем-то, искусственная…

[rPman]

Это почему у вас 768x768 ворочается медленнее чем многократно увеличенное количество кадров по 256x265?!!!

В вашем случае лучшее что можно сделать — увеличить размер кусочка карты… не больше размера экрана конечно же, если куски станут больше, то для отрисовки будет задействовано только четыре куска, что должно быть очень быстро (продумайте фоновую подзагрузку очередного куска заранее, например в направлении движения персонажа)

[anmipo]

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

Собственно, проблема с большими кусочками оттуда же: если пользователь подвинул карту на пару пикселей в сторону, в худшем случае начнут параллельно загружаться N маленьких 256×256 кусочков, и пользователь будет сразу видеть, как зарисовывается пробел => приложение выглядит отзывчивым и быстрым.
В случае больших 768×768 кусочков, их нужно будет всего N/3, и загружать их придётся реже, но каждый из них будет грузиться дольше. То есть, для пользователя приложение будет выглядеть быстрым, но при загрузке новых кусков карты будут заметные заикания, которых хотелось бы избежать.

Answer 2

[Анатолий]

base64
спрайты
архивы
итп, придумать при желании можно много чего.

Comments

[anmipo]

Спасибо за набор ключевых слов, но развёрнутая мысль была бы полезнее.

Base64 — просто формат хранения, какое отношение он имеет к вопросу?
Спрайты — приложение не использует CSS для работы с ресурсами (а даже если бы и — то CSS бы получился многомегабайтным). Или Вы не CSS-спрайты имеете в виду?
Архивы — фигурируют в решениях 1 и 3, там же описаны их недостатки.

[sompylasar]

Спрайты — приложение не использует CSS для работы с ресурсами (а даже если бы и — то CSS бы получился многомегабайтным). Или Вы не CSS-спрайты имеете в виду?

А что тогда используется? Спрайты — это общее понятие для группировки изображений в одно с дальнейшим выделением отдельных частей по смещениям и размерам. Если используется HTML, то может ли использоваться canvas? В этом случае можно загружать блоки картинок и «резать» их на лету (копировать в нужное место только некоторую область блока картинок).

Если есть возможность каким-либо образом читать изображения из ресурсов, то base64 я бы не использовал, поскольку он Чуть более объемный, чем исходные бинарные данные (по одному лишнему байту на каждые 3 исходных байта).

[d4rkr00t]

base64 имеется ввиду dataurl, то есть какую-то часть мелких картинок загнать в css

[anmipo]

Спасибо за пояснения. Действительно, изображения из ресурсов скриптом рисуются на canvas, и ничего не мешает при этом брать только часть спрайта/группы изображений. Я только опасаюсь, что загрузка большого спрайта вместо маленькой одиночной картинки сильно скажется на производительности (приложение-то мобильное).

Answer 3

[Павло Пономаренко]

Почему бы ресурсы не поставлять отдельно от приложения? Тогда оно будет масштабируемо.
Скажем, app.js + kiev.map.

Comments

[anmipo]

Масштабируемость была бы интересна, но заводить отдельный сервер под это дело не хочется. Гораздо проще один раз загрузить 150 МБ пакет в магазин приложений, чем отдавать такой же объём со своего хостинга каждому пользователю…

Answer 4

[Олег Барабанов]

1) Используя manifest. В нем необходимо будет указать эту орду файлов. Загрузки будут по мере необходимости, зато второй раз не будут грузиться. Поддержка манифеста в браузерах
2) Самостоятельный механизм кеширования с внесением в webSQL. Поддержка webSQL в мобильных

Comments

[anmipo]

1) Манифест присутствует, его создаёт SDK при сборке приложения. Иронично, что именно он и является корнем проблемы — при большом манифесте приложение невозможно подписать (а до введения подписывания, приложения с большим манифестом не запускались)
2) WebSQL поддерживается PlayBook'ом, но хотелось бы включать все ресурсы сразу в приложение, а не скачивать при первом запуске…

[Олег Барабанов]

Тогда CDATA XHTML-я + dataURL в помощь. Но это если есть возможность вгрузить ифреймом большой объем данных и проконтролировать его первую загрузку. Про данный трюк, замеченный экспериментальным образом, в скором времени от лица компании хочу рассказать. Если интересно — можно будет связаться, поясню обходной маневр.

Answer 5

[WEBIVAN]

Не знаю всех тонкостей html5, в playbook, но если возможно удалять файлы, возможно стоит сложить «базу» в 1 файл, при первом запуске нарезать его в WebSQL и удалить?

Comments

[anmipo]

К сожалению, удалить не получится — все компоненты приложения упаковываются в один файл, который затем подписывается всякими сертификатами.