Ответ на запрос провайдера:
Я вижу это и для маленьких файлов (100 байт). Веб-просмотр
также не может позвонить cachedResponseForRequest:
Я нашел этот вопрос , который напрямую обращается к этому поведению:
Несмотря на документацию Apple с указанием
в противном случае ,
NSURLCache
на iOS вообще не выполняет никакого кэширования диска (флэш). You
может подкласс NSURLCache
изменить поведение выборки и
хранить операции для использования диска (например,
SDURLCache
делает), но из-за
следуя строгим ограничениям того, как кэш используется и реализован,
это не работает так, как вы ожидаете:
NSURLConnection
даже не вызывает storeCachedResponse:forRequest:
для файлов размером более 50 КБ (> = 52428
байты, если быть точным). Это делает подклассы NSURLCache
бессмысленными для
наше использование (изображения 200 КБ), потому что оно даже не попадет в кеш. Как
результат, мы должны добавить кеширование вручную на уровне выше
NSURLConnection
.
Даже когда кто-либо вызывает встроенный NSURLCache storeCachedResponse:forRequest:
вручную, он сохраняет только
ответ в памяти, если он меньше, чем около 180 КБ. Я проверил это
вызываем storeCachedResponse вручную и видим, что до / после
currentMemoryUsage
не изменилось при длине данных выше 180 КБ.
Поэтому мы должны написать и собственное кэширование памяти LRU.
(Акцент мой.)
Кажется, это ответственно за вызываемое поведение. Поскольку текущий принятый ответ указывает , ASIHTTPRequest - ожидаемый обходной путь для этого поведения.
Однако обратите внимание на предостережение в верхней части страницы:
Обратите внимание, что я больше не работаю над этой библиотекой - возможно, вы захотите использовать что-то еще для новых проектов. :)
Вам следует подумать о том, чтобы полагаться на поддерживаемые библиотеки или, если вы предпочитаете, внести свой вклад в эту библиотеку, если она лежит в основе вашего кода.