okhttp cache что это
Caching¶
OkHttp implements an optional, off by default, Cache. OkHttp aims for RFC correct and pragmatic caching behaviour, following common real-world browser like Firefox/Chrome and server behaviour when ambiguous.
Basic Usage¶
EventListener events¶
Cache Events are exposed via the EventListener API. Typical scenarios are below.
Cache Hit¶
In the ideal scenario the cache can fulfill the request without any conditional call to the network. This will skip the normal events such as DNS, connecting to the network, and downloading the response body.
As recommended by the HTTP RFC the max age of a document is defaulted to 10% of the document’s age at the time it was served based on “Last-Modified”. Default expiration dates aren’t used for URIs containing a query.
Cache Miss¶
Under a cache miss the normal request events are seen but an additional event shows the presence of the cache. Cache Miss will be typical if the item has not been read from the network, is uncacheable, or is past it’s lifetime based on Response cache headers.
Conditional Cache Hit¶
When cache flags require checking the cache results are still valid an early cacheConditionalHit event is received followed by a cache hit or miss. Critically in the cache hit scenario the server won’t send the response body.
Cache directory¶
The cache directory must be exclusively owned by a single instance.
Deleting the cache when it is no longer needed can be done. However this may delete the purpose of the cache which is designed to persist between app restarts.
Pruning the Cache¶
Pruning the entire Cache to clear space temporarily can be done using evictAll.
Removing individual items can be done using the urls iterator. This would be typical after a user initiates a force refresh by a pull to refresh type action.
Troubleshooting¶
Make sure you are reading responses fully as unless they are read fully, cancelled or stalled Responses will not be cached.
How does Android OkHttp cache work?
Le Truong Quoc Thang
Mar 30, 2017 · 4 min read
Life without caching!
Caching is a very interesting topic in software engineering.
Imagine that Facebook app keeps loading the new feed from scratch every time we pull our finger or Google Photos app takes 10s to re-generate all the photo thumbnails every time we open them. That kind of experience would kill our user’s happiness!
We are all good engineers and we really care about user experience.
So in this topic, let’s narrow down that big caching topic into OkHttp cache.
Overview
This simple diagram describes the whole complex story behind:)
Quick questions and answers.
We will not c o ver everything about OkHttp cache because it just follows the Http caching mechanism. If you have no idea about that, read it first: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching. No rush 🙂
1. How to enable the cache?
2. How can I make it works?
Do nothing! Yeah. It automatically parses the cache-related header from the server and stores the response into the cache dir. Next time, when we send the request, it will automatically append the corresponding header for us.
For example, if the server responses:
then next time, OkHttp will set the request header to:
3. How to make it works offline?
If the server gives max-age which tells OkHttp that it can cache the response and use it offline then it will just work.
If max-age is not available or it expires but you still want to use local data, you can fore use it by set request like this:
Then the flow will become:
More generally, if you always want to use local cache whenever there is no Internet:
Note that this interceptor must be added as an application interceptor. If we add it as a network interceptor, it will have no chance to be triggered.
4. Is it a good idea to use OkHttp for data storing? Just use ‘FORCE_CACHE’ and we will always get the cached data?
Those are fundamentally different and should be treated differently. Data should always available, while cache may not.
E.g. login token should be stored, while new feeds should be cached.
Stop for a while, enjoy coffee and think about that…
5. How to decide whether we need the server to validate the cache?
This is done using max-age which tells how long the response can be cached.
For example, you are refreshing your Facebook setting page which has a list of settings. So, that list should stay unchanged for quite sometimes. So instead of return the same response every time, the server can just say max-age=3600 and for all the subsequence requests in the next 1 hour (3600 seconds), the client can just use the local cached data.
6. How does the server decide whether the client can use its cached data or not?
There can be done in a few ways. Basically:
One example is the Gmail app, because the client has no way to know if there are new emails every time the user refreshes, so it can’t just simply use the cached data. What it always does is to send out the last Etag to tell the server what was the last time the user checked their inbox. Then if there is no new email, the server just tells the client to use its cache to display the same email list.
Русские Блоги
Трансфер из: http://blog.csdn.net/copy_yuan/article/details/51524907
OkhttpЭто библиотека доступа к сети с открытым исходным кодом, разработанная SQARE, в настоящее время имеет широкий спектр приложений в разработке Android и Java. В разработке Android иRetrofitОбъединение можно легко вызвать сетевые интерфейсы.
Использование кэша позволяет нашему приложению надолго отображать BrodzyCurries, улучшите пользовательский опыт и сохранить трафик, что очень необходимо использовать кэш в обновлении данных, не очень часто. Если вы хотите присоединиться к кеше, вам не нужен сами по себе. OKHTTP построил кеш, который не используется по умолчанию. Если вы хотите использовать кеш, нам нужно вручную установить.
Кэш поддержки сервера
Если сервер поддерживает кэш, запрос возвращаемый ответ принесет такой заголовок: Cache-Control, MAX-AGE = XXX, в этом случае нам нужно только вручную дать кэш настройки OKHTTP, чтобы OKHTTP автоматически поможет вам кэш. Значение максимального возраста здесь представляет время, когда кеш локально сохраняется, и может устанавливать размер в соответствии с фактическими потребностями.
Сначала мы должны предоставить файл путь для хранения кеша. Для соображений безопасности мы рекомендуем использовать Context.getCachedir () в виде кэшированного пути хранения, и вы можете создать кэш для размера кэша. NS. Следующее:
После создания этого кэша нам также необходимо установить его на объект OkttpClient:
Сервер не поддерживает кэш
Если сервер не поддерживает кэш, он может не указывать этот заголовок, или указанное значение похоже на не магазин, но что мы должны делать, если мы хотим использовать кэш локально? В этом случае нам необходимо использовать перехватчик, чтобы переопределить информацию о головной информации о респомире, так что OHHTTP поддерживает кэш.
Как показано ниже, мы перезаписываем поля ответа на Cache-Control
Затем используйте InterCePter в качестве NetworkInterceptor Добавить в OKHTTPClient:
Таким образом, мы можем использовать кэш, если сервер не поддерживает кэш.
Смотрите полный кодgithub:
A simple Android app shows Hearthstone cards with okhttp, retrofit, dagger2 and Meterail Design
Значение Cache-Control является более сложным. Вот результат RFC-документации и веб-сайта MDN.
Запросить голову
max-age
Клиенту неохотно принимает кеш, который превышает это значение. И не принимайте истекший кэш, если не существует максимальная усталость. Быть
Всегда ценить
max-stale
Если значение, клиент может принять истекшее время, не превышает кэш указанного значения.
Если нет ценности, клиент готов принять кэш-память с истекшим сроком истекшими и независимо от того, как долго это слишком долго.
min-fresh
Клиент готов принять свежесть не менее текущего возраста, чтобы добавить указанный ответ времени. Просто введите в ответ на указанный последующий период времени. Быть
Всегда ценить
no-cache
Клиент масштабируется, и проверка должна быть проверена при использовании кеша. Быть
Неважно
no-store
Клиент проверяется, чтобы не хранить ответ по этому запросу. Тем не менее, нет никакого влияния на содержание, которое кэшируется. Быть
Также говорят, что кэш может построить этот ответ от кэшированных данных. Здесь трудно понять, а ниже фрагмент фрагмента, описанного в этом разделе в RFC7234
https://tools.ietf.org/html/rfc7234#section-5.2.1
Note that if a request containing this directive is satisfied from a
cache, the no-store request directive does not apply to the already
stored response.
https://tools.ietf.org/html/rfc7234#appendix-A
The “no-store” request directive doesn’t apply to responses; i.e., a
cache can satisfy a request with no-store on it and does not
invalidate it.
Неважно
no-transform
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control
Не преобразуйте или преобразуйте ресурсы. Кодировка контента, диапазон контента, тип контента и другие головы HTTP не могут быть изменены по прокси. Например, не прозрачный агент может преобразовать формат изображения для сохранения пробелов кэша или уменьшить трафик на медленной ссылке. Инструкция без преобразования не разрешено делать это. Быть
Неважно
only-if-cached
https://tools.ietf.org/html/rfc7234#section-5.2.1
If it receives this directive, a cache SHOULD either respond using a stored response that is
consistent with the other constraints of the request, or respond with
a 504 (Gateway Timeout) status code.
Отвечать головой
must-revalidate
Как только кэш истекает, исходный сервер должен быть проверен, а истечение не допускается. 504 необходимо возвращать, если вы не можете подключиться. Быть
Неважно
no-cache
Если значение, кэш не допускается, не успешно передавая проверку исходной станции. Быть
Значение, не отправляйте поля заголовка, указанное при проверке. Быть
нравиться Cache-Control: no-cache=»set-cookie,set-cookie2″ Указывает, что не несет печенье для проверки. Быть
Есть меньше в случае наличия значения, здесь есть обсуждение:Без кэши
no-store
Не кэшируйте ответ текущего запроса
Неважно
no-transform
Так же, как и запрос схема
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control
Не преобразуйте или преобразуйте ресурсы. Кодировка контента, диапазон контента, тип контента и другие головы HTTP не могут быть изменены по прокси. Например, не прозрачный агент может преобразовать формат изображения для сохранения пробелов кэша или уменьшить трафик на медленной ссылке. Инструкция без преобразования не разрешено делать это. Быть
Неважно
public
Любой кеш может быть кэширован, даже если ответ не является кэшированным или только частным кешем.
private
Нет значения, общедоступный кэш не сохраняется; даже если он не буфет по умолчанию, частный кеш также может быть сохранен
Значение, эффект не значения, ограниченный указанным полем заголовка. Существует кеш, который не может хранить указанное поле заголовка, в то время как другие поля могут быть кэшированы.
proxy-revalidate
То же самое, что необходимо реоридилировать, но только вступаться в силу для общественных кэшей. Быть
Неважно
max-age
После указанного времени он истекает
Бесполезный
s-maxage
Определяет максимальное время выживания в общественном буфере, который переопределяет максимальный возраст и истекает поля.
3. Простое использование кеша OKHTTP
Кэш в OKHTTP в целом, мы должны настроить в двух местах, чтобы построить okhttpclient, и он должен построить запрос
1. Установите путь кэширования, когда okhttpclient Constructs
Когда мы используем OKHTTP, мы, как правило, получаем приобретение клиента, потому что в большинстве случаев okhttpclient, нам нужен, на самом деле то же самое. В процессе инкапсуляции мы можем установить много свойств, таких как тайм-аут ссылки, прочесть Timeout и т. Д., Который также включает в себя кэш, который мы собираемся сказать, мы можем настроить путь кэширования, настроить путь кэширования, OKHTTP запрос Данные, к которым будут кэшироваться данные. Когда телефон не имеет сети, вы можете загружать данные прямо из кэша. Давайте посмотрим на код:
ОК, после поражения кэша, когда мы запрашиваем данные, то выключите сеть, затем запрашивайте сетевые данные, на этот раз OKHTTP автоматически перезагружает данные из локального кеша.
2. Настройте политику кэширования при построении запроса
Вышеуказанная конфигурация уже должна иметь возможность удовлетворить потребности многих небольших партнеров, но много раз у нас есть много других потребностей, то эти потребности мы можем сделать дальнейшие конфигурации через CacheControl при построении запроса.
При построении запроса мы можем настроить CACHECONTROL, есть два способа построить CACHECONTROL, и он должен напрямую использовать константы в CacheControl, давайте посмотрим на:
2. Построить CACHECONTROL
2.2 Использование констант в CACHECONTROL
Если вы используете константы в CACHECONTROL напрямую, вам не нужно вызывать выше способами, использование выглядит следующим образом:
Русские Блоги
Руководство по использованию кеша OkHttp
HTTP-кеш
В протоколе Http управление кешем контролируется параметром Cache-Control в заголовке. Установив параметр Cache-Control, можно реализовать различные стратегии кэширования.
Набор инструкций запроса (значение в сообщении запроса):
Набор команд ответа (значение в ответном сообщении):
общедоступный: может предоставить кэшированные данные любой стороне;
частный: предоставлять кэшированные данные только определенным пользователям;
no-cache: подтвердите его действительность перед кешированием;
no-store: не кэшировать содержимое запроса или ответа;
max-age: указывает максимальное время кеширования в пределах этого временного диапазона, при обращении к ресурсу непосредственно возвращаются кэшированные данные. Нет необходимости подтверждать валидность ресурсов;
must-revalidate: при доступе к кэшированным данным вам необходимо подтвердить исходному серверу, действительны ли кэшированные данные.Если достоверность не может быть проверена, вам необходимо вернуть 504. Следует отметить, что при использовании этого значения max-stale будет недопустимым.
Для получения более подробной информации, пожалуйста, обратитесь к:Определение поля заголовка HTTP
Поняв теоретические знания HTTP, мы кратко представим кеш в OkHttp позже.
OkHttp перехватчик
OkHttp поддерживает кеширование Http по умолчанию.Пока ответ, возвращаемый сервером, содержит стратегию кэширования, OkHttp будет кэшировать его через перехватчик CacheInterceptor. Но OkHttp не добавляет Cache-Control к HTTP-запросу, созданному по умолчанию.Даже если сервер поддерживает его, мы все равно не можем нормально использовать кешированные данные. Поэтому нам нужно вмешаться в процесс кеширования OkHttp, чтобы он соответствовал нашим потребностям.
Элегантность OkHttp заключается в использовании модели цепочки ответственности, которая реализует каждый шаг в процессе запрос-ответ через перехватчик и предоставляет расширения для головы и хвоста процесса, что также позволяет нам вмешиваться в кеш. Процесс предоставляет возможность. Поэтому перед реализацией кеширования нам нужно иметь общее представление об обработке перехватчиков OkHttp.
Приведенный выше код представляет собой процесс обработки всего перехватчика. Конкретный процесс может относиться к исходному коду. Здесь мы говорим только о базовом процессе: когда запрос инициируется, он будет выполняться в порядке, добавленном в перехватчиках, и в обратном порядке, когда возвращается ответ:
Из этого процесса видно, что если в ответе, возвращаемом сервером, нет Cache-Control, то мы можем реализовать его, добавив сетевой перехватчик. Точно так же при доступе к кэшированным данным мы можем добиться этого, добавив собственный перехватчик.
Использовать кеш OkHttp
Прежде чем мы начнем добавлять стратегию кэширования, давайте сначала разберемся с полной стратегией кэширования:
Вообще говоря, когда есть сеть, использование кеширования еще более усложняется. Здесь мы принимаем упрощенную версию стратегии кэширования (Посещать сервер при наличии сети и возвращать кэшированные данные при отсутствии сети) Чтобы продемонстрировать, как OkHttp использует кеширование.
Во-первых, мы добавляем стратегию кеширования в Response, определяя сетевой перехватчик:
Во-вторых, используйте собственный перехватчик для установки стратегии кэширования запросов:
Примените перехватчик, изменяющий стратегию кэширования запросов и ответов, к OkHttp:
Тогда вы сможете без проблем использовать кэшированные данные без сети.
Не использовать кеш OkHttp
Что делать, если вы считаете, что кэширование OkHttp слишком сложно, и хотите кэшировать данные самостоятельно? Есть два варианта достижения:
Кастомный перехватчик
В этом решении сначала необходимо решить, использовать ли обычный перехватчик или сетевой перехватчик. Мы уже поняли порядок выполнения перехватчика во всем процессе запроса. Следует отметить, что: при отсутствии сети запрос выполняется к CacheIntercepter, Если кэшированных данных нет, они будут возвращены напрямую и не будут выполняться в настраиваемом сетевом перехватчике, поэтому кэширование данных в сетевом перехватчике не подходит. Затем мы можем реализовать это, настроив общий перехватчик. Базовый процесс выглядит следующим образом:
Отслеживайте процесс запроса OkHttp
OkHttp: У тебя совесть не задела этим решением?
Можно сказать, что это решение отказывается от мощной функции перехватчика расширения OkHttp и напрямую взаимодействует с запросами и ответами.Основной процесс выглядит следующим образом:
Сравнение достоинств и недостатков
Оба этих решения отказываются от стратегии кэширования, реализованной самим OkHttp, поэтому они более гибкие, особенно метод мониторинга процесса запроса OkHttp. Но есть и большой недостаток: необходимость реализации модуля кеширования. Конкретная стратегия кэширования, используемая при разработке, может быть измерена в соответствии с существующими модулями кода и требованиями.
быть осторожен
Перехватчик, который изменяет стратегию кэширования ответа, должен быть применен к сетевому перехватчику, в противном случае данные не могут быть кэшированы, потому что во время процесса возврата ответа обычный перехватчик выполняется после встроенного CacheInterceptor;
При изменении Cache-Control of Response max-Age не должен быть слишком большим, в противном случае вы всегда будете получать доступ к кешированным данным в течение указанного max-Age времени (даже если есть сеть);
Руководство по OkHttp
1. Введение
В этой статье мы покажем основы отправки различных типов HTTP-запросов, получения и интерпретации HTTP-ответов и того , как настроить клиента с помощью OkHttp.
Кроме того, мы рассмотрим более сложные варианты использования настройки клиента с использованием настраиваемых заголовков, тайм-аутов, кеширования ответов и т. Д.
2. Обзор OkHttp
Он поставляется с расширенными функциями, такими как пул соединений (если HTTP / 2 недоступен), прозрачное сжатие GZIP и кеширование ответов, чтобы полностью исключить сеть для повторных запросов.
Он также может восстанавливаться после распространенных проблем с подключением, а в случае сбоя подключения, если служба имеет несколько IP-адресов, она может повторить запрос на альтернативные адреса.
На высоком уровне клиент предназначен как для блокировки синхронных, так и для неблокируемых асинхронных вызовов.
После этого краткого обзора давайте рассмотрим несколько примеров использования.
3. Зависимость от Maven
Давайте сначала добавим библиотеку в качестве зависимости в pom.xml :
Чтобы увидеть последнюю зависимость этой библиотеки, посетите страницу в Maven Central.
4. Синхронный GET с OkHttp
5. Асинхронный GET с OkHttp
Чтение тела ответа все еще может блокироваться. OkHttp в настоящее время не предлагает никаких асинхронных API для получения тела ответа по частям:
6. GET с параметрами запроса
После создания URL-адреса мы можем передать его нашему объекту Request :
7. Запрос POST
Давайте посмотрим на простой запрос POST, в котором мы создаем RequestBody для отправки параметров «имя пользователя» и «пароль» :
В нашей статье Краткое руководство по отправке запросов с OkHttp есть больше примеров запросов POST с OkHttp.
8. Загрузка файла
8.1. Загрузить файл
8.2. Получить прогресс загрузки файла
Во-первых, вот метод загрузки:
Вот интерфейс ProgressListener, который позволяет нам наблюдать за процессом загрузки:
Вот ProgressRequestWrapper, расширенная версия RequestBody :
Наконец, вот CountingSink, который является расширенной версией Forwarding Sink :
Обратите внимание, что:
9. Установка собственного заголовка
9.1. Setting a Header on a Request
To set any custom header on a Request we can use a simple addHeader call:
9.2. Setting a Default Header
In this example, we will see how to configure a default header on the Client itself, instead of setting it on each and every request.
For example, if we want to set a content type “application/json” for every request we need to set an interceptor for our client. Here is the method:
And here is the DefaultContentTypeInterceptor which is the extended version of Interceptor:
Note that the interceptor adds the header to the original request.
10. Do Not Follow Redirects
In this example, we’ll see how to configure the OkHttpClient to stop following redirects.
By default, if a GET request is answered with an HTTP 301 Moved Permanently the redirect is automatically followed. In some use cases, that may be perfectly fine, but there are certainly use cases where that’s not desired.
To achieve this behavior, when we build our client, we need to set followRedirects to false.
Note that the response will return an HTTP 301 status code:
If we turn on the redirect with a true parameter (or remove it completely), the client will follow the redirection and the test will fail as the return code will be an HTTP 200.
11. Timeouts
Use timeouts to fail a call when its peer is unreachable. Network failures can be due to client connectivity problems, server availability problems, or anything between. OkHttp supports connect, read, and write timeouts.
In this example, we built our client with a readTimeout of 1 seconds, while the URL is served with 2 seconds of delay:
Note as the test will fail as the client timeout is lower than the resource response time.
12. Canceling a Call
Use Call.cancel() to stop an ongoing call immediately. If a thread is currently writing a request or reading a response, an IOException will be thrown.
Use this to conserve the network when a call is no longer necessary; for example when your user navigates away from an application:
13. Response Caching
To create a Cache, we’ll need a cache directory that we can read and write to, and a limit on the cache’s size.
The client will use it to cache the response:
After launching the test, the response from the first call will not have been cached. A call to the method cacheResponse will return null, while a call to the method networkResponse will return the response from the network.
Also, the cache folder will be filled with the cache files.
The second call execution will produce the opposite effect, as the response will have already been cached. This means that a call to networkResponse will return null while a call to cacheResponse will return the response from the cache.
To prevent a response from using the cache, use CacheControl.FORCE_NETWORK. To prevent it from using the network, use CacheControl.FORCE_CACHE.
Be warned: if you use FORCE_CACHE and the response requires the network, OkHttp will return a 504 Unsatisfiable Request response.
14. Conclusion
In this article, we have seen several examples of how to use OkHttp as an HTTP & HTTP/2 client.
Как всегда, пример кода можно найти в проекте GitHub.