Android-Universal-Image-Loader学习笔记（二）--LruDiscCache

在正式最近最久未使用缓存（LruDiscCache）之前，先介绍一个概念和重要的三个类：

key:是DiscCacheAware接口中save方法里面的imageUri参数通过调用FileNameGenerator的generate(imageUri)所生成的字符串，key必须满足[a-z0-9_-]{1,64}；对应着Entry,Snapshot以及Editor的key字段。通过以如下方法来检测key的合法性

privatevoid validateKey(String key) {

        Matcher matcher = LEGAL_KEY_PATTERN.matcher(key);

        if (!matcher.matches()) {

            thrownew IllegalArgumentException("keys must match regex [a-z0-9_-]{1,64}: \"" + key + "\"");

        }

    }

Entry：是DiskLruCache里面的内部类,每一个key对应多个缓存图片文件,保存文件的个数是由Entry中lengths数组的长度来决定的，如果追根就地的话是valueCount来决定Entry中封装的文件的个数。（不过在实际初始化缓存的过程中，该每一个Entry中只有一个图片缓存文件与之对应，也就是说一个key对应一个file）

Editor(编辑器)：每一个entry对象又都包含一个Editor，Editor类也是DiskLruCache的一个final类型的内部类；用来负责保存Entry中每一个图片File的文件输出流和输入流，以便于图片缓存文件的输出和读取，在调用缓存的save方法的时候就是获取方法参数imageUri所生成的key对应Entry中的一个Editor对象，从而获取imageUri图片的输出流来把图片写入到缓存中（directory目录中）。

Snapshot: 每一个Entry又有一个Snapshot（快照），当从缓存中调用DisCacheAware方法中的get(String iamgeUri)获取缓存图片时实际上获取的不是Entry，而是imageUri生成key对应Entry的一个快照Snapshot对象所封装的File对象

所以Entry,Editor，Snapshot之间的关系通过key串联了起来：

日志文件：该缓存提供了一个名叫journal的日志文件，典型的日志文件看清来如下格式，用日志文件来决定LRU算法

每个日志文件的开头前面五行数据分别为

第五行过后就是日志的正文，日志正文的格式如下

CLEAN行所代表的数据格式如下

特别说明：f1.length 是key所对应的entry中第一个文件的大小，和f2.length之间用一个空格隔开，具体fn是多少由日志中第四行的数据所决定。如果追根究底的话，是由Entry对象中的lengths数组的长度来决定或者是DiskLruCache的valueCount字段来决定（因为lengths数组的长度初始化的时候就是valueCount）。

REMOVE行READ行以及DIRTY行显示的数据格式较为简单：

下面是源代码中给出的日志样本文件，如图

每行字段的被写入日志文件的时机如下表：

既然有写入日志文件的时机，那么肯定也会提供一个读取日志文件的时机，具体的时机下面讲解open方法初始化缓存的时候会讲到。

当缓存被操作的时候日志文件就会被追加进来。日志文件偶尔会通过丢掉多余行的数据来实现对日志的简化；在对日志进行简化操作的过程中会用到一个名为journal.tmp的临时文件，当缓存被打开的情况下如果journal.tmp文件存在的话就会被删除。

在DiskLruCache类中与日志相关的字段如下所示：

staticfinal String JOURNAL_FILE = "journal";

    staticfinal String JOURNAL_FILE_TEMP = "journal.tmp";

    staticfinal String JOURNAL_FILE_BACKUP = "journal.bkp";

    staticfinal String MAGIC = "libcore.io.DiskLruCache";

    staticfinal String VERSION_1 = "1";

    staticfinallongANY_SEQUENCE_NUMBER = -1;

    staticfinal Pattern LEGAL_KEY_PATTERN = Pattern.compile("[a-z0-9_-]{1,64}");

    privatestaticfinal String CLEAN = "CLEAN";

    privatestaticfinal String DIRTY = "DIRTY";

    privatestaticfinal String REMOVE = "REMOVE";

    privatestaticfinal String READ = "READ";

    privatefinal File journalFile;

    //调用rebuildJorunal重新创建日志文件的时候会把日志信息写入到该文件中去

    privatefinal File journalFileTmp;

    privatefinal File journalFileBackup;

    privatefinalintappVersion;

private Writer journalWriter;

private int reduantOpCount;//用来判断是否重建日志的字段

private int redundantOpCount;

注意：其中的journalWriter，该对象用来向日志文件中写入数据，同时该对象是否为null是作为缓存是否关闭的决定条件：下面三个方法可以说明这个结论

---------------------------------------------------------------------------------------------------

其实，这个类中大部分的方法都是再操作这些日志文件，当然日志文件的大小也有限制，而这个限制就是有redundantOpCount字段决定的，如果如下方法返回true的话就重新建立一个新的日志文件，并把原来的日志文件删除掉

redundantOpCount的值有在四处进行了设定：

get(String key)，remove(Stringkey) completeEdit没调用一次这个方法就会对redundantOpCount进行++操作，而读取日志的方法readJournal则对该字段赋值为redundantOpCount = lineCount - lruEntries.size()；事实上这个readJournal是在调用open方法初始化缓存的时候调用的，也就相当于对redundantOpCount进行了初始化操作。同时当journalRebuildRequired的时候redundantOpCount进行清零操作

-------------------------------------------------------------------------------

介绍了上面的一些基本概念下面说说具体怎么使用这个缓存（介绍流程为：初始化缓存，向缓存中存取数据，从缓存中删除数据以及关闭缓存来进行说明）以及LRU算法实现是怎么体现的。

初始化缓存

由于DiskLruCache的构造函数是私有的，所以不能在外部进行该对象的初始化；DiskLruCache提供了一个静态的open()方法来进行缓存的初始化：

该方法进行如下操作

1）  创建日志文件：主要是对日志备份文件journal.bkp进行处理，如果journal.bkp文件和journal都存在的话就删除journal.bkp文件，如果journal.bkp文件存在而journal文件不存在就把journal.bkp重命名为journal文件。

2）  调用构造器进行缓存对象cache的初始化,初始化的的数据包括日志的三个文件：journal, journal.tmp,journal.bkp;同时还初始化了每一个Entry锁能存储的文件的个数valueCount,缓存的最大内存maxSize和最多缓存多少个文件的maxFileCount;

3)      如果cache.journalFile.exists()==true并且读取日记操作没有IO错误的话，就直接返回上面的cache,否者就重新初始化缓存对象。

也即是说打开缓存的时候有可能初始化两次DiskLruCache的对象，第一次初始化cache1的时候会判断日志文件journalFile是否存在，不存在的话就进行第二次初始化cache2；如果存在的话就进行对journalFile进行IO操作，如果没有出现异常的情况下直接返回cache1,否则返回cache2.逻辑代码的处理如下：

上文刚说过初始化的时候需要读日志进行读取操作，下面重点说说初始化缓存的时候对日志文件进行了哪些操作。

1） 读取日志的方法是由readJournal()来对日式文件journal一行一行的读取，对每一行日志文件的处理是由readJournalLine(String line)方法来决定的，对每一行日式数据的处理实际上式对每行日志的key在lruEnries中对应Entry对象的处理。对每一行文件的处理如下表：

注意：除了读取到REMOVE行直接在lruEntries中删除对应的Entry之外，其余的每一行数据的需要进行如下判断然后在进行处理，主要是向lruEntries中添加Entry对象，（这是第一次添加）：

附带具体方法实现：

2） 调用processJournal()对日志文件进一步处理：遍历lruEntries（lruEntires中的数据在步骤1中的readJournalLine方法中添加的）中的每一个Entry对象，对同编辑状态的Entry进行不同的处理；对于处于非编辑状态的entry。也就是entry.currentEditor==null的entry,计算他们的总的文件数目fileCount以及总的文件的大小size;而entry.currentEditor!=null的Entry（注意是由日志文件中的DIRTY对应的Entry），这些，删除这些entry对应的每一个file，也即是说直接从缓存中删除了这些缓存文件。

3） 初始化journalWriter

到此完成了对缓存的初始化操作，注意这是在读取日志文件时没有抛出异常的时候完成的初始化，如果抛出异常的话，就再次进行如下初始化

到现在最终的缓存初始化操作才算真正的完成！

数据写入缓存

向缓存写入数据时通过DiscCacheWare的两个save方法来实现的：核心思想是从lruEntries中获取指定key（假设该key为123456）对应的Entry对象（如果没有就往lruEntries中添加），然后获取该Entry对象的Editor对象editor,并返回editor。因为这个editor包含了文件的输出流，用该输出流来想缓存中写入数据，从而达到缓存图片的目的。（注意此时向journal文件中写入了DIRTY记录）>

此时lruEntries中和journal文件中的包含的数据如下：

写入缓存成功后调用editor.commit()来完成保存数据的操作，（注意此时向journal文件中写入了CLEAN记录）

如果失败的话调用editor.abort()来撤掉此次的编辑，同时从lruEntries中删除此entry.（注意此时向journal文件中写入了REMOVE记录）

从缓存中取数据：

从缓存中取数据是通过调用DiscCacheWare的get(String imageUri)方法来实现的。前面说过，从缓存中取数据的时候获取的实际上是一个Entry的Snapshot，具体的方法如下：

此时向日志中加READ 记录

通过代码可以发现，当向缓存中取数据的时候需要检测是否重建日志，具体怎么重建，见下文。在此暂不做描述。

从缓存中删除数据

调用DiscCacheAware接口的remove(String imageUri方法)来实现，具体的删除的主要逻辑：

删除缓存中对应的文件，向日志中追加REMOVE行，从lruEntires中删除对应的entry

关闭缓存，清空缓存

通过close方法来实现，具体的逻辑为：

对正在编辑的entry进行撤销操作；

调用trimToSize使得已经使用缓存的大小不超过maxSize

调用trimToFileCount()方法使得缓存中的文件方法小于maxfileCount

关闭日志journalWriter

清空缓存的clear除了以上的逻辑外还对directory进行了删除操作。

--------------------------------------------------------------------------------------------------------------

LruDiscCache,看到这个类的名字就是到该类用到了最近最久未使用（LRU）算法来处理文件缓存。该算法的在该类核心思想的体现就是选择在最近一段时间里最久没有使用过的缓存文件删除。

该类也提供了跟BasicDiscCache一样的默认属性，比如默认缓存的大小为32k，默认压缩后的图片格式为png等等。另外也提供了后备缓存reserveCacheDir，不过跟BasicDiscCache不同的是BasicDiscCache中代表缓存目录的cacheDir在LruDiscCache中用DiskLruCache对象的引用cache来代替。

LruDiscCache提供了一个主要构造函数，该构造函数里面的参数主要用来初始化fileNameGenerator和cache对象。在此构造器中可以设置最大缓存的大小，缓存最多可以保存多少条数据的参数，这些参数都是初始化cache对象所需要的数据。

DiscCache接口提供的方法在LruDiscCache中的核心实现都转移到了cache对象中(或者说是DiskLruCache中)。下面就说说DiskLruCache，然后在掉过头来说LruDiscCache。

该类也定义了一下变量:

另外该类还封装了一个重要类型为LinkedHashMap的属性lruEntries,用它来实现LRU算法（最近最久未使用算法）

用LinkedHashMap能实现LRU算法的原因是在迭代map遍历列表中的元素时最近访问的元素会排在LinkedHashMap的尾部 。在这里简单介绍一个例子作为说明：如果一个LinkedHashMap中通过一个for循环加入了a
b c d e 五个元素，然后调用get方法获取元素a,那么当再次遍历该map的时候iterator.next().getValue()会依次输入b c d e a而不是a b c d e,这样通过最近经常使用的元素（比如get方法获取的元素a）就放在后面，最近最少使用的就排在了链表的前面，从而实现了LRU算法。

最后还有一个long 类型的nextSequenceNumber：为了对新的和旧的快照做区分，每一个entry对象在每一次编辑被提交的时候会获取一个序列号（nextSequenceNumber），如果这个序列号不等于entry的序列号的话，就说明该快照是旧的快照。（最近最久未使用的快照）

在这个缓存中实现对最近最久未使用文件的删除的目的和时机如下：

目的：

1）               在缓存文件总大小超出最大缓存大小maxSize时对最近最久未使用的图片缓存进行删除，核心方法为：trimToSize

2）               在缓存中的文件总数目超过缓存要求的最大文件数目fileCount时对最近最久未使用的的图片缓存进行删除，核心方法为：trimToFileCount

这两个方法调用的时机从总体来说分为三个，由于这些操作涉及到IO操作，费时，所以在代码中交给了一个Callable去处理，具体的核心代码如下

执行Callable的三种时机：

1） 调用setMax方法设置缓存的最大值的时候

2）  成功缓存一个文件的时候，也就是说调用complete第二个参数为true的时候、

3）  对缓存中的文件进行删除的时候

Android-Universal-Image-Loader学习笔记（二）--LruDiscCache