我是一个辛勤的搬运工(二)
来源:互联网 发布:java函数名命名规则 编辑:程序博客网 时间:2024/04/27 19:29
原文出处
Picasso,Glide,Fresco的前世今生
基本项对比
加载图片耗时及内存对比
without animations
从上面的加载静态图片可以看出三大主流框架性能都不错,不过用数据说话整体而言Glide更胜一筹。
allow animations
上面的数据我们可以忽略Picasso了,因为它根本不支持gif,那么Glide和Fresco可以看出Fresco的Java heap基本保持较低平稳状态,而Glide的Java heap基本为Fresco的一倍,所以OOM的风险也比fresco大一倍。
从时间上glide是有一定差距,不过fresco有两张图片没加载完成,所以时间不是完全可靠的数据
从native heap可以看出Fresco最高545MB,这个有点恐怖,下面我们看个知识点。
知识点
- Java Heap是对于Java 虚拟机而说的,一般的大小上限是 16M 24M 48M 76M 具体视手机而定。
- Native Heap是对于C/C++直接操纵的系统堆内存,所以它的上限一般是具体RAM的2/3左右。
- 所以对于2G的手机而言,Java Heap 大概76M,而Native Heap是760M左右,相差10倍。
所以Fresco也是存在一定风险的,因为native heap数据实在是太恐怖了。
详细属性对比
接下来只详细对比Fresco和Glide
Picasso从各方面都比这两个弱,这里就不浪费时间了,如果想详细了解的可以看本人之前转载的一篇文章
http://blog.csdn.net/github_33304260/article/details/54140164言归正传
compile 'com.github.bumptech.glide:glide:XXX.XXX'
compile 'com.facebook.fresco:fresco:XXX.XXX
初始化直接使用Fresco.initialize(this);
layout普通ImageView独有的SimpleDraweeView圆角, 圆形需要自己实现圆角,继承自BitmapTransformation操作bitmap对象实现通过RoundingParams设置参数缓存Glide内存和磁盘缓存三级缓存,分别是 Bitmap缓存,未解码图片缓存, 文件缓存。缓存图像大小Glide则会根据ImageView控件尺寸获得对应的大小的bitmap来展示,从而缓存也可以针对不同的对象:原始图像(source),结果图像(result)缓存原始图像加载策略Glide只有占位图先加载小尺寸图片,再加载大尺寸的加载进度falsetrue从上面的对比中可以看出来Fresco蛮强大的,不过使用起来相对Glide要复杂一点,而且需要自己的SimpleDraweeView,这一点在切换框架的时候最让人头疼了。而且Glide直接缓存相对大小的图片,节省空间的同时下场如果是同样大小的图片就不要再次请求,直接可以使用。
依赖
Glide
Fresco
要使用完整的Fresco功能就要导入如下的依赖
bitmap操作
Glide
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
Fresco
Fresco要获取bitmap更加复杂, 而且使用起来也并不是那么顺畅。首先,Fresco为了更好地管理bitmap 对象(bitmap对象申请和释放会引起频繁的GC操作,从而引起界面卡顿), 引入了可关闭的引用(CloseableReference), 持有者在离开作用域的时候需要关闭该引用,而我们要获取的bitmap 对象就是可关闭的引用。也就是说,我们不能像上面Glide那样把bitmap 对象取出来传递给其它地方使用, 只能在Fresco提供的作用域范围内使用。
实际项目中会获取缓冲的文件对象:
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
优点
Glide
- 多种图片格式的缓存,适用于更多的内容表现形式(如Gif、WebP、缩略图、Video)
- 生命周期集成(根据Activity或者Fragment的生命周期管理图片加载请求)
- 高效处理Bitmap(bitmap的复用和主动回收,减少系统回收压力)
- 高效的缓存策略,灵活(Picasso只会缓存原始尺寸的图片,Glide缓存的是多种规格),加载速度快且内存开销小(默认Bitmap格式的不同,使得内存开销是Picasso的一半)
Fresco
- 最大的优势在于5.0以下(最低2.3)的bitmap加载。在5.0以下系统,Fresco将图片放到一个特别的内存区域(Ashmem区)
- 大大减少OOM(在更底层的Native层对OOM进行处理,图片将不再占用App的内存)
- 适用于需要高性能加载大量图片的场景
缺点
Glide
-没有文件缓存
-java heap比Fresco高
Fresco
- 包较大(2~3M)
- 用法复杂
- 底层涉及c++领域,阅读源码深入学习难度大
结论
Fresco虽然很强大,但是包很大,依赖很多,使用复杂,而且还要在布局使用SimpleDraweeView控件加载图片。相对而言Glide会轻好多,上手快,使用简单,配置方便,而且从加载速度和性能方面不相上下。对于一般的APP来说Glide是一个不错的选择,如果是专业的图片APP那么Fresco还是必要的。
- 我是一个辛勤的搬运工(二)
- 我是一个辛勤的搬运工(一)
- 我是一个辛勤的搬运工(三)
- Spring简介~~~我是Spring的搬运工
- Spring中IOC的一个简单入门实例(搬运工)
- matlab并行运算之我是搬运工(一)
- 辛勤的小黄鸡
- 辛勤的第四天
- VIM快捷键、设置、操作的记录——我只是一个搬运工(不断搬运中)
- eclipse svn配置 (感谢同事的辛勤劳动)
- 大自然的搬运工(js/css)
- [GitHub的搬运工]roboguice的一个简单的例子
- 搬运工~看到一个很有意思的python程序
- 搬运工整理之HoloLens你的一个HoloLens应用程序 02
- 实习分享之腾讯二面(搬运工)
- 我是一个悲伤的孩子(转载)
- 不知名的搬运工
- echarts: 图表的搬运工
- 关于我用SecureCRT连接出的问题
- 为什么要去了解虚拟机是怎样使用内存的?
- 500. Keyboard Row
- Windows 下CL使用zip/unzip
- 20位活跃在Github上的国内技术大牛
- 我是一个辛勤的搬运工(二)
- Python中socket入门例子
- opencv 将两张图片显示到一幅图片中
- HTTP请求行中包含哪些内容?A、请求方法 B、资源名称 C、版本号 D、状态代码
- 阶段性总结
- web前端初学者相关知识
- linux环境变量设置空格问题
- 使用eclipse连接hadoop失败情况
- Vulkan中Loader和Layer的接口(LoaderAndLayerInterface)