Как установить кэш iOS и размер дискового хранилища и как кеш восстанавливается из дискового хранилища после завершения работы приложения? - PullRequest
0 голосов
/ 04 октября 2018

Я уже спросил Когда именно удаляются вещи из памяти и диска urlcache?

Теперь у меня есть еще несколько дополнительных вопросов:

  1. Кэш-память ограничена оперативной памятью iPhone (обычно 2 ГБ).Но постоянство диска ограничено 64 ГБ или 128 ГБ.Это правильно?

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

После контрольного нажатия на URLCache.shared я вижу следующие комментарии:

  • Объем памяти: 4 мегабайта (4
  • Емкость диска: 20 мегабайт (20 *1024* 1024 байта) *1024*
  • Путь к диску: (user home directory)/Library/Caches/(application bundle id)

Пользователи, не имеющие специальных требований или ограничений кэшированиядолжен найти экземпляр общего кэша по умолчанию приемлемым.Если этот экземпляр общего кэша по умолчанию неприемлем, можно вызвать +setSharedURLCache:, чтобы установить другой экземпляр NSURLCache, возвращаемый этим методом.Вызывающие абоненты должны позаботиться о том, чтобы вызывающий установщик вызывался в то время, когда ни один другой вызывающий не имеет ссылки на ранее установленный общий кэш URL-адресов.Это сделано для того, чтобы предотвратить сохранение данных кэша неожиданно недоступными.

Так что я думаю, что мое обоснование правильное.


Как работает весь процесс чтения / записи/ восстановление работы кеша?

Я имею в виду, когда я делаю сетевой запрос в первый раз, получается ли, что весь ответ / ошибка / данные записываются / сохраняются в кеше и затем сохраняются?

В следующий раз, если я захочу read , он сначала запускается из кэша, затем, если ответ был not stale / expired, он вернет его.Ничего не изменится для дискового хранилища.

Если срок его действия истек, он отправляет новый запрос и только после получения успешного ответа удаляет ответ из памяти и диска и записывает новый ответ в кэш и диск.Если новый запрос не удался, он не будет очищен, скорее он просто сохранит устаревшие / просроченные данные, поэтому, если мы захотим (загрузить просроченный ответ), он загрузится оттуда?

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

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

Если в обычный день количество сетевых подключений, которые пользователь выполняет в течение типичного 1-часового сеанса, составляет около 30 МБ, тогда я должен установить размер кэша в 20 МБ и 30 МБ дискового пространства?Что делать, если у меня есть изображения?Я слышал, что изображения хранятся по-разному, так как изображение размером 1 МБ может занимать 10 МБ.Так как мне это сделать?

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


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

1 Ответ

0 голосов
/ 13 октября 2018

Если вы хотите глубже познакомиться с управлением памятью, вам следует погрузиться в API более низкого уровня.URLSession, URLCache и т. Д. Являются API высокого уровня.Существует множество сессий WWDC о фреймах памяти, кэшировании изображений, сетевом кэшировании и т. Д. Каждая часть имеет много объяснений.Я предлагаю вам посмотреть все видео WWDC (если вы этого не сделали) для начала и разогрева.Некоторые темы имеют отличное объяснение основных понятий, подобных этому.

посмотрите эти два из WWDC этого года:

Рекомендации по работе с изображениями и графикой

Глубокое погружение в память iOS

Мы можем сидеть здесь и обсуждать ваши вопросы в течение нескольких недель!Но для быстрого ответа:

  1. Да.Память ограничена из-за размера оперативной памяти, а диск ограничен из-за размера памяти.Устройство и iOS могут играть с максимальным ограничением немного из-за их потребностей.
  2. Точно, и это одна из основных целей использования диска.Существует концепция под названием Память подкачки (для более подробных исследований и НИОКР, если хотите)

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

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

Не всегда.По умолчанию, только успешные запросы будут кэшироваться (если сервер не запросил клиента «не кэшировать его» в заголовке).Но, как вы знаете, URLSession имеет множество настроек для кэширования на диске, в памяти и т. Д. В API высокого уровня.См. Документацию URLSession.

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

HomeDirectory содержит несколько основных каталогов.iOS ведет себя по-разному с каждым.iOS будет очищать только каталог tmp (где находится дисковый кеш).Вы можете хранить кэш в другом каталоге, например Documents , чтобы предотвратить его удаление в iOS.Но дело в значении самого слова cache .

Любое меньшее пространство или даже больше места из фактической потребности имеет решающее значение.Это может повредить процесс или тратить память / диск.Помните причину изобретения списков ссылок?Вы можете иметь разные кэши для разных целей, таких как изображения и JSON.Но вопрос об изображениях таков:

Image Memory Use

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

Alamofire и Kingfisher являются отличными примерами.

Заключение

Правильный размер кэша зависит от варианта использования.Зависит от количества вариантов данных, количества изображений, размера каждого изображения, частоты обращения к одному и тому же изображению и т. Д. Например, если вы постоянно меняете изображение в кеше, это может отрицательно сказаться на сроке службы батареи!Лучший способ выбрать подходящий размер кеша - это проверить.Запустите приложение в разделе «Инструменты», чтобы измерить как производительность, так и уровень заряда батареи.Продолжайте увеличивать размер кеша, пока не увидите разницу в производительности.Это самый большой размер, который вам понадобится, по крайней мере, в условиях теста.Затем уменьшайте размер, пока производительность не станет едва приемлемой, чтобы определить наименьший приемлемый размер.Правильный размер находится где-то между этими двумя размерами, в зависимости от того, что вы считаете важным.

...