Android中巧妙的实现缓存详解

前言

缓存有很多的实现方式,技巧性还有坑都很多,今天我给大家介绍一些非通用的方法,可以巧妙地帮大家简单实现一些内存缓存。

Supplier和Memoize

SQLite是Android里常用的一种数据存储方式,在访问数据库数据时需要通过SQLiteOpenHelper

一份好的数据库连接代码应该能解决以下几个问题:

a) 构建实例比较费资源

b) 数据库连接最好能复用

c) onUpdate等方法在执行时不能和其他实例构成冲突。

这里可以很简单的这样写

Suppliers.memoize(new Supplier<SQLiteOpenHelper>() {
 @Override
 public SQLiteOpenHelper get() {
 return new ...;
 }
})

这段代码利用了Guava提供的一些辅助方法实现Supplier和Memoize和逻辑。顾名思义,Supplier一般被用作factory,generator,builder,closure。Memoize类似于缓存这种概念,它一旦生成了一个实例,在以后的调用中都会返回同一实例,而且,线程安全。

这样写有几个好处,一是需要时才去构建实例,并不会在一开始就去阻塞程序的执行,二是它很简单的用memoize实现了缓存,保证只有一个实例生成。

代码注入

Glow是代码注入的重度使用者,它使我们的代码更加结构化,清晰,简单,同时还节省了不少的开发时间。

Dagger 2是我们实现注入的刀具,有兴趣的同学应该去网站多了解一下相关的内容。除了注入,它还有一些附赠功能,而这些恰巧能被我们用来实现缓存,而且还很简单,我们只需要额外用到几个annotation或接口而已。

@Singleton

相信大家对这个应该比较熟悉,这可是面试时的常问问题。简单来说,它就是单例。因为所以,用了它你不用再担心对这些实例怎么实现缓存了吧。

@Singleton
public class SingletonClass {
}

@Reusable

这是一个新的很酷的功能。单例虽然很好,但有些时候实例可能有些太大,一直放在内存,又不能回收,暂时可能程序也用不到,怎么都感觉有些浪费。很多情况下,我们并没有那么严格的要求需要唯一的一个实例,能重用就重用,没有重新实例化一个就行。这就是@Reusable的使用场景,假如已有一个生成的实例,重用它就行,不行重新实例化,不需要保证。

@Reusable
public class ReusableClass {
}

Lazy

Lazy使用的地方和前两者有些不同。@Singleton和@Reusable一般用在provides或类型定义的地方,但Lazy则是用在使用时,它的使用效果和最开始讲到的Supplier和Memoize类似。

@Inject
Lazy<SQLiteOpenHelper> lazySQLiteOpenHelper;

这里不会先生成SQLiteOpenHelper实例,直到你开始调用lazySQLiteOpenHelper.get() 。而一旦第一次实例化结束,以后的调用都会返回第一次的结果。

Observable

在使用app的过程中,很多数据需要从服务器端获取。在我们app里,每天会为用户提供一些订制化内容,这些内容短期内不会改变,每次从服务器端去取太过耗时,但放到数据库或文件这些持久化存储里似乎不太必要。综合考虑后,似乎内存缓存是个不错的选择。

于是这个缓存需要提供以下功能,首先,它是个缓存,其次,它的结构需要很简单,因为很多地方需要用到,再次,它得线程安全。

后来我们的实现方案很简单,利用Retrofit和Observable提供的一些方法。

private static final long EXPIRE_MS = 5 * 60 * 1000;
 private Pair<Long, Observable<Content>> cache;
 public synchronized Observable<Content> getDailyContent() {
 if (cache == null || cache.first + EXPIRE_MS < System.currentTimeMillis()) {
  cache = Pair.create(System.currentTimeMillis(), serverApi.getContent());
 }
 return cache.second;
 }

这个方法的本质是利用Retrofit返回的Observable对象,然后Observable会提供一个类似缓存的cache方法,这样在subscribe之前,这个网络请求不会被发出,但一旦有了结果,后来的调用者都会得到同样的结果。

注意

缓存虽好,用起来很快捷方便,但在使用过程中,大家一定要注意数据更新和线程安全,不要出现脏数据。

总结

以上就是Android中巧妙实现缓存的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流。

(0)

相关推荐

  • Android实现WebView删除缓存的方法

    本文实例讲述了Android实现WebView删除缓存的方法.分享给大家供大家参考.具体如下: 删除保存于手机上的缓存: // clear the cache before time numDays private int clearCacheFolder(File dir, long numDays) { int deletedFiles = 0; if (dir!= null && dir.isDirectory()) { try { for (File child:dir.listF

  • android中图片的三级缓存cache策略(内存/文件/网络)

    1.简介 现在android应用中不可避免的要使用图片,有些图片是可以变化的,需要每次启动时从网络拉取,这种场景在有广告位的应用以及纯图片应用(比如百度美拍)中比较多. 现在有一个问题:假如每次启动的时候都从网络拉取图片的话,势必会消耗很多流量.在当前的状况下,对于非wifi用户来说,流量还是很贵的,一个很耗流量的应用,其用户数量级肯定要受到影响.当然,我想,向百度美拍这样的应用,必然也有其内部的图片缓存策略.总之,图片缓存是很重要而且是必须的. 2.图片缓存的原理 实现图片缓存也不难,需要有相

  • android开发教程之清除android数据缓存示例(清除本地数据缓存)

    复制代码 代码如下: /*  * 文 件 名:  DataCleanManager.java  * 描    述:  主要功能有清除内/外缓存,清除数据库,清除sharedPreference,清除files和清除自定义目录  */ import java.io.File;import android.content.Context;import android.os.Environment; /** * 本应用数据清除管理器 */public class DataCleanManager { 

  • Android中加载网络资源时的优化可使用(线程+缓存)解决

    网上关于这个方面的文章也不少,基本的思路是线程+缓存来解决.下面提出一些优化: 1.采用线程池 2.内存缓存+文件缓存 3.内存缓存中网上很多是采用SoftReference来防止堆溢出,这儿严格限制只能使用最大JVM内存的1/4 4.对下载的图片进行按比例缩放,以减少内存的消耗 具体的代码里面说明.先放上内存缓存类的代码MemoryCache.java: 复制代码 代码如下: <SPAN style="FONT-SIZE: 18px"><STRONG>publ

  • Android中的Retrofit+OkHttp+RxJava缓存架构使用

    RxJava如何与Retrofit结合 先扔出build.gradle文件的内容 dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) testCompile 'junit:junit:4.12' compile 'com.android.support:appcompat-v7:23.2.0' compile 'io.reactivex:rxjava:1.1.0' compile 'io.reactivex:rxand

  • Android中Glide加载库的图片缓存配置究极指南

    零.选择Glide 为什么图片加载我首先推荐Glide? 图片加载框架用了不少,从afinal框架的afinalBitmap,Xutils的BitmapUtils,老牌框架universalImageLoader,著名开源组织square的picasso,google推荐的glide到FaceBook推出的fresco.这些我前前后后都体验过,那么面对这么多的框架,该如何选择呢?下面简单分析下我的看法. afinal和Xuils在github上作者已经停止维护了,开源社区最新的框架要属KJFra

  • Android中使用二级缓存、异步加载批量加载图片完整案例

    一.问题描述 Android应用中经常涉及从网络中加载大量图片,为提升加载速度和效率,减少网络流量都会采用二级缓存和异步加载机制,所谓二级缓存就是通过先从内存中获取.再从文件中获取,最后才会访问网络.内存缓存(一级)本质上是Map集合以key-value对的方式存储图片的url和Bitmap信息,由于内存缓存会造成堆内存泄露, 管理相对复杂一些,可采用第三方组件,对于有经验的可自己编写组件,而文件缓存比较简单通常自己封装一下即可.下面就通过案例看如何实现网络图片加载的优化. 二.案例介绍 案例新

  • Android实现离线缓存的方法

    离线缓存就是在网络畅通的情况下将从服务器收到的数据保存到本地,当网络断开之后直接读取本地文件中的数据.如Json 数据缓存到本地,在断网的状态下启动APP时读取本地缓存数据显示在界面上,常用的APP(网易新闻.知乎等等)都是支持离线缓存的,这样带来了更好的用户体验. 如果能够在调用网络接口后自动缓存返回的Json数据,下次在断网状态下调用这个接口获取到缓存的Json数据的话,那该多好呢?Volley做到了这一点. 因此,今天这篇文章介绍的就是使用Volley自带的数据缓存,配合Universal

  • android异步加载图片并缓存到本地实现方法

    在android项目中访问网络图片是非常普遍性的事情,如果我们每次请求都要访问网络来获取图片,会非常耗费流量,而且图片占用内存空间也比较大,图片过多且不释放的话很容易造成内存溢出.针对上面遇到的两个问题,首先耗费流量我们可以将图片第一次加载上面缓存到本地,以后如果本地有就直接从本地加载.图片过多造成内存溢出,这个是最不容易解决的,要想一些好的缓存策略,比如大图片使用LRU缓存策略或懒加载缓存策略.今天首先介绍一下本地缓存图片. 首先看一下异步加载缓存本地代码: 复制代码 代码如下: public

  • android上的一个网络接口和图片缓存框架enif简析

    1.底层网络接口采用apache的httpclient连接池框架: 2.图片缓存采用基于LRU的算法: 3.网络接口采用监听者模式: 4.包含图片的OOM处理(及时回收处理技术的应用): 图片核心处理类:CacheView.java 复制代码 代码如下: package xiaogang.enif.image; import java.io.FilterInputStream; import java.io.IOException; import java.io.InputStream; imp

随机推荐