策略1：规则缓存（单纯App本地缓存）

App根据接口数据特性，本地规定缓存以及更新数据策略（例如：登录后更新数据）。即特定场景下指定特定数据源（local，remote）。有些数据不会经常变更，例如用户权限，可以规定在特殊场景下触发Request获取remote数据，其余场景下从本地缓存获取。

减少网络访问次数，数据实时性达不到。

策略2：时效缓存（单纯App本地缓存）

App（或者服务端）根据接口数据特性，规定特定接口缓存时效。即根据不同接口，设置Cache-Control的不同时长。同时根据网络情况，定义断网和联网场景下的缓存时效。

接口1：.header("Cache-Control", "max-age=" + 1000)

接口2：.header("Cache-Control", "max-age=" + 2000)

接口2：.header("Cache-Control", "max-age=" + 3000)

缓存方式：Cache

减少网络访问次数，数据实时性达不到。

策略3：时间戳缓存（参数形式，完全自定义）

App本地缓存接口数据，同时缓存最新接口访问时间戳。

（1）每次访问，上次request时间戳传参给后台（协议定义第一次访问参数形式，例如：“-1”）

（2）由后台判断该时间戳开始，到当前时间点截止，该接口数据有无变更，有：返回data，同时返回本次请求响应的时间戳；无：返回data = null（或协议其他形式）。

（3）App判断响应data是否为空数据（或者定义其他形式的协议），是，获取本地缓存；否，获取响应data，同时更新本地缓存以及本次接口访问时间戳。

说明：

（1）App负责缓存接口数据，最新的接口访问时间戳。

（2）后台负责记录接口数据最新的变更时间戳updateTime，负责对比终端请求参数中，上一次请求时间戳oldRequestTime 和 updateTime：

if(oldRequestTime > updateTime) {

return null;
} else {
return data;
}

（3）本策略，App需自定义并管理Cache。

策略4：Last-Modified-Date（Headers形式，OkHttp缓存策略）

App本地缓存接口数据，同时缓存remote接口数据最后一次变更时间戳。

（1）App第一次请求时，服务器返回接口数据最后一次变更时间点（Headers）：

Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT

（2）App二次请求时，头部加上如下header:

If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT

（3）服务器判断在If-Modified-Since ~ 当前，资源是否被二次修改，否：服务器返回code = 304告知客户端直接复用本地缓存（OkHttp内置缓存拦截器已实现相关策略）；是：服务器正常返回data，同时返回Last-Modified

说明：

App可完全采用OkHttp内置缓存拦截器机制，并自定义CommonHeaderInterceptor拦截器，在每次请求前，把If-Modified-Since添加到Request的Headers中。

策略5：全服务端策略

由服务端记录每个用户（每台设备）对每个数据接口的最后一次访问时间戳lastRequestTime，以及该数据最新update的时间戳lastUpdateTime。当每个用户再次访问数据接口时，服务端对比lastRequestTime和lastUpdateTime的先后顺序，判断是否返回data。

if(lastRequestTime> lastUpdateTime) {

return null;
} else {
return data;
}

App判断响应data是否为空数据（或者定义其他形式的协议），是，获取本地缓存；否，获取响应data。

特殊情况：用户强制使用remote data，服务端不做时间戳对比，直接返回相应数据。

说明：

该策略对端无感知，适合多个团队合作，一个服务器，多个端的情况。但同时服务端需要对每个用户n，每个接口m做最后一次访问时间戳的记录，复杂度n*m。

总结：

策略3,4性能无差，策略4对App而言更容易管理，但要充分考虑Cache大小设置；策略3App需要自己封装一套缓存代码，相应滴，也可以达到自定义缓存方式（sql，cache，文件，等等）的效果。

不同场景下，其实可以考虑把策略1,2，（3,4，5）综合运用，根据业务场景不同，定义相应的接口调用规则（策略1）；再由后台根据接口数据的update实际情况，指定App对不同数据的缓存时效（Cache-Control控制）（策略2），从而减少网络访问次数；同时记录data update time，配合App实现缓存与数据实时性并存（策略3,4）的效果。

说白了，策略1,2缓存的目的是减少网络访问次数，节约网络资源。策略3,4缓存的目的是最大限度节约数据流量，减少带宽压力，同时保证数据实时性。

扩展

对于策略5，服务端可以对接口数据变更时间戳，和用户所有接口访问时间戳同时保存（扩展），为后续用户行为分析，数据安全性等方面提供支持。

App 数据缓存方案相关推荐

米联客FDMA3.1数据缓存方案全网最细讲解，自创升级版，送3套视频和音频缓存工程源码
米联客的FDMA数据缓存方案发布也有五六年了,但真正能熟练使用的兄弟却很少,其实还是没有好的例程作为参考和同熟易懂的讲解,这里我做如下解析: FDMA部分:这部分是米联客封装了用户接口的AXI4-FU ...
自动抓取app数据技术方案总结
在app运营过程中,有时候我们需要了解app中的一些数据,比如:我们自己开的网店,有时候app官方提供的数据并不能满足我们的实际需求,这时就需要使用工具来自动抓取我们自己店铺中有用的数据.一般有两种实 ...
APP开发实战10-APP数据同步方案
3.3数据同步方案 3.3.1 文件的同步通常图片都需要在APP端做缓存处理,所以从服务器端返回图片链接的时候,一定要同时返回图片最新修改的时间戳.APP根据本地存储图片的时间戳和从服务器获取的时间 ...
Memcache,Redis,MongoDB（数据缓存系统）方案对比与分析
一.问题: 数据库表数据量极大(千万条),要求让服务器更加快速地响应用户的需求. 二.解决方案: 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 (这里仅从 ...
无线远程模块的应用，手机APP远程监控PLC数据技术方案
无线远程模块的应用,手机APP远程监控PLC数据技术方案 (巨控何工_原创) 无线远程模块用途:广泛,遍及智能交通.环境保护.政府工作.公共安全.智能消防.工业监测.环境监测.路灯照明管控.景观照明管 ...
Fiddler缓存app数据
Fiddler缓存app数据 (一)配置首先需要一个安卓模拟器,这里使用夜神模拟器,设置Fiddler为代理IP: Fiddler配置也需要修改为app抓包: 在Tools下的Options中设置H ...
App地推数据统计方案：解决业绩结算、渠道归因难题
地推是当下App获客的最有效手段之一,相较于线上推广和渠道买量,有效的地推不仅能更精准的定位目标用户,还可以在短时间内快速起量,尤其适合O2O产品和冷启动时期推广. 作为地推活动开展的重要一环,地推数 ...
基于vue的移动web app页面缓存解决方案
现在移动web app越来越热门了,许多公司开始尝试使用angular.react.vue等MVVM框架来开发单页架构的web app.但在开发web app时,如果希望页面的导航体验也接近原生应用, ...
Windows phone 应用开发[2]-数据缓存
今天把JDi/Server测试做完.终于有了时间来写写关于这个项目总结.关于我在博客上Post这些文章内容都是从实际项目应用而来.当然有些问题解决方案也是不断被重复设计修改.期间也碰到诸多问题.也曾为 ...

App 数据缓存方案