написать впереди

Для того, чтобы решить проблему мини программы генерации и обмена картинками в кругу друзей, мы включили画家计划--- 一个小程序图片生成库. Программа имеет открытый исходный код и может быть перемещена:GitHub.com/Ku добавил -моб…. Все мы знаем, что рисование на холсте имеет много подводных камней, одним из которых является его метод drawImage, который может быть напрямую установлен на URL-адрес сетевого изображения для рисования в IDE, но это невозможно сделать на реальной машине. С этой ямой нам нужно загрузить картинку на локалку через загрузку, прежде чем мы сможем ее нарисовать. Таким образом, в вашем апплете, если есть необходимость часто рисовать некоторые изображения, и вам нужно использовать сетевые графические материалы, это приведет к повторной загрузке изображений материалов каждый раз, когда вы рисуете, что приведет к большой проблеме с производительностью рисования.

Сам апплет не предоставляет механизма кэширования, такого как файл LRU. за наших画家计划Образ генерируется быстрее, а небольшой программный файл, который мы сами разработали, выполняет соответствующий код для хранения LRU. Таким образом, нам не нужно повторно загружать материалы для рисования, которые могут часто использоваться, что значительно увеличивает скорость рисования.

Представьте систему кэширования апплета

Кэш апплета разделен на две части: кеш данных и кеш файлов. Файловый кеш делится на временный файловый кеш и локальное хранилище файлов. Размер локального хранилища файлов ограничен 10M.

кеш данных

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

Подробнее см. в официальной документации WeChat:

Developers.WeChat.QQ.com/mini программа…

Примечание. Кэш данных является общим в пробной версии, версии для разработчиков и онлайн-версии и не будет изолирован.

файловый временный кеш

После успешного вызова wx.downloadFile или wx.chooseImage для получения файла или изображения мы получим путь временного хранения файла или изображения. В документации говоритсяЖизненный цикл временного пути находится в начале этой небольшой программы..

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

локальное хранилище

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

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

Сведения об интерфейсах, связанных с локальным хранилищем, см. в следующих документах:

Developers.WeChat.QQ.com/mini программа…

Примечание. После успешного вызова временного файла функцией saveFile путь к временному файлу становится недопустимым. Помните, помните.

Реализация хранилища файлов LRU

Локальное хранилище апплета имеет ограничение в 10 МБ, но LRU отсутствует.Теперь нам нужно объединить три метода хранения апплета, упомянутых выше, чтобы реализовать набор механизмов LRU для загрузки файла апплета.

проектирование структуры данных

{
'key': {
        'path': // 文件的存储路径
        'time': // 时间戳，用来记录文件的最后访问时间，当存储不够时，会选择最远未被访问的文件进行删除
        'size': // 文件大小
       }
....
'totalSize': // 所有存储文件的当前总大小
}

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

Вы можете понять, что основная информация о файле хранится в хранилище, а путь эквивалентен указателю на реальный файл.

Общий дизайн процесса

Отказоустойчивость

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

Первый заключается в том, что удаляется определенная информация о файле хранилища, но сам файл не удаляется из-за волшебной ошибки. Кроме того, файл успешно добавлен, но хранилище не добавлено успешно.

Во-вторых, информацию о файле в хранилище удалить не удалось, но файл был удален.

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

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

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

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

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

написать на обороте

Небольшие программы имеют много подводных камней. В настоящее время производительность многих небольших программ на рынке не очень высока. Поэтому, чтобы сделать высокопроизводительную небольшую программу, нам нужно потратить много времени на пробы, ошибки и размышления. Наступить на яму не перестанешь, жизни нет совсем.

В настоящее время этот набор механизмов хранения файлов LRU используется в нашей библиотеке Painter с открытым исходным кодом.Если вы заинтересованы, перейдите по адресу:GitHub.com/Ku добавил -моб….