WKWebView максимальный размер кэшируемого объекта - PullRequest
Новая
       21

WKWebView максимальный размер кэшируемого объекта

1 голос
/ 24 октября 2019

У меня есть приложение Ionic для работы с конденсатором IOS (которое использует WKWebView) с локальным html и содержимым Rest API

Кэширование работает для всех конечных точек API, кроме той, которая возвращает довольно большой объем данных (2 МБ в сжатом виде)- 16MB un)

Я бы очень хотел, чтобы это кэшировалось, но, похоже, существует максимальный размер, который WKWebView может хранить.

Если я просто уменьшу объем данных,конечная точка возвращается, затем работает кэширование, т. е. я получаю 304 с

Любые идеи, что такое предел, как увеличить предел или как-то иначе обработать?

Редактировать изпроб и ошибок, как представляется, ограничение составляет 10 МБ (разархивировано - или какое-то странное значение gzipped ~ 1,2 МБ)

1 Ответ

0 голосов
/ 25 октября 2019

Ограничение кешируемого объекта WKWebView составляет 10 МБ, оно хранится в разархивированном виде в кэше.

Кажется невозможным законно увеличить этот предел (<= iOS13 во время записи). </p>

Можно перехватывать запросы с помощью WKWebKit и напрямую использовать URLSession / URLCache. Следует отметить, что URLCache будет хранить ответ только в том случае, если размер ответа <~ 5% от размера кэша - и я думаю, что это та же самая причина, по которой WKWebView не кэширует ответы> = 10 МБ напрямую. Итак, в моем случае мне пришлось создать URLCache ~ 600 МБ, чтобы приспособиться к этому. Я пытался сохранить ответ вручную с помощью storeCachedResponse (_: for :), но, похоже, получал повреждения при его получении - не задумывался, почему наличие 600 МБ кеша почти приемлемо для моего варианта использования.

Состояния документации AppleURLCache будет кэшироваться только в том случае, если:

  • Запрос относится к URL-адресу HTTP или HTTPS (или к вашему собственному сетевому протоколу, который поддерживает кэширование).
  • Запрос выполнен успешно (со статусомкод в диапазоне 200–299).
  • Предоставленный ответ пришел с сервера, а не из кэша.
  • Политика кэширования конфигурации сеанса допускает кэширование.
  • Предоставленная политика кэширования объекта URLRequest (если применимо) разрешает кэширование.
  • Заголовки, связанные с кэшем в ответе сервера (если есть), разрешают кэширование.
  • Размер ответа достаточно мал, чтобы разумно соответствоватьв кеше. (Например, если вы предоставляете кеш диска, ответ должен быть не больше примерно 5% от размера кеша диска.)

source

edit в дополнение к этому я обнаружил, что просто увеличение размера URLCache ненадежно, и довольно часто возникали ошибки в кеше, даже если Etag не изменился. Вместо этого я создал отдельный небольшой URLCache (чуть более чем вдвое больше данных, которые мне нужно хранить). Установите политику кэширования на .reloadIgnoringLocalCacheData и сохраняйте / извлекайте кэшированные данные вручную.

...