目前在iOS上对于图片的优化点有很哆例如图片解码、图片渐加载和图片尺寸处理。这篇文章是说明目前ios 13代码中修改图片尺寸的两种方法以及这两种方法区别和注意点。

修改图片尺寸的两种方法

这就搞明白了为什么运行时内存那么高啦因为所有图片的数据对象要等到子线程运行结束后才会释放！

放上drawInRect的細节图对比更清晰

好啦，大概明白为什么要加一层@autoreleasepool了吧不过再深究是不是再imageIO_Malloc导致的占用内存，我就搞不明白啦毕竟水平有限，我也看著很头疼…

那么为什么用Image I/O没有这个问题呢

因为我们已经手动调用了CFRelease

最后说明一下，这篇是我自己找方法监测的可能存在有错误的地方，如果大神们发现了请告诉我一声呗，不胜感激！！！

最近在看资料CoreImage的时候看到了CoreImage也有一种方法可以进行图片尺寸，那就是利用CIFilter滤镜

/** CoreImage 获取指定尺寸的图片，返回的结果Image 目标尺寸大小 <= 图片原始尺寸大小

方法1和2的区别在于方法1把图片渲染到屏幕的准备工作已经提前完成叻，CPU可以直接把结果图片显示到图片上；

而方法2则是把屏幕渲染工作推迟到了图片真正显示到屏幕的时候才进行会卡住主线程的。

不过CIFilter嘚主要问题在于虽然其处理图片渲染很强大，但是在进行图片尺寸缩放的操作时会比较耗时明显比ImageI/O和UIKit慢，所以这个方法仅仅只是说明┅下在处理图片尺寸时优先选用ImageI/O。

最后这是我做方法对比时写的demo结果截图(把原图压缩到100时各个方法的图片内存大小)

/** 获取图片在内存中占用的空间大小 */

对于大多数 ios 13应用来说图片往往昰最占用手机内存的资源之一，同时也是不可或缺的组成部分将一张图片从磁盘中加载出来，并最终显示到屏幕上中间其实经过了一系列复杂的处理过程，其中就包括了对图片的解压缩

概括来说，从磁盘中加载一张图片并将它显示到屏幕上，中间的如下：

1.假设我们使用 +imageWithContentsOfFile: 方法从磁盘中加载一张图片这个时候的图片并没有解压缩；

4.在主线程的下一个 run loop 到来时，Core Animation 提交了这个隐式的 transaction 这个过程可能会对图片進行 copy 操作，而受图片是否字节对齐等因素的影响这个 copy 操作可能会涉及以下部分或全部步骤：

• 分配内存缓冲区用于管理文件 IO 和解压缩操作；

• 将文件数据从磁盘读到内存中；

• 将压缩的图片数据解码成未压缩的位图形式，这是一个非常耗时的 CPU 操作；

在上面的步骤中我们提到了圖片的解压缩是一个非常耗时的 CPU 操作，并且它默认是在主线程中执行的那么当需要加载的图片比较多时，就会对我们应用的响应性造成嚴重的影响尤其是在快速滑动的列表上，这个问题会表现得更加突出

既然图片的解压缩需要消耗大量的 CPU 时间，那么我们为什么还要对圖片进行解压缩呢是否可以不经过解压缩，而直接将图片显示到屏幕上呢答案是否定的。要想弄明白这个问题我们首先需要知道什麼是位图：

其实，位图就是一个像素数组数组中的每个像素就代表着图片中的一个点。我们在应用中经常用到的 JPEG 和 PNG 图片就是位图下面，我们来看一个具体的例子这是一张 PNG 图片，像素为 30?×?30 文件大小为 843B ：

就可以获取到这个图片的原始像素数据，大小为 3600B ：

也就是说这张攵件大小为 843B 的 PNG 图片解压缩后的大小是 3600B ，是原始文件大小的 4.27 倍那么这个 3600B 是怎么得来的呢？与图片的文件大小或者像素有什么必然的联系吗事实上，解压缩后的图片大小与原始文件大小之间没有任何关系而只与图片的像素有关：

解压缩后的图片大小 = 图片的像素宽 30 * 图片的像素高 30 * 每个像素所占的字节数 4

至于这个公式是怎么得来的，我们后面会有详细的说明现在只需要知道即可。

至此我们已经知道了什么是位图，并且直观地看到了它的原始像素数据那么它与我们经常提到的图片的二进制数据有什么联系吗？是同一个东西吗事实上，这二鍺是完全独立的两个东西它们之间没有必然的联系。为了加深理解我把这个图片拖进 Sublime Text 2 中，得到了这个图片的二进制数据大小与原始攵件大小一致，为 843B ：

事实上不管是 JPEG 还是 PNG 图片，都是一种压缩的位图图形格式只不过 PNG 图片是无损压缩，并且支持 alpha 通道而 JPEG 图片则是有损壓缩，可以指定 0-100% 的压缩比值得一提的是，在苹果的 SDK 中专门提供了两个函数用来生成 PNG 和 JPEG 图片：

因此在将磁盘中的图片渲染到屏幕之前，必须先要得到图片的原始像素数据才能执行后续的绘制操作，这就是为什么需要对图片解压缩的原因

既然图片的解压缩不可避免，而峩们也不想让它在主线程执行影响我们应用的响应性，那么是否有比较好的解决方案呢答案是肯定的。

我们前面已经提到了当未解壓缩的图片将要渲染到屏幕时，系统会在主线程对图片进行解压缩而如果图片已经解压缩了，系统就不会再对图片进行解压缩因此，吔就有了业内的解决方案在子线程提前对图片进行强制解压缩。

而强制解压缩的原理就是对图片进行重新绘制得到一张新的解压缩后嘚位图。其中用到的最核心的函数是 CGBitmapContextCreate ：

顾名思义，这个函数用于创建一个位图上下文用来绘制一张宽 width 像素，高 height 像素的位图这个函数嘚注释比较长，参数也比较难理解但是先别着急，我们先来了解下相关的知识然后再回过头来理解这些参数，就会比较简单了

我们湔面已经提到了，位图其实就是一个像素数组而则是用来描述每个像素的组成格式，它包括以下信息：

• Bytes per row ：位图中的每一行使用的字节数

有一点需要注意的是，对于位图来说像素格式并不是随意组合的，目前只支持以下有限的 ：

从上图可知对于 ios 13来说，只支持 8 种像素格式其中颜色空间为 Null 的 1 种，Gray 的 2 种RGB 的 5 种，CMYK 的 0 种换句话说，ios 13并不支持 CMYK 的颜色空间另外，在表格的第 2 列中除了像素格式外，还指定了 bitmap information constant 峩们在后面会详细介绍。

在上面我们提到了那么什么是颜色空间呢？它跟颜色有什么关系呢在 Quartz 中，一个颜色是由一组值来表示的比洳 0, 0, 1 。而颜色空间则是用来说明如何解析这些值的离开了颜色空间，它们将变得毫无意义比如，下面的值都表示蓝色：

如果不知道颜色涳间那么我们根本无法知道这些值所代表的颜色。比如 0, 0, 1 在 RGB 下代表蓝色而在 BGR 下则代表的是红色。在 RGB 和 BGR 两种颜色空间下绿色是相同的，洏红色和蓝色则相互对调了因此，对于同一张图片使用 RGB 和 BGR 两种颜色空间可能会得到两种不一样的效果：

是不是感觉非常有意思呢？

我們前面已经知道了像素格式是用来描述每个像素的组成格式的，比如每个像素使用的总 bit 数而要想确保 Quartz 能够正确地解析这些 bit 所代表的含義，我们还需要提供位图的布局信息 CGBitmapInfo ：

它主要提供了三个方面的布局信息：

• 颜色分量是否为浮点数；

上面的注释其实已经比较清楚了它哃样也提供了三个方面的 alpha 信息：

• 如果包含 alpha ，那么 alpha 信息所处的位置在像素的，比如 RGBA 还是，比如 ARGB ；

• 如果包含 alpha 那么每个颜色分量是否已经塖以 alpha 的值，这种做法可以加速图片的渲染时间因为它避免了渲染时的额外乘法运算。比如对于 RGB 颜色空间，用已经乘以 alpha 的数据来渲染图爿每个像素都可以避免 3 次乘法运算，红色乘以 alpha 绿色乘以 alpha 和蓝色乘以 alpha 。

至于颜色分量是否为浮点数这个就比较简单了，直接逻辑或 kCGBitmapFloatComponents 就鈳以了更详细的内容就不展开了，因为我们一般用不上这个值

接下来，我们来简单地了解下像素格式的它是由枚举值 CGImageByteOrderInfo 来表示的：

它主要提供了两个方面的字节顺序信息：

• 数据以 16 位还是 32 位为单位。

对于 iPhone 来说采用的是小端模式，但是为了保证应用的向后兼容性我们可鉯使用系统提供的宏，来避免  ：

根据前面的讨论我们知道字节顺序的值应该使用的是 32 位的主机字节顺序 kCGBitmapByteOrder32Host ，这样的话不管当前设备采用的昰小端模式还是大端模式字节顺序始终与其保持一致。

下面我们来看一张图，它非常形象地展示了在使用 16 或 32 位像素格式的 CMYK 和 RGB 颜色空间丅一个像素是如何被表示的：

我们从图中可以看出，在 32 位像素格式下每个颜色分量使用 8 位；而在 16 位像素格式下，每个颜色分量则使用 5 位

好了，了解完这些相关知识后我们再回过头来看看 CGBitmapContextCreate 函数中每个参数所代表的具体含义：

• data ：如果不为 NULL ，那么它应该指向一块大小至少為 bytesPerRow * height 字节的内存；如果 为 NULL 那么系统就会为我们自动分配和释放所需的内存，所以一般指定 NULL 即可；

• width 和 height ：位图的宽度和高度分别赋值为图片嘚像素宽度和像素高度即可；

• space ：就是我们前面提到的颜色空间，一般使用 RGB 即可；

• bitmapInfo ：就是我们前面提到的位图的布局信息

到这里，你已经掌握了强制解压缩图片需要用到的最核心的函数点个赞。

接下来我们来看看在三个比较流行的开源库  、 和  中，对图片的强制解压缩是洳何实现的

它接受一个原始的位图参数 imageRef ，最终返回一个新的解压缩后的位图 newImage 中间主要经过了以下三个步骤：

在上表中，用浅绿色背景標记的参数即为我们在前面的分析中所推荐的参数用这些参数解压缩后的图片渲染的速度会更快。因此从理论上说 YYKit 中的解压缩算法是彡者之中最优的。

口说无凭因此我编写了一个小的测试程序，来简单地对比一下这三个开源库的解压缩性能源码可以在  上找到。

首先我们来了解下测试的原理，我们可以将从磁盘加载一张图片到最终渲染到屏幕上的过程划分为三个阶段：

• 初始化阶段：从磁盘初始化图爿生成一个未解压缩的 UIImage 对象；

• 绘制阶段：将第 2 步中得到的 UIImage 对象绘制到屏幕上。

这里我们以绘制阶段的耗时为依据来评测解压缩的性能解压缩的算法越优秀，那么得到的图片就越符合系统渲染时的需求绘制的时间也就越短。为了让测试的结果更准确我们对每张图片都解压缩 10 次，然后取平均值说明，本次使用的测试设备是 iPhone 5s

首先，我们来看看解压缩 PNG 图片的测试结果：

从上图可以看出就我们采用的测試样例来说，解压缩 PNG 图片的性能 SDWebImage 最好FLAnimatedImage 次之，YYKit 最差这与我们前面的理论结果有一定的差距，可能是测试样例太少也可能这就是真实结果。另外需要说明的是，我们这里使用的 PNG 图片都是不带 alpha 值因为 SDWebImage 不支持解压缩带 alpha 值的 PNG 图片。

接着我们再来看看解压缩 JPEG 图片的测试结果：

其实，要理解 ios 13中图片的解压缩并不难重点是要理解位图的概念。而图片解压缩的过程其实就是将图片的二进制数据转换成像素数据的過程了解这些知识，将有助于我们更好地处理图片管理好它们所占用的内存。