SDWebImageDecoder引发的思考
关于SDWebImage中的SDWebImageDecoder这个类,看完以后有下面几个思考
0.为什么图片要解码
1.这么解码的好处
2.这么解码有坏处吗
图片的格式(png, jpg, gif ,webp,bitMap等等)
jpeg :
(1)有损压缩格式, 将像素信息用jpeg保存成文件再读取出来，其中某些像素值会有少许变化。
(2)没有透明信息
(3)jpeg比较适合用来存储相机拍摄出来的图片
png :
(1) png是一种无损压缩格式
(2) png可以有透明效果
(3)png比较适合矢量图,几何图.
(矢量格式的一大优点就是缩放.矢量格式的图像其实是一组绘图命令.这些指令通常是独立于尺寸的.如果你想要扩大一个圆形,只需在绘制之前扩大他的半径就可以了)
bitMap(位图):
(1)bmp格式没有压缩像素格式
(2)存储在文件中时先有文件头、再图像头、后面就都是像素数据了，上下颠倒存储
最早接触到bitMap是在imageView的layer.shouldRasterize,你是否也用过这个属性
CALayer的shouldRasterize和离屏渲染(offscreen rendering):
开启shouldRasterize后,CALayer会被光栅化为bitmap,layer的阴影等效果也会被保存到bitmap中.
更新已光栅化的layer,会造成大量的offscreen渲染.
offscreen rendring: 指的是在图像在绘制到当前屏幕前,需要先进行一次渲染,之后才绘制到当前屏幕。
离屏渲染有两种:
1 .GPU的离屏渲染(shouldRasterize,mask等layer相关的 )
2 ,CPU的离屏渲染(使用drawRect,和CoreGraphic(线程安全,SDWebImage的解压图片))
离屏渲染消耗性能:(看了好多文章都是这么写的):
原因是显卡需要另外alloc一块内存来进行渲染,渲染完毕后在绘制到当前屏幕,而且对于显卡来说,onscreen到offscreen的上下文环境切换是非常昂贵的(涉及到OpenGL的pipelines和barrier等).
开启栅格化,相当于把部分GPU的工作转到CPU来做了,由CPU生成bitMap,供GPU下次使用.
总结: 开起栅格化的图片的内容不应该经常变化,否则造成大量的离屏渲染.它使用的范围应该是当前layer的显示比较复杂,但却不怎么变化.
就可以开启栅格化,在内存中保留一份,以方便使用.
Advanced Graphics and Animations for iOS Apps
这篇文章比较详细,也介绍了Instruments对性能的测试,对上面有兴趣的可以深看一下.
图片的在内存中的大小
图片在内存中占用的大小 跟图片自身的大小没有关系
内存中占用的大小 = 图片的宽度 * 图片的高度*每个像素占用的字节数
在SDWebImage中衡量大图的标准:
图片的像素总数 > 60M内存所存储的像素数 ? 压缩 : 不压缩.
这个里面的大图处理逻辑个SDWebImage 是完全一样的,介绍更详细,效果看起来也更好,建议看苹果官方的.
基本原理:也就是原图按照定好的大小(像素).来对原图进行切块,然后再一块块的绘制到destContext.
(这里网上Google了好多文章,对这个介绍很少,还是不怎么明白
static const CGFloat kDestSeemOverlap =2.0f;// the numbers of pixels to overlap(重叠) the seems where tiles(切片) meet.
为什么要定义这个,这个为什么会有重合的像素,以及它在后面的代码里面的操作.还望有大神明白指导一下,不胜感激).
这些都是经过压缩编码后的图片格式,是不能直接使用的,其基本原理
图片为什么要解码
png,jpeg格式的数据是不能直接使用的,需要将其转化为位图.
当我们使用imageView显示图片的时候:
1.读取图片
2.解压图片为位图(消耗CPU)
3.如果位图数据不是字节对齐的，CoreAnimation会copy一份位图数据并进行字节对齐
4 CoreAnimation渲染解压缩过的位图
这一切在IOS中都是默认发生在主线程成的并且是在UIImageView执行setImage方法的时候完成的(在UIImage imageNamed的时候不会发生,具体参考下文).
当你使用[UIImage ImageNamed: @"xxx.jpg"]的时候,内存不会有明显变化,只有当调用
UIImageView的setImage的时候,这时候内存才会增加.并且这时候你将imageView移除,内存也不会有减少. 这也是为什么
+ (nullableUIImage*)imageNamed:(NSString*)name;
不适合加载大的 不常用的图片.因为它会默认在程序里保存这张图片数据(不会随ImageView的移除而移除).只有经常使用图片适合这种方式加载.
+ (nullableUIImage*)imageWithContentsOfFile:(NSString*)path;
这个方法跟上面的略有不同,他不会在内存中保留一份数据.只要imageView移除,内存中的数据就会直接移除.这也就是这个方法为什么适合加载大的图片,但却不常用的图片.
这样解码的好处:
把图片解码这个默认在主线程执行,耗损CPU的行为,放在了后台线程.
只需要在使用的时候,直接setImage,不会有太大的CPU消耗
这只是对图片优化的其中一种方式.在图片从下载到显示的过程中有很多个步骤可以优化:
有兴趣的可以参考这篇文章:
Instruments的测试
由于数据比较多,直接做成了gif动画. 细细观察吧
PS:
下面的前两幅图是执行下面这段代码:(图1,图2,内存和CPU的消耗):
(1) 解压是代码执行SDWebImage的:
NSString*path = [[NSBundlemainBundle]pathForResource:@"xxx.jpg"ofType:nil];
UIImage *image = [UIImage imageWithContentsOfFile:path];
_decodeImage = [UIImage decodedImageWithImage :image];(SDWebImage的decodedImageWithImage)方法
(2) 点击灰色区域:
_showImageView.image = _decodeImage;
(3)点击移除
[_showImageView removeFromSuperView];
_decodeImage = nil;
下面的后两幅图是执行下面这段代码:(图3,图4,内存和CPU的消耗):
(1) 点击 使用UIImage imageName加载的按钮 是代码执行的:
_image = [UIImage imageNamed:@"xxx.jpg"];
(2) 点击灰色区域:
_showImageView.image = _image;
(3)点击移除
[_showImageView removeFromSuperView];
_image = nil;
使用SDWebImage的decodedImageWithImage方法解码的时候,内存的占用情况
1
使用SDWebImage的decodedImageWithImage方法解码的时候,CPU的占用情况
2
使用[UIImage imageNamed:@"xxx.jpg"]的内存占用情况
3 这里可以清楚地看到,移除ImageView和指针后,图片没有被销毁,还存在内存中
使用[UIImage imageNamed:@"xxx.jpg"]的CPU占用情况
4
这样解码的弊端:
这样解码就是以空间换时间的方法,提前解压好,用的时候直接从内存读取.
如果下载的图片比较大,然后直接解码的话 这个是内存所不能承受,需要对图片进行压缩.
不过SDWebImage里面也提供了对大图的压缩API.
