Android Image Loader 第三方库对比测试

AndroidImage 2015-07

预热知识

测试前，我们需要先明白这样一个问题

Java Heap / Native Heap 各自代表什么？
Bitmap 到底是分配在Java heap上 还是分配到了Native heap上
Java Heap 大小一般是多大，有限制吗？
Native Heap大小一般是多大，有限制吗？
Java OOM 一般是发生在什么时候，和Java Heap有关还是和 Native Heap有关

如果以上问题不是很清楚的话可以参考这个链接，自己恶补一下基础知识：Android进程的内存管理分析

关于上面的几个问题，这里可以小结一下：

Java Heap是对于Java 虚拟机而说的，一般的大小上限是 16M 24M 48M 76M 具体视手机而定。
Native Heap是对于C/C++直接操纵的系统堆内存，所以它的上限一般是具体RAM的2/3左右。
所以对于2G的手机而言，Java Heap 大概76M，而Native Heap是760M左右，相差10倍。

那么Android为啥这么吝啬，给Java Heap分配了这么点内存呢？

Google 既然这么做了，自然有他的道理： 这样设计的目的是为了让Android系统能同时让比较多的进程常驻内存，这样程序启动时就不用每次都重新加载到内存，能够给用户更快的响应。迫使每个应用程序使用较小的内存，移动设备非常有限的RAM就能使比较多的app常驻其中。

我们知道在大多数的Android APP中OOM大多数发生在加载多图片的时候，而很多人会认为Bitmap的实例构造是在JNI层完成的，所以也应该在Native层才对，其实不对，虽然在Native层完成，但是Bitmap的实例构造还是通过Android的虚拟机环境完成的，所以还是在Java Heap中。

对比测试

上面几个问题回答清楚了，接下来我们看看迄今为止比较火的几个Image Loader库

初始化状态

Fresco

Glide

UIL

Volley

Fresco+OkHttp

Picasso

小结

这里需要说清楚的是，其中并非都是静态图，还有大量的Gif动态图，所以，评测的平均加载时间就不太客观了，我们重点看一下上面我们提及的几个概念：

Java Heap 和 Native Heap
从上面的测试可以看出： Frasco/Frasco + OkHttp 表现的和其他几个迥异，前者会动态调整Native Heap而基本保持Java Heap 稳定， 其他几个是相反的。而Java Heap的增长会直接导致OOM的出现。所以可以肯定的说 Frasco可以有效的避免OOM，同时 Frasco还可以显示动态图以及其他特性

基于以上的测试可以发现，孰优孰劣， 一辩便知。