1.android volley ImageLoader+ImageCache+LruCache内存缓存的源码
2.Glide源码分析
3.FREE SOLO - 自己动手实现Raft - 17 - leveldb源码分析与调试-3
4.深入源码解析LevelDB

android volley ImageLoader+ImageCache+LruCache内存缓存的

       Volley是Google在Google I/O 上发布的一个网络框架，主要功能：web接口请求，分析网络异步下载，源码支持缓存。分析volley只是源码定义了缓存以及Request的接口，具体实现可以自己定义，分析串口服务器源码例如lru磁盘缓存，源码内存缓存,分析下载的ImageRequest.

       Volley的源代码里包含了一些实现，都在com.Android.volley.toolbox包里，源码包括磁盘缓存、分析json请求,源码请求。还定义了一个继承自ImageView的分析NetworkImageView,可以异步载入网络。

Glide源码分析

       深入剖析Glide源码：解析与理解其架构与机制

       1. Glide三大关键流程

       使用Glide加载时，源码主要包含三大关键流程：with、分析load、源码into。通过链式调用这些方法，能轻松完成加载任务，但背后蕴含的原理复杂且源码规模庞大。分析源码时，需抓住重点。

       1.1 with主线

       with方法是Glide中的重要接口，可传入Activity或Fragment，vcan0源码与页面生命周期紧密关联。在分析中，我们曾遇到线上事故，因伙伴在with方法中传入了Context而非Activity，导致页面消失后请求仍在后台运行，最终刷新页面时找不到加载的容器直接崩溃。因此，with方法与页面生命周期息息相关。

       1.1.1 Glide创建

       通过getRetriever方法最终获得RequestManagerRetriever对象。在Glide的构造方法中，通过双检锁方式创建Glide对象。之后，调用Glide的build方法创建一个Glide实例，传入缓存和Bitmap池等对象。

       1.1.2 RequestManagerRetriever

       Glide的build方法直接创建RequestManagerRetriever对象，需requestManagerFactory参数，若未定义则默认为DEFAULT_FACTORY。获取此对象后，方便后续加载。

       1.1.3 生命周期管理

       在获取RequestManagerRetriever后，调用其get方法。当with方法传入Activity时，老庄指标源码公式会在子线程调用另一个get方法，而主线程中通过fragmentGet方法，创建空Fragment并同步页面生命周期。

       1.1.4 总结

       with方法主要完成：创建Glide对象，绑定页面生命周期。

       1.2 load主线

       通过with方法获得RequetManager，调用load方法创建RequestBuilder对象，将加载类型赋值给model。剩余操作由into方法负责。

       1.3 into主线

       into方法负责Glide的创建和生命周期绑定。传入ImageView，根据其scaleType属性复制RequestOption。into方法调用buildRequest返回Request，并判断是否能执行请求。执行请求或从缓存获取后回调onResourceReady。

       1.3.1 发起请求

       创建request后，调用RequetManager的track方法，执行请求并添加到请求队列。判断isPaused状态，决定是否发起网络请求。成功加载或从缓存获取后回调onResourceReady。

       1.3.2 三级缓存

       通过EngineKey获取资源，收益衡量指标源码从内存、活动缓存和LRUCache中查找。若未获取到，则发起网络请求。成功后加入活跃缓存并回调onResourceReady。

       1.3.3 onResourceReady

       资源加载完成或从缓存获取后，调用SingleRequest的onResourceReady方法。判断是否设置RequestListener，最终调用target的onResourceReady方法，显示。

       1.3.4 小结

       into方法主要步骤包括：创建加载请求、判断请求执行、从缓存获取资源、网络请求与资源回调。

       2. 手写简单Glide框架

       实现Glide需理解其特性，特别是生命周期绑定和三级缓存。手写时，着重实现这两点。在load方法中，支持多种资源加载，并使用RequestOption保存请求参数。在into方法中，色播源码 pan传入ImageView控件，并在buildTargetRequest方法中判断是否发起网络请求。实现三级缓存逻辑，确保加载效率。使用协程进行线程切换，提高性能。通过简单API加载本地或网络链接，实现Glide功能。

FREE SOLO - 自己动手实现Raft - - leveldb源码分析与调试-3

       leveldb的数据流动路径是单向的，从内存中的memtable流向不可变的memtable，最终写入到磁盘上的sorted table文件中。以下是几个关键状态的分析，来了解内存和磁盘上数据的分布。

       以下是分析所涉及的状态：

       1. 数据全在内存中

       随机写入条数据，观察到数据全部存储在memtable中，此时还没有进行compaction操作。

       2. 数据全在磁盘中

       写入大量数据，并等待数据完全落盘后重启leveldb。此时，数据全部存储在磁盘中，分布在不同的level中。在每个level的sstable文件中，可以看到key的最大值与最小值。

       3. 数据部分在内存中，部分在磁盘中

       随机写入条数据，发现内存中的memtable已满，触发compaction操作，数据开始写入到sstable文件。同时，继续写入的数据由于还未达到memtable上限，仍然保存在内存中。

       4. 总结

       通过观察不同数据写入量导致的数据在内存与磁盘间的流动，我们可以看到leveldb内部状态的转换。

       下篇文章将分析LRUCache数据状态的变化。敬请期待！

深入源码解析LevelDB

       深入源码解析LevelDB

       LevelDB总体架构中，sstable文件的生成过程遵循一系列精心设计的步骤。首先，遍历immutable memtable中的key-value对，这些对被写入data_block，每当data_block达到特定大小，构造一个额外的key-value对并写入index_block。在这里，key为data_block的最大key，value为该data_block在sstable中的偏移量和大小。同时，构造filter_block，默认使用bloom filter，用于判断查找的key是否存在于data_block中，显著提升读取性能。meta_index_block随后生成，存储所有filter_block在sstable中的偏移和大小，此策略允许在将来支持生成多个filter_block，进一步提升读取性能。meta_index_block和index_block的偏移和大小保存在sstable的脚注footer中。

       sstable中的block结构遵循一致的模式，包括data_block、index_block和meta_index_block。为提高空间效率，数据按照key的字典顺序存储，采用前缀压缩方法处理。查找某一key时，必须从第一个key开始遍历才能恢复，因此每间隔一定数量（block_restart_interval）的key-value，全量存储一个key，并设置一个restart point。每个block被划分为多个相邻的key-value组成的集合，进行前缀压缩，并在数据区后存储起始位置的偏移。每一个restart都指向一个前缀压缩集合的起始点的偏移位置。最后一个位存储restart数组的大小，表示该block中包含多少个前缀压缩集合。

       filter_block在写入data_block时同步存储，当一个new data_block完成，根据data_block偏移生成一份bit位图存入filter_block，并清空key集合，重新开始存储下一份key集合。

       写入流程涉及日志记录，包括db的sequence number、本次记录中的操作个数及操作的key-value键值对。WriteBatch的batch_data包含多个键值对，leveldb支持延迟写和停止写策略，导致写队列可能堆积多个WriteBatch。为了优化性能，写入时会合并多个WriteBatch的batch_data。日志文件只记录写入memtable中的key-value，每次申请新memtable时也生成新日志文件。

       在写入日志时，对日志文件进行划分为多个K的文件块，每次读写以这样的每K为单位。每次写入的日志记录可能占用1个或多个文件块，因此日志记录块分为Full、First、Middle、Last四种类型，读取时需要拼接。

       读取流程从sstable的层级结构开始，0层文件特别，可能存在key重合，因此需要遍历与查找key有重叠的所有文件，文件编号大的优先查找，因为存储最新数据。非0层文件，一层中的文件之间key不重合，利用版本信息中的元数据进行二分搜索快速定位，仅需查找一个sstable文件。

       LevelDB的sstable文件生成与合并管理版本，通过读取log文件恢复memtable，仅读取文件编号大于等于min_log的日志文件，然后从日志文件中读取key-value键值对。

       LevelDB的LruCache机制分为table cache和block cache，底层实现为个shard的LruCache。table cache缓存sstable的索引数据，类似于文件系统对inode的缓存；block cache缓存block数据，类似于Linux中的page cache。table cache默认大小为，实际缓存的是个sstable文件的索引信息。block cache默认缓存8M字节的block数据。LruCache底层实现包含两个双向链表和一个哈希表，用于管理缓存数据。

       深入了解LevelDB的源码解析，有助于优化数据库性能和理解其高效数据存储机制。