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 深色模式适配原理分析

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

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

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

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

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

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

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

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

深入探究Android应用启动起点

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

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

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

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

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

Android 记一次解决问题的过程

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

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

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

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

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

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

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

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

Android SurfaceView 播放gif

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

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

Android Studio 生成so文件 及调用

so文件是C、C++的函数库,在Android中 调用这些库,使用的是JNI( Java Native interface) JNI 可以使Java程序调用本地程序或者库(一般是使用C、C++ 或者汇编语言编写)。 这篇文章 会介绍 使用Android Studio 如何生成so文件,及如何使用so

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

Android 保活从入门到放弃:乖乖引导用户加白名单吧(附7大机型加白示例)

IM在Android上的保活问题经常在即时通讯网的论坛和技术群里被讨论,自从Android 8.0后系统大大降低了后台运行应用的保活容忍度(详见《Android P正式版即将到来:后台应用保活、消息推送的真正噩梦》),保活从黑科技横行的时代进入了技术蛮荒阶段,真要实现保活,技术难度越来越大。

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

安居客 Android APP 走向平台化 | 开发者说·DTalk

安居客 Android App 距离上次的模块化/组件化重构已经两年多了,重构之后很好的支撑了两年多以来的业务发展。但这个世界总是在向前走的,没有任何一种架构能够一劳永逸的解决所有问题,外部环境的不断变化相应的也要求项目架构做出改变,以此来应对环境变化所带来的挑战。

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

Android View 体系竟然还能这么理解?

很多小伙伴可能在学习view的绘制流程源码的时候有点抓不住重点,所以在分析代码的时候绕来绕去脑袋晕乎乎的。今天我就来给大家化繁为简,只关注它最核心的东西。

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

移动端常见崩溃指标

崩溃分析,是将 Android 和 iOS 平台常见的 APP 崩溃问题进行归类分析,帮助企业根据崩溃指标快速发现、定位问题。

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

最多阅读

简化Android的UI开发 11月以前  |  286108次阅读
Android设计与开发工作流 11月以前  |  2808次阅读
Google Enjarify:可代替dex2jar的dex反编译 1年以前  |  2681次阅读
30分钟搭建一个android的私有Maven仓库 1年以前  |  2440次阅读
Android多渠道打包工具:apptools 1年以前  |  2255次阅读
Google Java编程风格规范(中文版) 1年以前  |  2244次阅读
Android UI基本技术点 1年以前  |  2194次阅读
Android权限 - 第一篇 1年以前  |  2178次阅读
Stetho 1年以前  |  2105次阅读
2015 Google IO带来的新 Android 开发工具 1年以前  |  1991次阅读
你应该知道的布局和属性 1年以前  |  1963次阅读
听FackBook工程师讲*Custom ViewGroups* 1年以前  |  1938次阅读
MVP在Android平台上的应用 1年以前  |  1936次阅读
Gradle小知识#3:任务的顺序 1年以前  |  1908次阅读