volley 框架剖析(四) 之HTTPCache设计

记得有位高人说过,成功在于细节。同样,一份代码质量如何,同样也在于对细节的处理上。考虑的情况越多,则出现问题的概率也就越低。

Cache之前也写过,但看了Volley的Cache之后,真心觉得差距大了。不废话了,还是上大餐吧

public static class Entry {
        /** The data returned from cache. */
        public byte[] data;

        /** ETag for cache coherency. */
        public String etag;

        /** Date of this response as reported by the server. */
        public long serverDate;

        /** The last modified date for the requested object. */
        public long lastModified;

        /** TTL for this record. */
        public long ttl;

        /** Soft TTL for this record. */
        public long softTtl;

        /** Immutable response headers as received from server; must be non-null. */
        public Map<String, String> responseHeaders = Collections.emptyMap();

        /** True if the entry is expired. */
        public boolean isExpired() {
            return this.ttl < System.currentTimeMillis();
        }

        /** True if a refresh is needed from the original data source. */
        public boolean refreshNeeded() {
            return this.softTtl < System.currentTimeMillis();
        }
    }

还有与之相应的HttpHeaderParser这个类。这个类代码较长,这里就不贴了,主要

还是一个个来介绍吧。

data[]没什么说的,就是数据本身

ETAG

etag 是HTTP头部的一个定义,是HTTP协议提供的若干机制中的一种Web缓存验证机制,并且允许客户端进行缓存协商。这就使得缓存变得更加高效,而且节省带宽。如果资源的内容没有发生改变,Web服务器就不需要发送一个完整的响应。ETag也可用于并发控制,作为一种防止资源同步更新而相互覆盖的方法。Etag的算法没有明确规定,只要冲突的概率低就好了,它可以是时间戳,可以是低冲突的哈希值,甚至也可以是版本号。

怎么使用ETAG呢?通常由服务器在返回的HttpHeader中加入

ETag: "686897696a7c876b7e"

然后客户端再次请求相同URL时,带上

If-None-Match: "686897696a7c876b7e"

如果服务器发现资源没有变,则直接返回304,客户端则可以直接使用本地缓存,如果服务器资源有变,则返回完全的内容。

通过使用ETAG即能节省流量,又能保持本地资源更新。

serverEtag = headers.get("ETag");

serverDate

服务器时间,从Header中取出。

headerValue = headers.get("Date");

取服务器时间是为了防止客户端时间修改导致的问题。

lastModified

同样,这个值也是服务器上下发,告诉客户端上次内容改变的时间。

headerValue = headers.get("Last-Modified");

交互方式与ETAG相同

第一次发起请求,服务器返回

Last-Modified : Fri , 12 May 2006 18:53:33 GMT

第二次发起请求,客户端则带上

If-Modified-Since : Fri , 12 May 2006 18:53:33 GMT

同样,如果页面数据没变,则返回304

读者或会问,这两种方种都行,为什么要定义两个呢。我的理解是Last_Modified对于动态网页无效。另外,多一种方式,在使用的场景上会灵活很多。

ttl****softTtl

说这两个参数,话又长了。得先从HttpHeader中一个叫Cache-Control的说起。

为了节约时间,我这里直接来传送门http://www.blogjava.net/dashi99/archive/2008/12/30/249207.html

总得说来,这两个值就是缓存的生存周期,超过这个时间,就失效了。

这两个值的使用场景如下代码所示。ttl小于了当前时间,则直接过期,当softTtl小于当前时间,需要做刷新操作。

       /** True if the entry is expired. */
        public boolean isExpired() {
            return this.ttl < System.currentTimeMillis();
        }

        /** True if a refresh is needed from the original data source. */
        public boolean refreshNeeded() {
            return this.softTtl < System.currentTimeMillis();
        }

以下是这两个值的获取过程,其中,finalExpire是ttl,softExpire是softTtl.

        // Cache-Control takes precedence over an Expires header, even if both exist and Expires
        // is more restrictive.
        if (hasCacheControl) {
            softExpire = now + maxAge * 1000;
            finalExpire = mustRevalidate
                    ? softExpire
                    : softExpire + staleWhileRevalidate * 1000;
        } else if (serverDate > 0 && serverExpires >= serverDate) {
            // Default semantic for Expire header in HTTP specification is softExpire.
            softExpire = now + (serverExpires - serverDate);
            finalExpire = softExpire;
        }

这个Cache的强大之处就是在于完整实现了HTTP中提到的缓存方式,值得

时间: 2024-08-04 14:04:23

volley 框架剖析(四) 之HTTPCache设计的相关文章

volley 框架剖析(一) 面向接口的编程

Volley是Google出品的一个轻量级的网络框架,默认实现,主要用于小数据量的网络请求.这里就按从粗到细,自上而下的过程,给大家剖析这个牛X的框架. 这个框架的代码量虽少,但却把面向接口的编程这个原则发挥的淋漓尽致.这个框架是怎么构成的呢? 先看包的结构. 有com.android.volley 及 com.android.volley.toolbox两个包. 其中com.android.volley中的接口和类,是基础框架,构成了一个基于队列的网络请求功能. 而com.android.vo

volley 框架剖析(三) Request类精解

Request是所有网络请求的基类,它实现了Comparable接口,前面提到RequestQueue可按照优先级队进行排序,这里的Comparable就是为优先级排序作准备. 接下来,我们对Request中比较重要或有趣的成员或方法进行一一解释. Request中包括一个对支持的Http方法的定义.这里使用的内部接口而不是枚举来实现的. public interface Method { int DEPRECATED_GET_OR_POST = -1; int GET = 0; int POS

Volley框架剖析( 二)从开始到结束

上一篇中,我们分析了Volley的一个总体组成.今天我们继续分析Volley的一个数据流走向,即从初始化到发起请求,再到请求结束的一个流程. 先看初始化. Volley的初始化,实际上就是返回一个RequestQueue的队列.在Volley中调用.一个最简单的创建方式即有一个Context即可. /** * Creates a default instance of the worker pool and calls {@link RequestQueue#start()} on it. *

Volley框架的原理剖析--&gt;

Volley的主要特点: 1.扩展性强.Volley中大多数都是基于接口的设计,可配置性强. 2.一定程度符合Http规范,包括返回ResponseCode的处理,请求头的处理,缓存机制的支持等.并支持重试及优先级定义. 3.默认Android2.3及以上基于HttpURLConnection,2.3以下基于HttpCllient. 4.提供简便的图片加载工具. Volley主要是通过两种Dispatch Thread不断从RequestQueue中取出请求,根据是否已缓存调用Cache或Net

Volley框架源码分析

Volley框架分析Github链接 Volley框架分析 Volley源码解析 为了学习Volley的网络框架,我在AS中将Volley代码重新撸了一遍,感觉这种照抄代码也是一种挺好的学习方式.再分析Volley源码之前,我们先考虑一下,如果我们自己要设计一个网络请求框架,需要实现哪些事情,有哪些注意事项? 我的总结如下: 需要抽象出request请求类(包括url, params, method等),抽象出request请求类之后,我们可以对其继承从而实现丰富的扩展功能. 需要抽象出resp

MFC框架剖析和消息机制

即便是基于MFC的应用程序,建立窗口类也是会遵循如下的过程: 设计窗口类->注册窗口类->生成窗口->显示窗口->更新窗口->消息循环->消息路由到窗口过程函数处理.下面就剖析一下在MFC中是如何完成上述过程的. (1)每个应用程序都有且仅有一个应用类的全局变量theApp,全局变量先于WinMain函数进行处理. (2)WinMain函数体在APPMODUL.CPP文件中,定义如下: extern "C" int WINAPI _tWinMain(

Volley框架源码浅析(一)

尊重原创http://blog.csdn.net/yuanzeyao/article/details/25837897 从今天开始,我打算为大家呈现关于Volley框架的源码分析的文章,Volley框架是Google在2013年发布的,主要用于实现频繁而且粒度比较细小的Http请求,在此之前Android中进行Http请求通常是使用HttpUrlConnection和HttpClient进行,但是使用起来非常麻烦,而且效率比较地下,我想谷歌正式基于此种原因发布了Volley框架,其实出了Voll

Volley框架源码浅析(二)

尊重原创 http://write.blog.csdn.net/postedit/25921795 在前面的一片文章Volley框架浅析(一)中我们知道在RequestQueue这个类中,有两个队列:本地队列和网络队列 /** The cache triage queue. */ private final PriorityBlockingQueue<Request<?>> mCacheQueue = new PriorityBlockingQueue<Request<

Android Volley 框架的使用(一)

为什么要使用Volley框架 开发android应用很多时候都要涉及网络操作,Android SDK中提供了HttpClient 和 HttpUrlConnection两种方式用来处理网络操作,但当应用比较复杂的时候需要我们编写大量的代码处理很多东西:图像缓存,请求的调度等等: 而Volley框架就是为解决这些而生的,它与2013年Google I/O大会上被提出:使得Android应用网络操作更方便更快捷:抽象了底层Http Client等实现的细节,让开发者更专注与产生RESTful Req