缓存数据到数据库常见策略

1. 概述


这节课我们就来搭建我们自己的一个数据库框架,首先先来说下我们为什么需要去缓存数据到数据库,这个是我们这节课的一个重点,如果咱们大家有做新闻类、资讯类的app,那么凡是涉及到需要展示列表的界面,不管是用 ListView、RecyclerView显示的列表,都是必须要缓存该列表的数据的,主要的原因有两点。

2. 原因


原因一:

如果每次进入app时,比如说我们的应用是一个新闻或者资讯的列表,那么你每次一打开app,它都会去服务器中去请求列表数据,如果说网络不是特别好,那么可能需要2-3秒或者更长的时间后台才能返回数据,然后你再去展示到你的列表中,这样用户体验可能并不是特别好,因为用户如果一进来app时发现没有数据,什么都没有,就是一个空白页面,这样可能或多或少都会影响用户体验,所以这个时候缓存列表数据到数据库就显得尤为重要;

原因二:

如果你对需要展示的列表的数据去缓存,那么你完全可以在有网络的时候让它去请求网络,展示最新的数据,如果没有网络或者网络不是特别好的话,就去展示缓存中的内容,这样就不至于在app刚一打开就是白屏,什么都没有,这样用户体验就会稍微好一些;

注意:

做缓存的话必须两端都需要去做缓存,app端和服务器端需要去做缓存,那么我们接下来先看下常规的后台服务器是以及我们的app,它们是如何做缓存的。

3. app客户端和服务器如何做缓存?


3.1:服务器端缓存方法:

后台有一个缓存,还有一个数据库,每次app请求服务器接口时,后台先去查询缓存中是否有数据,如果缓存中有就直接把缓存中的数据返回给app就ok,如果缓存中没有,就去查询数据库,然后把数据给app返回回来,并且把数据再给缓存中保存一份,这样下次app再去请求服务器接口时就直接可以把缓存中的数据给app返回就可以了。

套路就是:服务器有一个缓存,一个数据库,每次app请求接口时服务器端首先先去查缓存,如果缓存有数据就直接返回就ok,如果没有就去查询数据库,然后把数据给app返回回去,并且把数据再给缓存中存储就ok;

3.2:app缓存方法:

比如OKHttp缓存,它是自带缓存,特点就是如果我们访问同一个接口,那么它在规定时间内,是不会去后台请求数据的,而是直接读取缓存的,如果超过规定时间,就会去后台请求数据。

套路就是:比如说规定时间是60秒,它会首先从本地缓存中查询数据,如果没有它会去请求服务器数据,在获取到数据之后就会把数据给缓存中存储一份,那么下一次就会直接从缓存中读取数据,而不会去请求服务器数据了,这个就是 OKHttp的缓存。

注意:

一般第三方的联网请求缓存基本都是这样子的缓存的,比如OKHttp、Retrofit等等这些第三方网络请求框架的缓存基本都类似。

那么接下来我们就来看下,针对于新闻类app我们应该如何去做缓存,才能达到一个相对来说比较好的用户体验。网上的第三方数据库框架特别多,比如:GreenDao、litepal、orm等等,而且用法基本都类似,都是一些套路,而且我们必须要把这些套路玩好,玩6,。但是它们的数据库都是放在 data/data/包名/database目录下边的,如果app卸载了那么数据库就没了。而且我们没有必要去造轮子,但是有的时候我们我们还真就得对一些特定场景进行量身定制,这个是我们今天要做的。

3. 新闻类app如何缓存?


如下图所示:

新闻类app列表数据缓存方式.png

上图意思就是,以下缓存指的是文件或者数据库都可以:

1>:第一次刚进入app时缓存中肯定没有数据,这个时候就会去请求服务器拉取最新数据,并且也要求服务器最好给自己做一个缓存,把刚请求的数据也给自己服务器保存一份,然后返回数据给app端,这个时候app就去在列表中显示数据,并且app客户端的也需要在文件或者数据库中存储一份数据;
2>:第二次app再次打开的时候需要再次显示列表数据的时候,这个时候首先先在自己本地的文件或者数据库查询,如果有数据,就直接给列表显示,与此同时直接去请求服务器拉取最新数据,如果服务器返回数据了,这个时候比较返回的数据和自己本地缓存的数据,如果数据一样,就不去刷新界面也不去存入到数据库,如果不一样,就去刷新本地列表,然后把新的数据再存储到自己本地的文件或者数据库中就行。
注意这里的存储数据的方式是以key-value键值对存储,key是url地址,value值是 返回的json数据,而不是对象,因为对象太大;

就是这样,每次进入app列表先从app的缓存中读取数据,如果有就直接显示在列表,与此同时直接去请求服务器,如果服务器有数据,就返回给app,然后比较客户端的数据库中的数据与返回的数据是否一样,如果不一样,就去重新刷新列表数据,然后给缓存中再去存储一份数据即可;

这种缓存就比较适合类似头条新闻、QQ空间等等的这种数据更新比较快的。

4. 我们为什么要手动搭建数据库框架?


我们之所以自己要手动去搭建数据库框架,是因为一般第三方的数据库,都是存储在 data/data/包名/database中的,如果app卸载了,那么数据库就没有了,而我们自己写的数据库框架,它是存储在外部存储卡中,可以直接导出来查看,非常的方便。

那么下节课我们就来手动搭建我们自己的数据库。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,829评论 1 331
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,603评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,846评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,600评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,780评论 3 272
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,695评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,136评论 2 293
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,862评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,453评论 0 229
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,942评论 2 233
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,347评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,790评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,293评论 3 221
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,839评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,448评论 0 181
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,564评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,623评论 2 249

推荐阅读更多精彩内容