一种简单粗暴的数据层网络缓存（一）

安卓app开发中大量使用http接口与服务器交互。目前很多方便的http网络请求开源框架可供使用，比如OKHttp+retrofit可以将http请求Response Body中的json string直接转化成数据实体对象，供业务逻辑使用。与网络交互，经常会有缓存的需求。譬如：

（1）在无网的状态下希望能够有些内容显示，显示上次有网状态下的内容；

（2）为了提高响应速度，尤其是在网络条件不好的情况下，可以考虑先加载本地缓存，同时异步去query网络，待返回后再刷新内容。

http协议层面上，已经提供了缓存的机制，但一般需要服务器支持来确定过期时间。网络框架已经有所支持，譬如OKHttp，甚至可以在服务器不支持的情况下，通过重写Response Header的方式来支持缓存。具体方法网上已经有很多文章供参考，譬如 http://blog.youkuaiyun.com/copy_yuan/article/details/51524907。如图中所示，姑且将app简单地分为三层架构——业务逻辑层、数据层、网络层。这种缓存可以称之为网络层缓存，在网络框架之下，对于其上透明。

但这种缓存对于app而言，有些缺点：完全依赖于http协议和第三方网络框架，app无法定义其使用的逻辑（譬如什么时候使用？是完全无网的情况？返回错误情况？所有情况优先加载？），受限于超时时间等。所以需要一种在数据层面的缓存，其实也可以理解成一种数据持久化，将上次的数据实体缓存下来，下次直接read缓存得到数据实体，与网络层完全脱离关系，什么时候使用完全可控。如上图所示“数据层缓存”。

实现这样的缓存也不难，大概有几种方式：

（1）数据库。优点不用说了，缺点是数据库的设计和维护成本较高，尤其要命的是，在app第一版开发中，常常服务器接口的设计并不稳定，不时会修改字段，这样就需要在数据实体之外，在数据库表字段定义中再修改一次，增加了开发成本。

（2）序列化存储数据对象。序列化是强大的通用工具，但在这个具体问题上，似乎并不高效，因为需要将所有的数据实体实现可序列化，而实际业务逻辑中数据实体可能非常之多，并且很多数据实体并不需要序列化就可以满足业务逻辑的需求。另外，往往有些场景是各种实体的复杂组合，对于序列化和反序列化这又是一个成本。

所以需要一种简单粗暴的，轻的数据层缓存方法。从OKHttp+retrofit的架构原理来看，OKHttp返回的是json字符串，retrofit将json字符串直接转化为数据实体（对业务逻辑透明）。能不能借鉴这个思路，在需要缓存的时候将数据实体（List）对象转化成json字符串，然后持久化这个字符串；使用的时候再读出字符串，并转化成数据实体（List）对象？

这需要一个工具。Gson是谷歌提供的一个在json和java对象直接映射的工具，具体的使用方法可以参考 http://www.jianshu.com/p/e740196225a4。有了这个工具，我们就可以实现上述想法。这是大体的思路，并且已经在实际项目中落地使用。后续有时间会继续写文章讨论实现细节和一些问题。