Android 内存缓存 LruCache 原理与实现

okhttp和glide都使用的lru缓存,那什么是lru缓存呢?android 又是如何实现lru缓存 的呢?

LRU,即Least Recently Used的缩写,就是最近最少使用,通俗意思就是最近最少被使用的会最先被从内存中除去,举个例子:内存大小为3,我们要1,2,3,4,2,3 六个数字,则:

首次调用1,内存里为1;

调用2,内存里为2,1

调用3,内存里为3,2,1

调用4,内存里为4,3,2

调用2,内存里为2,4,3

调用3,内存里为3,2,4

之后我们在存入一个7,则内存里为7,3,2

这里我们看出来,最先被放进内存的,会被最先删除,如果先被放入内存而被调用,则会放到最前面

我们知道了lrucache的原理,那Android是怎么实现LruCache的呢?

在Android中,使用了LinkedHashMap来实现Lru,

我们知道,Java中HashMap是一个哈希表,hashmap本身是无顺序的,而LinkedHashMap是有序的,LinkedHashMap使用双向链表的形式来存储MapEntry的,我们依次往LinkedHashMap中插入1,2,3,4,5,6 六个数字,然后打印遍历结果

插入数据

遍历

遍历结果

然后我们在get("key3"),再插入一个数据7,之后再遍历

get数据后插入数据

遍历结果

我们发现顺序变成了1,2,4,5,6,3,7 其中get 3后3到了表尾,插入7后7到了表尾,为什么会这样呢?这和LinkedHashMap的实现有关:

linkedhashmap链表方式

这样,我们添加数据会添加到链表最后的位置,而LinkedHashMap在初始化中,可以设置为按插入顺序来插入还是get读取顺序

LinkedHashMap 初始化

LinkedHashMap在get数据的时候,会先查找表,如果有,则从链表里删除,移动到表尾,没有,则返回null

//LinkedHashMap get数据

publicVget(Object key) {

LinkedHashMapEntry e = (LinkedHashMapEntry)getEntry(key);//查找表里是否有

//数据,getEntry()为LinkedHashMap继承HashMap方法

if(e ==null)

return null;

e.recordAccess(this);//调用LinkedHashMapEntry的recordAccess()方法

returne.value;

}

我们看LinkedHashMapEntry类

/**

* LinkedHashMap entry.

*/

private static class LinkedHashMapEntry extends HashMapEntry {

LinkedHashMapEntrybefore,after;

LinkedHashMapEntry(inthash,Kkey,Vvalue,HashMapEntry next) {

super(hash,key,value,next);

}

private void remove() {

before.after=after;

after.before=before;

}

private void addBefore(LinkedHashMapEntry existingEntry) {

after= existingEntry;//add value next指向header

before= existingEntry.before;//add value before指向 之前表尾

before.after=this;//之前表尾 next指向 add value

after.before=this;//header before指向 add value

}

void recordAccess(HashMap m) {

LinkedHashMap lm = (LinkedHashMap)m;

if(lm.accessOrder) {//get模式

lm.modCount++;

remove();//从链表中删除

addBefore(lm.header);//添加到表尾

}

}

void recordRemoval(HashMap m) {

remove();

}

}

通过LinkedHashMapEntry的recordAccess我们看到,如果链表中有链表会先将原先的entry 从链表中删除,然后再放到表尾,例如我们使用get方法get 上面 的value1后的链表为以下内容:

LinkedHashMap get value1后

我们发现,LinkedHashMap和Lru的思路是相同的,最近使用的被放在表尾(内存头),而最远时间使用的呗放在表头(内存尾),这样,就可以使用LinkedHashMap来实现lru

我们在初始化LruCache的时候,给LruCache设置最大大小

初始化LruCache

//LruCache get数据方法

public final V get(Kkey) {

if(key ==null) {

throw newNullPointerException("key == null");

}

V mapValue;

synchronized(this) {

mapValue =map.get(key);//从LinkedHashMap中查找,找到则放到表尾

if(mapValue !=null) {

hitCount++;//命中次数+1

return mapValue;

}

missCount++;//没有找到,miss次数加1

}

V createdValue = create(key);//创建新的value

if(createdValue ==null) {//创建失败返回null

return null;//未找到,返回null

}

synchronized(this) {

createCount++;//创建成功 ,创建次数+1

mapValue =map.put(key,createdValue);//put到linkedHashMap中,放到表尾

//如果表中原先有数据并且和creat的不一致,返回旧数据,否则返回null

if(mapValue !=null) {

// There was a conflict so undo that last put

map.put(key,mapValue);//撤销put 新的createValue

}else{

size+= safeSizeOf(key,createdValue);//size大小加上新加数据size

}

}

if(mapValue !=null) {

entryRemoved(false,key,createdValue,mapValue);

return mapValue;

}else{

trimToSize(maxSize);//重新计算空间大小,是否能插入下条数据

returncreatedValue;

}

}

get 数据的时候,如果有数据则返回数据,没有则创建数据,如果创建失败了,则返回null,成功了则插入数据并返回,创建成功其实和put是差不多的

put 插入数据

put 的时候,先计算新加数据的大小,size增加,如果之前有key的数据,size再减去之前数据的大小,最后再重新计算空间大小

trimToSize方法是重新计算空间,如果空间足够,则插入,不够则从表中删除最早插入数据,直到空间足够位置,每次在map中插入数据都要重新计算空间

//LruCatch释放空间

public void trimToSize(intmaxSize) {

while(true) {

K key;

V value;

synchronized(this) {

if(size<0|| (map.isEmpty() &&size!=0)) {

throw newIllegalStateException(getClass().getName()

+".sizeOf() is reporting inconsistent results!");

}

if(size<= maxSize) {//size<=maxSize,返回

break;

}

Map.Entry toEvict =map.eldest();//获取map最早插入数据

if(toEvict ==null) {

break;

}

key = toEvict.getKey();

value = toEvict.getValue();

map.remove(key);//删除数据

size-= safeSizeOf(key,value);//size减少

evictionCount++;

}

entryRemoved(true,key,value, null);

}

}

LinkedHashMap 获取最早插入数据

以上就是Android中自带LruCache的基本实现,其实LruCache的思路就是通过LinkedHashMap去存储或删除数据,最主要的还是get(),put()以及释放数据 的trimToSize()方法,当然这个LruCache只是google简单实现的缓存,我们可以根据需求使用LinkedHashMap自己去实现需要的LruCache


https://mp.weixin.qq.com/s/hCSicmx1ji3QeLkicXYMPQ

Android动态传感器的介绍及其应用

发布于:9天以前  |  69次阅读  |  详细内容 »

Android 实现小红书登陆页面背景图无限滚动效果

发布于:12天以前  |  99次阅读  |  详细内容 »

关于 Android MVVM 一些理解与实践

发布于:1月以前  |  404次阅读  |  详细内容 »

原生 Android 集成 React Native

发布于:1月以前  |  303次阅读  |  详细内容 »

基于 Jenkins 的 Android 持续集成

发布于:2月以前  |  517次阅读  |  详细内容 »

有赞 Android 编译优化方案 Savitar 2.0

发布于:2月以前  |  667次阅读  |  详细内容 »

闲鱼是如何实践一套完整的埋点自动化验证方案的?

搜索推荐算法的精准和埋点数据的准确性息息相关。一旦埋点数据出现问题,用户侧就会出现推荐商品不准确、过度推荐等问题,同时宏观的交易大盘数据的统计也会有偏差,进而影响整个商品运营策略,因此采取有效的手段来保障埋点质量就成为了闲鱼客户端质量保障的关键的一环。

发布于:3月以前  |  671次阅读  |  详细内容 »

Android 样式系统 | 主题背景覆盖

在 Android 样式系统系列的前几篇文章中,我们探讨了样式和主题背景之间的区别,讨论了使用主题背景和主题背景属性的好处,并重点介绍了一些常用的主题背景属性。 今天,我们聚焦于主题背景的实际使用,如何将它们应用到我们的应用中,以及如何构建主题背景。

发布于:5月以前  |  936次阅读  |  详细内容 »

Android 深色模式适配原理分析

从Android10(API 29)开始,在原有的主题适配的基础上,Google开始提供了Force Dark机制,在系统底层直接对颜色和图片进行转换处理,原生支持深色模式。深色模式可以节省电量、改善弱势及强光敏感用户的可视性,并能在环境亮度较暗的时候保护视力,更是夜间活跃用户的强烈需求。对深色模式的适配有利于提升用户口碑。

发布于:6月以前  |  1488次阅读  |  详细内容 »

百度APP-Android H5首屏优化实践

百度App自2016年上半年尝试Feed流业务形态,至2017年下半年,历经10个版本的迭代,基本完成了产品形态的初步探索。在整个Feed流形态的闭环中,新闻详情页(文中称为落地页)作为重要的组成部分,如果打开页面后,loading时间过长,会严重影响用户体验。因此我们针对落地页这种H5的首屏展现速度进行了长期优化,本文会详细阐述整个优化思路和技术细节

发布于:6月以前  |  1183次阅读  |  详细内容 »

Android 10分区存储介绍及百度APP适配实践

Google于 2019年9月3日发布了Android10 release版本,为了更好的保护用户数据并限制设备冗余文件增加,Android 10版本变更了设备外部存储访问方式,外部存储新特性称为分区存储(Scoped Storage), 分区存储遵循以下三个原则对外部存储文件访问方式重新设计,便于用户更好的管理外部存储文件

发布于:6月以前  |  1348次阅读  |  详细内容 »

深入探究Android应用启动起点

开发者文档中提到,Android应用有三种启动状态,每种状态都会影响应用向用户显示所需的时间:冷启动、温启动或热启动。三种启动状态中,冷启动耗时最久,系统和App有较多初始化的工作。如果启动时间过长,可能会导致用户在应用商店打低分,甚至完全弃用app,所以冷启动速度是各个app非常重要的性能指标之一。

发布于:6月以前  |  1149次阅读  |  详细内容 »

一文搞懂Android JetPack组件原理之Lifecycle、LiveData、ViewModel与源码分析技巧

Lifecycle、LiveData和ViewModel作为AAC架构的核心,常常被用在Android业务架构中。在京东商城Android应用中,为了事件传递等个性化需求,比如ViewModel间通信、ViewModel访问Activity等等,以及为了架构的扩展性,我们封装了BaseLiveData和BaseViewModel等基础组件,也对Activity、Fragement和ViewHolder进行了封装,以JDLifecycleBaseActivity、LifecycleBaseFragment和LifecycleBaseViewHolder等组件强化了View层功能,构建出了各业务线统一规范架构的基石。

发布于:6月以前  |  1450次阅读  |  详细内容 »

Android 记一次解决问题的过程

之前我写过一篇文章,介绍我在GitHub开源的滑动控件 ConsecutiveScroller 是如何实现布局吸顶功能的。有兴趣的朋友可以去看一下:Android滑动布局ConsecutiveScrollerLayout实现布局吸顶功能。

发布于:6月以前  |  1087次阅读  |  详细内容 »

Android内存异常机制(用户空间)_NE

常见的Android稳定性异常,有内核异常和Android层异常。内核异常也就是常说的“kernel panic”,简称KE异常;Android层异常又分为java层crash和Native层crash,简称JE、NE异常。 上篇文章介绍了JE异常的抓取机制和处理方式,本文再讲一下NE异常。

发布于:8月以前  |  1637次阅读  |  详细内容 »

Android-模块化-面向接口编程

随着业务的发展,工程的逐渐增大与开发人员增多,很多工程都走向了模块化、组件化、插件化道路,来方便大家的合作开发与降低业务之间的耦合度。现在就和大家谈谈模块化的交互问题,首先看下模块化的几个优势。

发布于:8月以前  |  1987次阅读  |  详细内容 »

Android 机型适配终极篇

发布于:9月以前  |  1812次阅读  |  详细内容 »

Android 内存缓存 LruCache 原理与实现

okhttp和glide都使用的lru缓存,那什么是lru缓存呢?android 又是如何实现lru缓存 的呢?

发布于:9月以前  |  1860次阅读  |  详细内容 »

ijkPlayer编译支持https的so文件-Android

发布于:9月以前  |  1842次阅读  |  详细内容 »

Android SurfaceView 播放gif

Android SurfaceView 是Android系统中的高级组件,它有自己的绘制界面,可以在一个独立的线程进行UI的绘制, 因此不会阻塞主线程,这也是我们使用SuefaceView播放gif图片的原因。

发布于:9月以前  |  1683次阅读  |  详细内容 »

最多阅读

简化Android的UI开发 1年以前  |  442542次阅读
30分钟搭建一个android的私有Maven仓库 2年以前  |  3308次阅读
Android设计与开发工作流 1年以前  |  3223次阅读
Google Enjarify:可代替dex2jar的dex反编译 2年以前  |  3113次阅读
Android多渠道打包工具:apptools 2年以前  |  2673次阅读
Google Java编程风格规范(中文版) 2年以前  |  2640次阅读
Android UI基本技术点 2年以前  |  2632次阅读
Android Studio 生成so文件 及调用 9月以前  |  2535次阅读
Android权限 - 第一篇 2年以前  |  2512次阅读
Stetho 2年以前  |  2437次阅读
2015 Google IO带来的新 Android 开发工具 2年以前  |  2372次阅读
Android死锁初探 9月以前  |  2365次阅读
听FackBook工程师讲*Custom ViewGroups* 2年以前  |  2287次阅读