I/O 2013已经落下帷幕，也让我们对未来的发展有了更大的期待。 今年 I/O 大会上展示的令人兴奋的创新之一就是“库”。 它是一个处理和缓存网络请求的库。 它使开发人员免于在不同应用程序中编写相同代码的泥潭。 编写相同的代码从来都不是一件有趣的事，而且会增加开发人员出错的机会。 这是经过正式考虑和创建的。

如果你还没有看过I/O上介绍的视频，我建议你先看一下，等你有了基本的了解后再继续下面的文章。

在介绍 I/O 时，Ficus 详细讨论了它如何帮助加载图像。 当用作图像加载解决方案时，您会发现虽然它本身处理 L2 缓存，但它请求但不包含内存不足的 L1 图像缓存。 许多人使用过 Image 或较新的库来处理图像缓存； 然而，这些库通常只处理图像的加载和缓存。 那么，我们如何使用替换图像来加载和缓存图像呢？ 首先，我们看一下提供的加载功能，缓存功能将在稍后介绍。

该类需要请求的实例和该类的实现。 通过将 URL 和实例传递给 get() 方法来加载图像。 从那里检查图像，如果图像不在缓存中，则从网络加载图像。

该类替换布局中的类并使用该类。 该类的 () 方法需要一个 URL 路径字符串和一个实例。 然后，它使用 get() 方法检索图像数据。

爪哇

:id="@+id/"

：ft =“真”

：p =“真”

：=“40dp”

：=“40dp”

：=“5dp”

/>

该库的接口允许您使用您首选的 L1 缓存实现。 不幸的是，缺点之一是没有默认的缓存实现。 在 I/O 上演示了代码片段，但库本身不包含任何实现。

该接口有两个方法，(url)和(url,)。 这些存根非常简单，可以添加到任何缓存实现中。

填补空白：添加图像缓存

例如，我创建了一个简单的应用程序，用于搜索“”并在列表视图中显示结果，每列包含用户名和图片。 向下滚动时，列表将自动加载旧记录并从缓存中检索图像。

有两种可用的缓存实现。 推荐的方法是在内存中使用基本的 LRU 缓存。 对于硬盘缓存的实现，我选择使用Jack写的。 我选择这个实现是因为它在社区中经常使用，并且有人提供了一个用于调整自己的应用程序的用例。 使用基于磁盘的 L1 缓存可能会导致阻塞 I/O 问题。 已经存在隐式硬盘二级缓存。 由于我最初不知道缓存处理图像请求，因此已包含硬盘 L1 缓存。

以下是该实现的主要组成部分：

保留对我们的引用。 用于处理我们的数据和图像加载请求。

与图像加载没有直接关系，但它表示如何扩展请求类来处理 JSON 解析。 此类用于 GET 请求和对象结果。

此类是基本的“最近最少使用（LRU）”内存缓存实现。 它速度很快，但不会阻塞 I/O。 这是推荐的方法。

它是该包的位图版本。 它添加位图并从中检索位图，还处理缓存实例化。 硬盘缓存可能会阻塞 I/O。

保留并引用。

在 中，您可能会注意到我们使用 URL 字符串的 () 作为缓存键。 这是因为 URL 中的某些字符不能用作缓存键。

适配器相对简单。 这里我们只需要注意一件事，我们要实现 and 接口，并将适配器作为参数传递给 (,,) 方法。 该适配器包含一些额外的代码来在滚动时加载旧的代码。

爪哇

鸣叫tweet = mData.get();

if(推文！= null){

..(推文.(),.().());

..("@" + 推文.());

..（鸣叫。（））;

..（（鸣叫。（）））;

。 = 推文。();

信息摘要

完成所有这些部分后，图像加载和缓存现在非常简单。 启动时，应用程序初始化类和类中的类。 在这里您可以声明您想要的 L1 缓存类型。 默认实现是内存缓存。

在 中，我们进行第一次调用并加载初始数据。 一旦我们收到返回数据，我们将其传递给并将其设置为 .

在上面的代码中，所有繁重的图像加载操作都得到了处理。 我们只需将获得的实例传递给图像加载器即可。

检查我们的 LRU 缓存实现并返回可用图像。 如果图像不在缓存中，则会从网络中获取。

当您滚动时，会加载更多相应的图像，从而重用缓存中已有的图像。

结束语

虽然它很有用、快速且易于实现，但现在还不是使用它的时候，原因如下：

该库缺乏任何文档和使用示例。

例如，缓存配置组件尚未达到我想要的高度可配置性。

正如您在上面所看到的，排除基本图像缓存实现看起来很奇怪。 包含一个实现或使缓存可配置以满足仅从网络获取所有信息的需求可能更有用。

开发者社区中有很多令人兴奋的消息。 给人的感觉是这个库应该是作为API来使用的，并且引入了很长时间。 就像I/O大会上宣布的新API一样。 很明显，我们正在努力消除应用程序开发的一些障碍，让开发人员的生活变得更轻松。