Кэширование текстовых/графических объектов в средах с ограничением производительности

Question

Я работаю над устройствами с ограниченными возможностями. Из-за накладных расходов на запросы AJAX я намерен агрессивно кэшировать текстовые и графические объекты в браузере, но мне нужно настроить размер кэша на одно устройство как на 1MB текста и 9MB изображений - довольно сложная задача для многоэкранное, графическое приложение.

Поскольку устройство легко попадает в пределы памяти, я должен быть очень осторожным в отношении того, как я управляю размером моего приложения: размер файла кода, количество одновременных HTTP-запросов, количество циклов процессора JS при отправке событий, ограничение переходов CSS и т. Д. Мой вопрос сегодня заключается в том, как разработать сдержанный размер кеша для текстовых активов и изображений.

Для текста я развернул свой собственный cache с использованием JSON.encode().length для объектов и 'string'.length для приблизительного размера. Приложение вручную получает/устанавливает записи кэша. При попадании настраиваемого верхнего предела мусор класса собирает себя от gcLimit до gcTarget размеров, придавая вес последним свойствам доступа (то есть, если что-то было доступно в последнее время, пропустите сбор этого объекта в первый раз).

Для изображений я намерен предварительно проинсталлировать элементы интерфейса и позволить браузеру самому заниматься сбором мусора, удаляя элементы DOM и никогда не сохраняя Image() объектов. Для предварительной загрузки я, скорее всего, снова скачу свое - у меня есть примеры для подражания как ImgPreloader FiNGAHOLiC и this. Мне нужно иметь в виду такие функции, как «размер окна загрузки» и «максимальные запросы кеша», чтобы я не случайно перегружал устройство.

Это огромная проблема, работающая в такой ограниченной среде, а общие структуры, такие как Backbone, не поддерживают «max Collection size». В других местах на SO пользователи указывают лимиты 5MB для HTML5 localStorag e, но моя цель - не сохранение сеанса, поэтому я не вижу преимущества.

Я не могу не чувствовать, что могут быть лучшие решения. Идеи?

Редактировать: @ Xotic750: Благодарим за обращение к индексированномуDB. К сожалению, это приложение является стандартной веб-страницей, построенной на Opera/Presto. Еще лучше, платформа не настойчивее. Скала и трудное место: - /.

Answer 1

localStorage and sessionStorage (DOM Storage) лимиты не применяются (or can be overridden), если приложение является расширением браузера (вы не указываете, что представляет собой ваше приложение).

LocalStorage настойчив

sessionStorage является сессионный

Идея

Взгляните на IndexedDB это гораздо более гибким, хотя и не так широко не поддерживается.

Кроме того, некоторые ссылки на хранение Chrome

Managing HTML5 Offline Storage

chrome.storage

Answer 2

С современных JavaScript двигателей производительности CPU/GPU не является проблемой для большинства приложений (за исключением игр, тяжелой анимации или флэш) на даже устройства с низким энергопотреблением, поэтому я подозреваю, что ваши основные проблемы - память и io.Оптимизация для одного типично вредит другому, но я подозреваю, что ниже будут ваши проблемы.

Я не уверен, что вы контролируете использование кеша браузера. Вы можете ограничить память, занятую приложением javascript, с помощью таких методов, как те, которые вы предложили, но браузер все равно сделает это самостоятельно, и это, вероятно, является основной проблемой с точки зрения памяти. Создав свои собственные кеши, вы, вероятно, фактически дублируете данные, которые уже кэшируются браузером и таким образом усугубляют проблему с памятью. Браузер (если вы не используете что-то неясное), как правило, лучше выполняет кэширование, чем это возможно в javascript. В любом случае, я бы настоятельно рекомендовал броузеру заботиться о сборке мусора, поскольку в javascript нет способа заставить браузеры освобождать память (они делают сборку мусора, когда захотят, а не когда вы им рассказываете). У вас есть контроль над тем, какой браузер используется на устройстве? Если вы это сделаете, то изменение этого может быть лучшим способом уменьшить использование памяти (также вы можете ограничить размер кеша браузера?).

Для запросов ajax убедитесь, что вы полностью понимаете разницу между GET и POST, поскольку это имеет большое значение для кеширования в браузере и прокси-серверов, распространяющих сообщения по сети (и, следовательно, также влияет на логику вашего приложения). Посмотрите, можете ли вы минимизировать количество запросов, объединив их вместе (JSON помогает здесь). Как правило, задержка, а не пропускная способность, является проблемой для запросов AJAX (но не заходите слишком далеко, поскольку большинство браузеров могут выполнять несколько запросов одновременно). Убедитесь, что вы сконфигурируете свой менеджер ajax, чтобы разрешить приоритизацию запросов (т. Е. Материал, который влияет на то, что видит пользователь, имеет приоритет перед предварительной загрузкой, приоритет которой определяется аналитикой - половина веб-сайта имеет запрос google analytics, первое, что происходит после загрузки страницы, даже до объявления и загружается другой контент).

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

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

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

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