Fresco:一个新的Android图片加载库

对于Android平台的Facebook来说,快速而高效的展示图片是很重要的。不过近年来,我们在如何高效地存储图片方面遇到了很多问题。图片所需空间很大,而设备上空间很小。每个像素占用4个字节,分别为红、绿、蓝和α透明度。如果一个手机的屏幕尺寸是480*800像素,一张全屏的图片就占用1.5MB的内存。通常手机的内存很少,并且Android设备在众多应用程序之间会平均分配自身的内存。在一些设备上,Facebook程序内存被限制在16MB,可是仅仅一张图片就占用了十分之一!

当你的应用程序运行超出内存时会发生什么?它会crash。我们打算通过创建我们称之为Fresco的库来解决这个问题它能管理图片及其所占内存Crash便随之消失了。

内存区

要了解Facebook的做法,我们需要了解Android上可用的不同内存堆。

严格来说,Java堆是一个棘手问题,每个应用程序由设备制造商所限制。所有通过Java创建出来的对象都存在于此,这是一个存储器使用相对稳定的区域。内存会被垃圾回收,所以当应用程序不再需要内存时,系统会对其自动回收。

不巧的是,垃圾回收的过程恰好是一个难题。为了做到较为彻底的垃圾回收,当系统执行垃圾回收时,Andoid必须停止应用程序。这就是在你使用应用程序的时候,遇到短暂卡顿或停滞的众多常见原因之一。这会困扰用户的使用,同时他们可能会尝试滚动屏幕或者按下按钮,却只看到应用程序在响应之前莫名其妙的等待。

相比之下,native层的堆是通过C++创建出来的。它会有更多的可用内存。应用程序仅仅被设备上可用内存所限制。然而,C++程序管理其所释放的每一个字节,就是说他们会内存泄露,并且最终崩溃。

Android有另一个内存区,叫做ashmem。它的操作很像native层的堆,但是有额外的系统调用。Android可以“取下”内存而不是释放内存。这是一种懒释放,内存只是在系统真正需要更多内存的时候才释放。当Android重新”固定”内存的时候,如果原有的数据没有被释放掉,会仍然存在。

可回收Bitmap

Ashmen不直接和Java应用程序打交道,但有少数例外的情况,图片就是其中之一。当你创建一个解码的(未被压缩的)被称为位图的图片,Android的API允许你指明这个图片是可回收的。

可回收的bitmap存在于ashmem。然而,垃圾回收器不会自动回收它们。Android的系统库在系统绘制图片的时候“固定”内存,在图片销毁的时候“取下”内存。在任何情况下,内存都可以被系统回收。如果被回收的图片需要再次绘制,系统会在运行时再次解码图片。

这似乎是一个完美的解决方案,但问题是运行时解码发生在UI线程。解码是CPU耗时的操作,与此同时UI会停滞。出于这个原因,Google目前不建议使用该功能。他们现在推荐使用一个不同的标志位,叫做inBitmap。然而,这个标志位在Android 3.0之前是不存在的。即使如此,除非应用程序中大部分图片是相同大小的,否则这是没有用的。对于Facebook来说,这种情况不可能出现。直到Android 4.4出现之后,这一限制被打破。然而我们需要一个解决方案,那就是在Android 2.3设备上Facebook用户如何使用的问题。

兼而有之

我们找到一个解决方案,无论在快速的UI还是在高效内存使用上都可以两全其美。如果我们在UI线程之后提前占用内存,并确保它不被回收掉,然后我们可以在ashmem中持有图片而不会遇到UI停滞的情况。碰巧的是,Android Native Development Kit (NDK)具有这样的函数,叫做AndroidBitmap_lockPixels。这个函数原本计划紧跟调用unlockPixels之后,用于再次回收内存。

当意识到不必要这么做的时候,我们取得了突破。即便我们调用lockPixels时没有一个匹配的unlockPixels,也可以在Java堆内存中创建一张图片并不拖慢UI线程。在完成了少量C++代码之后,我们便回家了。

用C++思维写Java代码

正如我们在蜘蛛侠中学到的,“权力越大责任就越大”。持有可回收的位图可以既不使用垃圾回收也不使用ashmem内置的回收特性从而避免内存泄露。我们确实可以自力更生。

在C++中,通常的解决办法是创建实现引用计数的智能的指针类。这些类充分利用C++语言的特性,拷贝构造函数赋值运算符和确定性析构函数。Java中没有这个语法优势,Java中垃圾回收被假定可以打理一切。因此我们终究要找到一个方法,能够在Java中实现C++风格式的保障性。

我们充分利用两个类来做到这一点。其中一个被称为SharedReference它有两个方法addReference和deleteReference调用者应该在它们获取到底层对象或者超出范围的时候调用。一旦引用计数为0,就要回收资源(比如Bitmap.recycle)。

但显而易见的是,在Java开发者在调用这些函数的时候,它会带来很高的易错性。我们选择Java语言来避免这些!因此在SharedReference的顶层,我们创建了CloseableReference接口。这不仅实现了Java Closeable接口,也实现了Cloneable接口。它的构造器和clone()方法调用了addReference(),并且close()方法调用了deleteReference()。因此Java开发者仅仅需要遵循这两个简单的规则:

在给一个新对象分配CloseableReference时,调用.clone()。在越界止前,调用.close(),这些通常写在finally代码块中。这些规则在避免内存泄露方面很有效,并且让我们体验到在诸如Android上的Facebook和Messenger这些大型Java应用程序中的native内存管理方式。

这不仅仅是一个加载器,更是一个管道在移动设备上展示图片包含很多步骤:

Fresco

目前有几个优秀的开源库执行这些序列,仅举几例,比如Picasso、Universal Image Loader、Glide和Volley。他们对于Android的发展做出了巨大的贡献。我们相信我们的新库在一些重要方面会更加成功。

认为这几步是一种管道而不是加载器这本身就很重要。每一步骤都应该尽可能独立,输入一些参数并得到输出结果。一些操作可能是并行的,另一些则是串行的。其中一些只能在特定条件之下执行。至于它们执行在哪些线程上,会有特殊的需求。此外,当我们考虑渐进式图像的时候,整个描述图会变得越来越复杂。许多人在很慢的联网状态下使用Facebook,我们希望这些用户可以尽快看到图片,即使是在图片未下载完成之前。

不用担心,使用streaming吧

过去,Java上的异步代码常常通过类似Future的机制来执行。代码被提交给其他线程,同时检查一个类似Future的对象,看是否能得出结果。然而,假设只会有一个结果。当处理渐进式图像的时候,我们希望有一个完整而持续的结果。

我们的解决方案是使用Future的更广义的版本,叫做DataSource。它提供了一个订阅方法,其调用者一定要传递一个DataSubscriber和一个Executor。该DataSubscriber从DataSource的中间值和最终结果那里接收通知,并且提供一个简单的方法来区分两者。因为我们常常处理对象,这就需要一个明确的close调用,DataSource本身就实现了Closeable。

深入分析之后,其实上述的每一个格子用一个新的框架来实现,叫做Producer/Consumer。绘制图示的灵感来源于ReactiveX框架。我们的系统和RxJava有相似的接口,但其更适于移动设备,并内建了Closeables支持。

该接口保持简单。Producer仅有一个方法produceResults,其中包含了一个Consumer对象。Consumer反过来也有有一个onNewResult方法。

我们用此系统组成了一个生产链。设想我们有这样的一个生产者,其工作是转换 I 类型到 O 类型。实现如下:

这让我们串联起一系列复杂的步骤,并使之保持逻辑上独立。

动画,从单一到复杂

Stickers是存储GIF和WebP格式的动画,深受Facebook用户的喜爱。为了支持它们面临了全新的挑战。一个动画不是一个位图而是一系列位图,其中每一个都要被解码,需要在内存中存储并展示。对于大型动画来说,在内存存储其每一帧是不现实的。

我们建立了AnimatedDrawable,一个可以提供绘制动画的Drawable,以及两个后端处理,一个是GIF,另一个是WebP。AnimatedDrawable实现了标准的Android Animatable接口,因此调用者可以随时开始和停止动画。为了优化内存利用,我们缓存所有内存中足够小的帧,但是如果他们太大的话,我们会在运行时解码。这些操作完全取决于调用者。

两个后端处理都是用C++代码实现的。我们保留两个编码数据和解析元数据的备份,比如宽和高。我们引用计数的数据,在Java端它允许多个Drawables同时访问单一的WebP图片。

我是如何爱你的?让我Drawee这些方法……

当图片正在从网络上下载,我们希望显示占位的图片。如果他们下载失败,我们就显示错误的提示。当图片如期而至,我们便使用快速的淡入动画。我们经常放缩图片,甚至是使用matrix矩阵,并通过硬件加速将图片调整为期望的尺寸。我们瞄准图片中央放缩,图片中央在别处可能是很有用的聚焦点。有时我们想要显示圆角,甚至是正圆形的图片。所有的操作都应该是快速和顺滑的。

我们以前的实现涉及Android View对象,比如在必要的时机对ImageView替换为占位的View。事实证明,这是相当缓慢的。改变Views会强制Android系统执行一次完整的布局传递过程,当用户滑动的时候会明显发生一些用户不愿发生的事情。一个更明智的做法就是使用Android的Drawables,可以在运行时替换它们。

所以我们创建了Drawee。这是一个展示图片的类MVC架构。这个模型叫做DraweeHierarchy。它被用作一个Drawables的层次结构,其中每一个都实现了一个特定的功能,比如成像、分层、淡入或者放缩,这些构成了图像的基础。

DraweeControllers构建了图像管道,或者说是任何图像加载器,同时也考虑到了到后端图像处理。他们从管道接收到了事件回馈并决定如何处理它们。无论在是占位,错误条件或是图片加载完成情况下,它们都操控了DraweeHierarchy的展示内容。

DraweeViews只有有限的功能,但是它们起着决定性作用。它们监听Android系统事件,传递这些view是否显示在屏幕上的消息。当不在屏幕上时,DraweeView会告诉DraweeController去关闭图片使用的资源。这就避免了内存泄露。此外,控制器将告诉图片管道取消网络请求,尽管图片还没有请求结束。因此,就像Facebook经常做的那样,滑动一个很长的图片列表时不会打断网络加载。

有了这些措施,显示图片的繁重工作便不存在了。仅仅调用一个实例化的DraweeView,指定一个URI,同时可以把其它一些参数作为可选项。一切便水到渠成。开发者不需要担心管理图片内存或者流式地更新图片。一切都由库来接管。

Fresco

我们精心构建这个工具集来展示和管理图片,想要分享给Android开发者社区。我们很高兴地宣布,该项目从此开源了。

湿壁画技术是一个数百年来风靡全球的的绘画技术。伴随此名,从文艺复兴时期大师Raphael到斯里兰卡的Sigiriya艺术家都使用了这个形式,我们以如此伟大的艺术家为荣。我们不能相其媲美。我们真心希望Android应用开发者乐于使用我们的库,就像我们乐于构建它一样。

4 收藏 评论

关于作者:treesouth

sina微博:@楠楠戏语 个人主页 · 我的文章 · 10 ·      

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部