[关闭]
@linux1s1s 2019-02-15T08:30:42.000000Z 字数 1110 阅读 2400

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还可以显示动态图以及其他特性

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

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注