篇1:SDWebImage源码看图片解码

导语:这是SDWebImage源码理解的第一篇,本篇先介绍图片解码相关的背景知识,然后介绍SDWebImage中解码的源码及其解码相关的问题。

一、背景知识

在SDWebImage中处理图片解码的是SDWebImageDecoder

1、图片加载
  • iOS 提供了两种加载图片方法,分别是UIIImage的imageNamed: 和 UIIImage的imageWithContentsOfFile:

  • 其中,imageNamed: 方法的特点在于可以缓存已经加载的图片;使用时,先根据文件名在系统缓存中寻找图片,如果找到了就返回;如果没有,从Bundle内找到该文件,在渲染到屏幕时才解码图片,并将解码结果保留到缓存中;当收到内存警告时,缓存会被清空。当频繁加载同一张图片时,使用imageNamed: 效果比较好。而imageWithContentsOfFile:仅加载图片,不缓存图像数据。

  • 虽然imageNamed: 方法利用缓存优化了图片的加载性能,但是第一次加载图片时,只在渲染的时候才在主线程解码,性能并不高效,尤其是在列表中加载多张高分辨率的图片(大图),可能会造成卡顿;

    说明:这里抛出图片解码的概念,SDWebImageDecoder这个类是为了优化解码效率存在的。

2、图片解码
  • 图像可以分为矢量图位图,显示到屏幕中的图像是位图图像,位图图片格式有RGB、CMYK等颜色模式;其中RGB是最常用的颜色模式,它通过红(R)、绿(G)、蓝(B)三个颜色通道的数值表示颜色。手机显示屏使用自带Aphal通道(RGBA)的RGB32格式。

  • 在项目中,通常使用的图片是JPG或PNG压缩格式,它们是经过编码压缩后的图片格式;而图片显示到屏幕之前,需要将JPG/PNG格式的图片解码位图图像;这个解码工作是比较耗时的,而且不能使用GPU硬解码,只能通过CPU软解码实现(硬解码是通过解码电路实现,软解码是通过解码算法、CPU的通用计算等方式实现软件层面的解码,效率不如GPU硬解码)。

  • iOS默认会在UI主线程对图像进行解码,解码后的图像大小和图片的宽高像素有关,宽高像素越大,位图图像就越大。假设一个3MB的图片,其宽高像素为2048 * 2048的图片,解码后的位图图像大小是16MB(2048 * 2048 * 4)。

    //位图大小的计算公式,其中bytesPerPixel = 4B
    bitmap_size = imageSize.width * imageSize.height * bytesPerPixel
    
  • 优化解码耗时的思路是:将耗时的解码工作放在子线程中完成。SDWebImage和FastImageCache就是这么做的。具体的解码工作就是SDWebImageDecoder负责的。

3、图片重采样
  • 在图片显示到屏幕前,除了要在主线程中解码,还会在主线程中完成重采样的工作。重采样算法一般有: Nearest Neighbour Resampling (最邻近重采样)、 Bilinear Resampling(双线性/两次线性重采样)、Bicubic Resampling (双立方/两次立方重采样)等。

  • Nearest Neighbour Resampling比较简单暴力,根据目标图像的宽高 与源图像的宽高比值,取源图像相对位置的像素点的值作为目标像素点的值;而Bilinear Resampling参考源像素位置周围4个点的值,按一定权重获得目标图像像素点的值;而Bicubic Resampling参考源像素点周围4*4个点的值,按一定权重获得目标图像像素点的值。

  • 图像的放大和缩小都会引起重采样,放大图像称为上采样/插值(upsamping),缩小图像称为小采样(downsampling)。当图片的size和imageView的size不同时,发生重采样。

4、总结
  • 总结1SDWebImage 利用空间换时间的做法,在子线程中解码图片并缓存位图结果,避免图片的重复解码,提升图片展示性能。如果列表中需要展示很多网络图片,SDWebImage这种做法,有利于提高列表的流畅度。

  • 总结2:SDWebImage中下载的图片,即使解码缩放(decodedAndScaledDownImageWithImage:)后,图片大小 未必 和imageView的大小相同,这会引发重采样,我们可以在图片显示前,将图片裁剪成和imageView的大小相同,提升性能(一个小的优化点)。

二、源码说明

SDWebImageDecoder的源码有200多行,重要的函数两个。其一是:(默认)解码图片办法decodedImageWithImage: ;其二是:处理大图缩放和解码办法decodedAndScaledDownImageWithImage:。

1、decodedImageWithImage:函数
  • decodedImageWithImage实现了PNG、GIF、TIFF三类图片解码的问题,这是SDWebImage默认的解码操作;当它解码高分辨率图片,会导致内存暴增,甚至Crash。它造成的问题就是网上很多博客说的,“SDWebImage加载大图(高分辨率图),内存暴涨,导致加载失败的问题”。

  • decodedImageWithImage函数很简单,主要步骤可以看成:先过滤掉不符合解码条件;再获得图片的信息;最后绘制出位图图片。

    1)shouldDecodeImage:过滤点不适合解码的image,分别是:image为nil、animated images 或 有透明度的图片
    2)获取图片的像素宽高(width、height)、颜色空间(colorspaceRef) 、行字节数(bytesPerRow,4 * width)等数据。
    3)使用创建CGBitmapContextCreate没有透明度的位图上下文,然后在该上下文中绘制出图像。
    

说明:解码操作在@autoreleasepool中,可以使得局部变量能尽早释放掉,避免内存峰值过高。

2、decodedAndScaledDownImageWithImage:函数处理流程
  • decodedAndScaledDownImageWithImage解决了PNG、GIF、TIFF三类高分辨率图片因解码导致内存暴增的问题,采用办法是:将大的原图缩放成指定大小的图片(个人感觉,思路应该来自苹果的LargeImageDownsizing)。

  • decodedAndScaledDownImageWithImage: 函数中主要步骤可以看成:先过滤掉不符合解码条件,位图大小不达标的(小于60MB);再将原图按照固定大小分割,然后依次绘制到目标画布上(这部分最关键)。

  • 在裁剪绘制过程中,主要步骤如下:

    1)根据sourceTotalPixels(原图像素大小)和kDestTotalPixels(60MB对应的像素大小)获取imageScale;
    2)根据imageScale和原图的像素宽高获取 目标图的大小destResolution.size, 并创建目标位图上下文;
    3)获得原图分割图的size(sourceTile.size),宽度和原图宽一样,高度是 (int)(kTileTotalPixels / sourceTile.size.width ),其中 kTileTotalPixels为20MB
    4)获取目标分割图的size(destTile.size),宽度和目标图宽一样,高度是sourceTile.size.height * imageScale
    5)根据原图高(sourceResolution.height)除以原图分割图的高(sourceTile.size.height)获得获取分割块的个数iterations,如果还有余数,分割块个数(iterations)载累加1。
    6)从原图中裁剪出指定大小的分割图,然后绘制到目标上下文的指定位置。
    

    注意:Core Graphics的坐标系则是y轴向上的,UIKit框架坐标系是y轴向下的;使用CGContextDrawImage将sourceTileImageRef绘制到destContext中,为了避免图片上下文颠倒,注意destTile.origin.y和sourceTile.origin.y的计算方式

    for( int y = 0; y < iterations; ++y ) {
        @autoreleasepool {
            //注意sourceTile.origin.y和destTile.origin.y的计算
            sourceTile.origin.y = y * sourceTileHeightMinusOverlap + sourceSeemOverlap;
            destTile.origin.y = destResolution.height - (( y + 1 ) * sourceTileHeightMinusOverlap * imageScale + kDestSeemOverlap);
            sourceTileImageRef = CGImageCreateWithImageInRect( sourceImageRef, sourceTile );
            if( y == iterations - 1 && remainder ) {
                float dify = destTile.size.height;
                destTile.size.height = CGImageGetHeight( sourceTileImageRef ) * imageScale;
                dify -= destTile.size.height;
                destTile.origin.y += dify;
            }
            CGContextDrawImage( destContext, destTile, sourceTileImageRef );
            CGImageRelease( sourceTileImageRef );
        }
    }
    
3、CGBitmapContextCreate创建位图上下文

函数原型CGBitmapContextCreate(void *data,size_t width,size_t height,size_t bitsPerComponent,size_t bytesPerRow,CGColorSpaceRef colorspace,CGBitmapInfo bitmapInfo)

  • 参数data:渲染目标的内存地址,内存块大小至少是(bytesPerRow * height) 个字节;一般传递NULL,让系统去分配和释放内存空间,避免内存泄漏问题。
  • 参数width和height分别是:位图的宽高像素;
  • 参数bitsPerComponent是:位图像素中每个组件的位数(number of bits)。对于32位像素格式和RGB 颜色空间,这个值是8;
  • 参数bytesPerRow:在内存中,位图每一行所占的字节数。
  • 参数 colorspace:位图的颜色空间。
  • 参数 bitmapInfo:指出该位图是否包含 alpha 通道和它是如何产生的(RGB/RGBA/RGBX…),还有每个通道应该用整数标识还是浮点数。值为kCGBitmapByteOrderDefault | kCGImageAlphaNoneSkipLast,表示着新的位图图像不使用后面8位的 alpha 通道的。

说明:一个新的位图上下文的像素格式由三个参数决定:每个组件的位数(bitsPerComponent),颜色空间(colorspace),alpha选项(bitmapInfo),alpha值决定了绘制像素的透明性。

三、解码高分辨率图的担忧

1、“被嫌弃”的解码
  • 网络上,很多博客都说到了使用SDWebImage加载(高分辨率)图片,发生内存暴涨,甚至导致Crash的问题;提出的解决的办法是,关闭解码操作。

    // 关闭解码操作
    [[SDImageCache sharedImageCache] setShouldDecompressImages:NO];
    [[SDWebImageDownloader sharedDownloader] setShouldDecompressImages:NO];
    
  • 关闭解码操作,将decodedImageWithImage解码高分辨率图的内存问题避开了,但是这意味着:如果大图多次加载显示,意味着在主线程要多次重复解码(这好像不是什么好事);此外显示大图时,App依然会占用大量的内存,还可能造成卡顿;放弃SDWebImage解码并不能保证能应对所有高分辨图。所以说,关闭解码操作并不是一个很好的选择

2、加载高分辨率图问题
  • 项目中,加载高分辨率图不可避免,如后台下发给我们一张大图(高分辨率图);主线程解码(默认)可能导致卡顿;子线程解码可能因内存暴涨而Crash。解决办法可以参考 LargeImageDownsizing。该Demo展示加载显示一个高分辨率(7033 × 10110 像素,位图大小271MB)图片的做法;其主要优化思路是:将大的原图缩放成指定大小的图片。decodedAndScaledDownImageWithImage就是采用这种思路。

  • decodedAndScaledDownImageWithImage:函数中,为了避免内存暴增,将原图裁剪成多个小图,然后依次绘制到目标位图context中。项目中,我更愿意decodedAndScaledDownImageWithImage方法去解码高清晰图片,而不愿意禁止解码操作。

    //SDWebImageOptions选择SDWebImageScaleDownLargeImages,处理网络高分辨率图
    [self.imageView sd_setImageWithURL:url placeholderImage:nil options:SDWebImageScaleDownLargeImages];
    
  • Apple提供了一个异步绘制内容的图层CATiledLayer,不需要加载全部图片,可以将大图分解成小图片,然后再载入显示,具体参考下CATiledLayer

3、需要考虑的问题

凭心而论,后台不经处理,任意下发高分辨率大图这类事发生可能性很少;绝大部分场景下,iOS设备上不需要分辨率过高的图(iPhone X的屏幕尺寸也不过是1125px × 2436px),那我们应该考虑什么呢。

  • 考虑1:因为SDWebImage支持并发的解码操作,同时解码多张分辨率中等图片,占用的内存空间比较大,可能会给内存带来压力(小图不必担心)。可行的处理办法是,限制并发解码的个数

  • 考虑2:如果后台下发的图片是带透明度的图片,SDWebImage并不会去做解码,这样的图片只能让iOS系统去解码。我能想到的办法:尽可能让后台下发不透明的图片

四、解码中的小问题

SDWebImageDecoder的解码工作中,有两个小问题值得留意一下。

1、颜色空间的问题
  • 在创建位图,选用颜色空间时,如果图片的颜色空间模式是kCGColorSpaceModelUnknown(未知)、kCGColorSpaceModelMonochrome、kCGColorSpaceModelCMYK和kCGColorSpaceModelIndexed,默认使用设备RGB颜色空间(通过CGColorSpaceCreateDeviceRGB获得),详见代码:

    + (CGColorSpaceRef)colorSpaceForImageRef:(CGImageRef)imageRef {
      // current
      CGColorSpaceModel imageColorSpaceModel = CGColorSpaceGetModel(CGImageGetColorSpace(imageRef));
      CGColorSpaceRef colorspaceRef = CGImageGetColorSpace(imageRef);  
      BOOL unsupportedColorSpace = (imageColorSpaceModel == kCGColorSpaceModelUnknown ||
                                    imageColorSpaceModel == kCGColorSpaceModelMonochrome ||
                                    imageColorSpaceModel == kCGColorSpaceModelCMYK ||
                                    imageColorSpaceModel == kCGColorSpaceModelIndexed);
      if (unsupportedColorSpace) {
          colorspaceRef = CGColorSpaceCreateDeviceRGB();
          CFAutorelease(colorspaceRef);
      }
      return colorspaceRef;
    }
    

这么做的原因,我认为只要有两点

  • RGB颜色模式几乎包括了人类视力所能感知的所有颜色,而SDWebImageDecoder中主要支持PNG、JPG、TIFF常见图片格式的解码,它们大部分采用RGB色彩模式;目前手机屏、电脑显示屏大都采用了RGB颜色模式。

  • 对应Monochrome、CMYK和Indexed这样的模式,使用设备RGB颜色空间(device color space),其结果是可以接受的。一张灰度图片,颜色空间模式是kCGColorSpaceModelMonochrome,使用设备灰度颜色空间设备RGB颜色空间都可以,只是使用设备灰度颜色空间内存上效果会好一些。

2、解码不透明图片的问题
  • SDWebImage中不解码透明的图片,猜测原因是:在UI渲染视图时,如果某个layer透明时,需要叠加计算下方多层的像素;如果某个layer不透明,可以忽略掉下方的图层,减少了GPU像素混合计算。使用CGBitmapContextCreate 时 bitmapInfo 参数设置为忽略掉 alpha 通道,绘制出不透明的位图图片,在渲染视图,能减少GPU的计算,提高性能。

End

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,013评论 6 481
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,205评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 152,370评论 0 342
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,168评论 1 278
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,153评论 5 371
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,954评论 1 283
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,271评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,916评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,382评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,877评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,989评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,624评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,209评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,199评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,418评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,401评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,700评论 2 345

推荐阅读更多精彩内容