1. 先把结论摆出来：一张图的内存账到底怎么算
聊 iOS 图片占内存这件事，我踩过最典型的一个坑是：设计同学丢过来一张 4000×3000 的主视觉图，文件在 Finder 里显示 1.8MB，产品看完说"这图不大啊"，结果真机一滚动列表，内存曲线直接拉起来，Xcode 里看到峰值涨了四十多兆。文件大小和内存占用完全是两套账，这是所有图片内存问题的起点。iOS 图片占内存大小，本质上只取决于一件事——这张图被解码成位图之后，在内存里铺开了多少个像素、每个像素占几个字节。压缩格式、磁盘体积、网络传输大小，统统只是"运输途中"的尺寸，跟落地后占多大房子没有直接关系。
我见过不少团队在图片优化上走偏：拼命压 JPEG 质量、上 WebP、转 HEIC，包体确实降下来了，可内存该爆还是爆。因为压缩算法优化的是"存储密度"，解码之后照样要还原成一整片像素矩阵，你没法让一个 4000×3000 的画面在屏幕上显示时只占 400×300 的内存——除非你在解码阶段就把它降采样掉。所以这篇文章想做的事情很明确：把"图片内存 = 像素宽 × 像素高 × 每像素字节数"这条主公式拆开，讲清每个乘数受什么影响，再顺着解码、缓存、渲染三条链路，说说这些字节到底被谁攥在手里、什么时候能松手。
适合谁看？如果你写过UIImage(named:)，被didReceiveMemoryWarning折磨过，或者用 Instruments 看过内存曲线却不知道那几十兆是哪来的，这篇应该能帮你把账算明白。我会给可直接抄的降采样代码、参数怎么定的计算过程、资源审计的脚本思路，还有一堆文档里不会写的坑。所有结论都基于我在实际项目里的观察，不同系统版本、不同机型可能有细微差别，涉及到具体数值的地方建议你在自己的环境里复核一遍。
1.1 决定内存的三个乘数：像素宽、像素高、每像素字节数
把图片想成一块地砖阵列，宽多少块、高多少块、每块砖多重，乘起来就是总重量。像素宽高是"块数"，每像素字节数是"每块砖的重量"。三者缺一不可，而且通常只有前两个是大家会注意到的。
像素宽高指的是解码后位图的实际像素数，不是 UIImage 的size属性。size单位是 point，得乘以scale才是像素。一张标成@3x的图，size写 100×100，实际位图是 300×300 像素，面积是 9 倍关系而不是 3 倍，这点经常有人算错。我在评审代码时见过有人按image.size.width * image.size.height估内存，估出来的数只有真实值的九分之一左右，做完"优化"发现毫无效果。
每像素字节数取决于像素格式。最常见的 RGBA8888 是每通道 8 位、四个通道，正好 4 字节。灰度图 1 字节，RGB565 这类 16 位格式 2 字节，带广色域或高位深的能到 8 字节甚至更多。绝大多数从相册、网络拿到的普通图片，解码后都是 4 字节/像素，所以你用宽 × 高 × 4快速估算，误差通常不大，够用来判断"这图会不会出事"。
举个实际数字。一张 4000×3000 的照片，按 4 字节算：
- 4000 × 3000 = 12,000,000 像素
- 12,000,000 × 4 = 48,000,000 字节
- 换算成 MiB 约 45.8MB
这还只是一张。如果列表里同时有十张这样的大图在内存里活着，就是四百多兆，中低端机型基本必挂。而它对应的 JPEG 文件可能只有 2MB 左右，压缩比 20 多倍，这就是"文件小、内存大"的全部真相。
反过来算一个合理尺寸的例子：iPhone 上一张撑满全屏的图，逻辑宽度按 393pt 算，@3x就是 1179 像素宽，高度按 852pt 算是 2556 像素：
- 1179 × 2556 = 3,013,524 像素
- × 4 = 12,054,096 字节，约 11.5MB
一张全屏图十几兆是正常量级，这也解释了为什么背景大图特别容易把内存顶上去——它天然就是全屏尺寸，还得常驻。
1.2 为什么磁盘上的 200KB 进内存能变成 50MB
这个落差让很多人第一次看到时以为是工具读数出错。要理解它，得区分两个概念：编码态和解码态。
编码态的图片是压缩过的。JPEG 用离散余弦变换加量化，把高频细节粗暴地丢掉一部分，再用熵编码压一遍；PNG 用 DEFLATE 做无损压缩，靠的是相邻像素之间的冗余。两者的共同点是：数据被"折叠"起来了，读的时候必须解开。
解码态就是解开之后的样子。图形处理器和显示管线没法直接去算 DCT 系数，它要的是"第 1234 行第 567 列这个像素，红绿蓝各是多少"。所以解码的结果必然是一整片连续的像素缓冲区，一个像素挨着一个像素排好，索引靠偏移量算，这是硬件的工作方式决定的，没有捷径。
记住一句话：压缩率是存储属性，像素数是显示属性，内存只认后者。
所以"200KB 变 50MB"不是内存泄漏，也不是系统坑你，是正常开销。真正该问的问题是：这张图需要以 4000×3000 的姿态待在内存里吗？如果它只在一个 120pt 宽的卡片里显示，答案显然是不需要，多出来的像素纯粹是浪费。
1.3 屏幕尺寸、scale 与资源命名的连带关系
@2x、@3x这套命名机制，本质上是让同一份逻辑尺寸在不同屏幕上匹配到不同物理像素，保证清晰度。但它带来一个容易被忽略的连带效应：图片的像素尺寸是被设备决定的，不是你写的逻辑尺寸决定的。
你声明一个 200×200pt 的图，在@3x设备上系统优先取 600×600 像素的那份资源。如果资源目录里只有一张 1200×1200 的图被放进了@3x槽位（这种情况在设计师直接导出时非常常见），那系统就老老实实加载 1200×1200，解码成 5.76MB，然后在 600×600 的位置上把它缩着显示。视觉上看不出问题，内存白白多花 4 倍。
我在一个项目里做过统计，资源目录里超过三成的图实际像素尺寸比它被使用的槽位大一圈。原因通常是：设计师按"最大可能需要"导出，或者从网页端素材直接拖过来。这类浪费不体现在崩溃日志里，只会让你的内存基线悄悄抬高几十兆，在低端机上表现成"莫名其妙就被杀了"。
顺带说一句 scale 和渲染的关系。UIImageView的contentMode只影响绘制时的采样，不改变位图本身的内存占用。.scaleAspectFill把一张 4000×3000 塞进 100×100 的框里，位图还是 48MB。想省内存，唯一有效的动作是在拿到图的时候就把它降下来，而不是指望显示层帮你裁。这条我后面会给出完整的实现。
2. 每像素字节数：位深、通道与色彩空间怎么影响结果
公式里最容易被低估的就是这个乘数。很多人默认"图片就是 4 字节一像素"，确实大部分场景成立，但一旦碰上特殊格式，偏差可能是 2 倍甚至 8 倍。这一节把常见的几类情况列清楚，让你在估算时心里有数。
2.1 常见像素格式的字节账
先给一张对照表，都是我实际遇到过或者在文档里核对过的组合：
| 像素格式 | 每通道位深 | 通道数 | 每像素字节 | 典型来源 |
|---|---|---|---|---|
| 灰度 8 位 | 8 | 1 | 1 | 二维码、蒙版图、扫描件 |
| 灰度 + Alpha | 8 | 2 | 2 | 特殊遮罩素材 |
| RGB565 | 5/6/5 | 1（打包） | 2 | 低精度渲染缓冲、旧硬件纹理 |
| RGB888 | 8 | 3 | 3 | 少见，通常会对齐成 4 |
| RGBA8888 | 8 | 4 | 4 | 绝大多数 PNG、解码后的照片 |
| BGRA8888 | 8 | 4 | 4 | 系统内部常见排列，字节数一致 |
| 16 位/通道 RGBA | 16 | 4 | 8 | 高位深素材、部分 HDR 中间态 |
| 单通道浮点 | 32 | 1 | 4 | Core Image 中间缓冲 |
日常最需要关心的其实就三档：1 字节、4 字节、8 字节。普通照片和 UI 素材走 4 字节这档，估算是宽 × 高 × 4；灰度素材能省到四分之一；涉及高位深色彩的时候要按 8 字节算，不然会严重低估。
这里有个细节值得说：RGB888 这种 3 字节格式在实践中很少作为最终位图存在，因为行首地址对齐的要求，通常会补一个字节凑成 4。所以你看到某些文档写"24 位色"，别真的按 3 去乘，实际占的往往是 4。
2.2 Alpha 通道与不透明声明
不带透明信息的图，理论上 3 通道就够，但系统解码时为了方便统一处理，往往还是给 4 通道。想让系统真的按不透明来处理，得靠UIGraphicsImageRendererFormat里的opaque属性，或者用 Core Graphics 建位图上下文时传CGImageAlphaInfo.noneSkipLast这类参数。
这个开关的价值在于两处。一是位图本身能省 25% 的字节；二是渲染阶段少一次混合运算，滚动时的帧率会更稳。我在一个信息流页面里把卡片背景图统一改成不透明渲染，滚动掉帧率有明显改善，尤其是老机型。
不过要提醒一句，opaque = true的前提是图里真的没有半透明像素。如果 PNG 里藏了软边缘或者阴影，强行声明不透明会得到一个黑底或者怪异边缘，这种视觉 bug 排查起来很费时间。我的做法是：素材入库时用脚本扫一遍 alpha 通道，全 255 的标记成"可优化"，有非 255 的保留原样，别靠人工判断。
2.3 广色域与 HDR 带来的翻倍
最近几年设备屏幕支持 P3 广色域，素材里带 P3 色彩描述的图越来越多。这类图的解码结果可能不再是 8 位/通道，而是 16 位/通道，每像素直接变成 8 字节。
我遇到过一次典型情况：同一张图，从设计工具导出时勾了广色域，塞进 App 之后内存占用翻倍，但因为视觉上看不出差别（大部分内容本来就在 sRGB 范围内），一直没人发现，直到内存告警才回头查。排查方法很简单，用cgImage.bitsPerComponent和bitsPerPixel打一行日志就知道：
if let cg = image.cgImage { print("w=\(cg.width) h=\(cg.height) bpc=\(cg.bitsPerComponent) bpp=\(cg.bitsPerPixel) cs=\(String(describing: cg.colorSpace?.name))") }如果bpp是 64 而不是 32，那就是高位深，值得考虑转换。转成 sRGB 8 位有个小代价——超出 sRGB 范围的鲜艳颜色会被裁掉一点，但绝大多数 UI 素材根本感知不到。
HDR 内容同理，而且更极端。真 HDR 图在解码和合成环节的缓冲区可能是普通图的好几倍。如果你不是在做影像类应用，我建议直接在资源处理管线里把 HDR 标志去掉，转成标准动态范围，能省一大截。
2.4 色彩空间转换带来的临时副本
还有一个隐性开销：色彩空间不匹配时的转换。图片标的是 P3，屏幕是 sRGB，系统在绘制前可能需要生成一份转换后的位图。这份副本的生命周期不一定长，但在合成的瞬间是实打实存在的，会体现在内存峰值上。
这个现象在做图片浏览页时特别明显：连续滑动切图，每次切换的瞬间内存曲线都会拱一下。如果你的应用对峰值敏感（比如还要同时做视频解码），建议在图片进入缓存前就统一色彩空间，别让转换发生在渲染时刻。统一的位置可以放在下载完成后的处理环节，用CGContext重绘一遍，代价是一次性的，收益是峰值平滑。
3. 图片格式与解码链路：谁决定了解码后长什么样
格式选择这件事，大家的关注点通常在"哪个压得更小"。但对内存来说，格式影响的是解码路径和解码时机，这两点比压缩率重要得多。
3.1 JPEG、PNG、HEIC、WebP 差异在哪一层
我按内存相关的角度重新排一下：
- JPEG：有损、无 Alpha、解码器成熟。解码后必然是不透明位图，4 字节/像素（或者 3 字节，取决于解码器输出配置）。渐进式 JPEG 在解码时内存峰值会比基线式高，因为它需要保留多次扫描的中间状态。
- PNG：无损、支持 Alpha。解码后是 4 字节/像素。压缩率一般，但解码快，UI 素材首选。要注意的是带 Alpha 的 PNG 无法走不透明优化路径。
- HEIC：压缩率高，同画质下体积明显小。但解码依赖系统能力，在低端设备上解码耗时略高。内存层面它和 JPEG 一样，解出来还是那么大，压缩率优势只体现在磁盘和网络。
- WebP：有损/无损都支持，体积小。解码需要额外处理，第三方的解码实现可能在内存上不如系统原生路径精细，尤其是有动画的多帧 WebP，一次性把所有帧解出来会非常吃内存。
结论很清楚：格式决定传输成本，不决定内存成本。选格式时优先考虑网络和包体，内存要靠尺寸和解码策略来控。
3.2 懒解码：UIImage 不是拿到就解压
这是理解 iOS 图片内存的关键一环，也是很多人搞错的地方。UIImage本身很轻，它更接近一个"图片描述对象"，里面存的是数据源引用、尺寸、scale、方向这些元信息。真正的解码发生在需要显示的时候——通常是在图层提交给渲染服务、需要把位图上传成纹理的那一刻。
这个设计叫懒解码，好处是省内存：你创建了一百个UIImage但只显示三个，就只有三个会被解码。坏处是解码发生在主线程，而且是在滚动的关键时刻，于是你会看到列表滑动时卡顿，尤其是大图。
我做过对比测试：同样一批 2000×1500 的图放进UICollectionView，不做预处理的情况下首次快速滚动明显掉帧，用 Instruments 的 Time Profiler 看，热点就在解码调用上。改成在后台线程预先解码并降采样之后，滚动就顺了。
这也解释了一个现象：用内存工具看，UIImage对象本身的Size很小，但总内存涨了很多。因为占内存的是解码出来的位图缓冲，它挂在图形相关的内存区域里，不在对象堆上。
3.3 ImageIO 增量解码与降采样的原理
ImageIO框架提供的能力，本质上是在解码过程中"半路截胡"。它不需要先把整张图解出来，而是读文件头拿到尺寸信息，然后按你要求的最大边长来采样输出。对于一张 4000×3000 的 JPEG，你要求最大边 600，它输出的就是 600×450 的位图，中间不会产生完整的 4000×3000 缓冲。
这个机制对内存的意义是决定性的。对比两条路径：
- 路径 A：
UIImage(contentsOfFile:)→ 得到完整位图 48MB → 缩放到目标尺寸 → 释放大图。峰值 48MB，还可能因为释放不及时堆积。 - 路径 B：
CGImageSourceCreateThumbnailAtIndex指定最大边 → 直接得到小图 1MB 左右。峰值 1MB 多一点。
差距是几十倍。所以只要你的图片来自文件或者网络数据，且目标显示尺寸远小于原图，就应该走路径 B。这不是"优化技巧"，是基本操作。
3.4 渐进式与多帧图片的解码峰值
渐进式 JPEG 在多网络环境下体验很好，先糊后清。但它的解码状态机比基线式复杂，解码过程中需要维护更多的中间数据。如果你一屏放了很多张渐进式图，解码峰值会叠加，这个在低内存设备上可能触发告警。
多帧图片（GIF、动态 WebP、APNG）问题更大。有些实现会一次性把所有帧解码成UIImage数组，十帧 800×600 的动图就是十份位图，接近 20MB，而且只要动画在播就得一直留着。我的建议是：能不用多帧就不用，必须用的话控制尺寸和帧数，并且考虑播放结束或离开屏幕后主动释放缓存。
4. 渲染与缓存：内存被谁真正占住
算清楚一张图的字节数只是第一步。真正让内存曲线失控的，往往是这些字节被复制了几份、被谁缓存着、什么时候才释放。
4.1 纹理上传与 GPU 侧的额外拷贝
位图解码出来之后，要显示就得变成 GPU 能用的纹理。这个过程中，系统通常会在图形内存里再放一份。也就是说，一张图的峰值可能是 CPU 侧位图加 GPU 侧纹理两份并存。
更麻烦的是纹理的对齐要求。图形硬件对每行字节数有对齐要求，小尺寸的图可能因为对齐而浪费一部分空间。比如一张 10×10 的 RGBA 图，理论上 400 字节，但按行对齐之后可能占到 1KB 甚至更多。这个浪费对小图数量巨大时（比如表情包列表）会积少成多。
另外纹理尺寸有上限，超大的图会被拆分成多块。如果你的应用里有可能出现几千像素见方的图，最好在进入渲染前就降下来，别让系统去处理拆分，那不仅吃内存还影响帧率。
4.2imageNamed的缓存陷阱
UIImage(named:)会走系统缓存，这个缓存不参与你的内存管理，而且在内存紧张时释放时机不完全可控。好处是重复使用同一张图时快；坏处是你以为已经不在屏幕上的图，其实还占着内存。
我遇到过一个很典型的场景：一个页面里循环显示了几十张不同的装饰图，用的是imageNamed，退出页面后内存没降。排查发现是系统缓存还留着。改成UIImage(contentsOfFile:)配合自己的缓存策略后，退出页面内存立即回落。
经验规则：小图标、频繁复用、生命周期贯穿整个应用的资源用
imageNamed；一次性的、大尺寸的、页面级的图用contentsOfFile或者自己管缓存。
这条规则不是绝对的，但能覆盖大部分情况。判断标准就一个：这张图会不会在整个应用生命周期里被反复用。会就用系统缓存，不会就别占那个坑。
4.3NSCache的cost怎么算才靠谱
自己写图片缓存时，NSCache的totalCostLimit是按你传入的cost累加的。这个值必须传"接近真实内存占用"的数，否则淘汰逻辑会失效。
我的做法是直接用像素字节数：
let cost = cgImage.bytesPerRow * cgImage.height cache.setObject(image, forKey: key, cost: cost)用bytesPerRow * height而不是width * height * 4，是因为bytesPerRow已经包含了行对齐的填充，更接近真实占用。这个细节很多人忽略，但在小图多的情况下误差不小。
totalCostLimit设多少？我的经验是按设备内存分档，低端机 30MB 到 50MB，中高端 100MB 左右。别设太大，缓存的目的是加速而不是囤货。同时监听内存告警，收到就removeAllObjects()：
NotificationCenter.default.addObserver( forName: UIApplication.didReceiveMemoryWarningNotification, object: nil, queue: .main ) { [weak self] _ in self?.cache.removeAllObjects() }4.4 离屏渲染带来的瞬时峰值
圆角加masksToBounds、阴影、组透明度、遮罩，这些都会触发离屏渲染。离屏渲染需要额外的缓冲区，尺寸跟图层大小相关。一个全屏的圆角视图，离屏缓冲就是十几兆，如果同时有多个，峰值会很夸张。
我的处理方式是：能预合成的就预合成。比如头像的圆形裁剪，在下载完成后直接用UIGraphicsImageRenderer画成圆形位图，显示的时候就不需要运行时裁剪了。代价是处理时多一次绘制，收益是滚动时不再有离屏缓冲。这个交换在列表场景里非常划算。
阴影同理，如果阴影是固定的，用一张带阴影的九宫格图代替layer.shadow*系列属性，能省掉大量离屏开销。
5. 实操：把一张大图的内存从 48MB 压到 200KB
前面讲原理，这一节给完整可复现的流程。场景设定：从网络下载了一张 4000×3000 的 JPEG，需要显示在 120×120pt 的列表卡片里，设备是@3x。
5.1 第一步：算出目标像素尺寸
流程是先定目标，再动手，顺序不能反。目标逻辑尺寸 120×120pt，@3x折算：
- 目标像素宽 = 120 × 3 = 360
- 目标像素高 = 120 × 3 = 360
- 目标位图字节 = 360 × 360 × 4 = 518,400 字节，约 506KB
如果卡片是不透明的，走不透明渲染能到 3 字节/像素，约 380KB。再考虑圆角预合成，最终驻留的就是这个量级。
对比原始 48MB，压缩比接近 95 倍。这就是"降采样"和"压缩图片质量"的根本区别——后者只能把 2MB 压到 1.5MB，前者直接把 48MB 砍到 0.5MB。
这里有个细节要提醒：不要用一个固定的"最大边"参数糊弄所有场景。列表缩略图、详情页大图、全屏预览，目标像素完全不同。我建议在业务层给每个展示位定义好目标逻辑尺寸，向下传的时候带上，别让图片处理层去猜。
5.2 第二步：用 ImageIO 做降采样（完整代码）
import ImageIO import UIKit enum ImageDownsampler { /// 按目标逻辑尺寸降采样，内部自动乘以屏幕 scale static func downsample(imageAt url: URL, to pointSize: CGSize, scale: CGFloat = UIScreen.main.scale) -> UIImage? { // 关键：不要缓存完整解码结果，只留源数据 let sourceOptions = [kCGImageSourceShouldCache: false] as CFDictionary guard let source = CGImageSourceCreateWithURL(url as CFURL, sourceOptions) else { return nil } let maxPixelSize = max(pointSize.width, pointSize.height) * scale let options: [CFString: Any] = [ kCGImageSourceCreateThumbnailFromImageAlways: true, kCGImageSourceCreateThumbnailWithTransform: true, kCGImageSourceShouldCacheImmediately: true, kCGImageSourceThumbnailMaxPixelSize: maxPixelSize ] guard let cgImage = CGImageSourceCreateThumbnailAtIndex( source, 0, options as CFDictionary ) else { return nil } return UIImage(cgImage: cgImage, scale: scale, orientation: .up) } /// 内存数据版本，适合下载完直接处理，避免落盘 static func downsample(data: Data, to pointSize: CGSize, scale: CGFloat = UIScreen.main.scale) -> UIImage? { let sourceOptions = [kCGImageSourceShouldCache: false] as CFDictionary guard let source = CGImageSourceCreateWithData(data as CFData, sourceOptions) else { return nil } let maxPixelSize = max(pointSize.width, pointSize.height) * scale let options: [CFString: Any] = [ kCGImageSourceCreateThumbnailFromImageAlways: true, kCGImageSourceCreateThumbnailWithTransform: true, kCGImageSourceShouldCacheImmediately: true, kCGImageSourceThumbnailMaxPixelSize: maxPixelSize ] guard let cgImage = CGImageSourceCreateThumbnailAtIndex( source, 0, options as CFDictionary ) else { return nil } return UIImage(cgImage: cgImage, scale: scale, orientation: .up) } }几个参数的作用我逐个说明，这些是踩坑之后才弄明白的：
kCGImageSourceShouldCache: false放在源创建选项里，意思是别急着把源数据解成完整位图缓存住。不加这个，某些情况下 ImageIO 会先把整张图解出来，降采样的省内存效果就打了折扣。
kCGImageSourceCreateThumbnailFromImageAlways: true强制从原图生成缩略图，而不是找内嵌的 EXIF 缩略图。EXIF 里那个缩略图分辨率通常很低（160×120 这种），直接拿来显示会糊。
kCGImageSourceCreateThumbnailWithTransform: true让输出遵循 EXIF 方向信息。不加这个，竖拍的照片会躺倒，而且你后面还得自己旋转，白折腾一遍。
kCGImageSourceShouldCacheImmediately: true在缩略图创建时就完成解码，返回的CGImage是已解码状态。这样后续显示时不会在主线程再解一次，避免滚动卡顿。这个参数是我认为最值钱的一个，很多人漏掉。
5.3 第三步：放到后台线程并做好任务管理
降采样本身是 CPU 密集的，必须挪出主线程。但光挪出去不够，还得处理"快速滚动时同一个位置被请求多次"的问题。
final class ImageTaskManager { private let queue = DispatchQueue(label: "image.downsample", qos: .userInitiated, attributes: .concurrent) private var tasks: [String: DispatchWorkItem] = [:] private let lock = NSLock() func load(url: URL, targetSize: CGSize, key: String, completion: @escaping (UIImage?) -> Void) { lock.lock() tasks[key]?.cancel() let item = DispatchWorkItem { [weak self] in guard let self else { return } if self.isCancelled(key: key) { return } let image = ImageDownsampler.downsample(imageAt: url, to: targetSize) DispatchQueue.main.async { if !self.isCancelled(key: key) { completion(image) } } } tasks[key] = item lock.unlock() queue.async(execute: item) } private func isCancelled(key: String) -> Bool { lock.lock(); defer { lock.unlock() } return tasks[key]?.isCancelled ?? true } }在 cell 的复用回调里先取消旧任务再发新请求，这是避免"图片错位"和"无谓解码"的关键。我见过不少项目只做了取消网络请求，没取消解码任务，结果快速滑动时后台堆了一堆已经不需要的解码工作，既浪费 CPU 也抬高内存峰值。
5.4 第四步：让服务端也参与进来
客户端降采样是兜底，更好的做法是从源头就只要合适尺寸。图片服务通常支持按宽度或高度参数返回裁剪后的图，比如请求时带上目标像素宽度。
我的建议是把"展示位 → 目标像素尺寸"这个映射维护在配置里，请求时一并带上。这样传输体积也降下来了，一举两得。要注意的是别把参数写死在客户端代码里，不同设备、不同布局（比如 iPad 分栏）目标尺寸不一样，得有统一的换算逻辑。
有个坑提醒一下：CDN 返回的图可能不是你请求的尺寸，尤其是缓存命中旧版本或者参数没被识别时。所以客户端拿到数据后仍然要检查实际像素尺寸，超出预期就本地降采样，别盲目信任。
5.5 第五步：资源审计与 CI 卡口
代码层面管住了运行时，还得管住入包资源。我的做法是写个小脚本，在 CI 里跑一遍资源目录，把超标的图列出来。
import plistlib from pathlib import Path from PIL import Image MAX_PIXELS = 3_000_000 # 单图像素上限，按项目调整 def audit(assets_root: str): problems = [] for contents in Path(assets_root).rglob("Contents.json"): try: data = plistlib.loads(contents.read_bytes()) except Exception: import json data = json.loads(contents.read_text()) for item in data.get("images", []): filename = item.get("filename") if not filename: continue path = contents.parent / filename if not path.exists(): continue try: with Image.open(path) as im: w, h = im.size except Exception: continue if w * h > MAX_PIXELS: problems.append((str(path), w, h, w * h * 4 // 1024 // 1024)) return problems if __name__ == "__main__": for p in audit("Resources/Assets.xcassets"): print(f"{p[0]} {p[1]}x{p[2]} 约 {p[3]}MB")这个脚本不追求精确，就是要一个"红灯"。阈值定多少看项目，我的经验是 UI 素材单张不要超过 300 万像素（约 12MB 内存），照片类可以放宽到 1200 万像素但要确保走降采样路径。跑在合并请求的检查里，超标的图必须说明理由，否则打回。
6. 常见问题与排查实录
这一节把我实际遇到过的问题整理一下，都是那种"看代码觉得没问题、跑起来才发现"的类型。
6.1 现象与根因速查表
| 现象 | 可能的根因 | 处理方向 |
|---|---|---|
| 列表滚动内存持续上涨不回落 | 图片缓存无上限，或用了imageNamed且图量大 | 检查缓存cost与上限，大图改用文件加载 |
| 进入某页面内存瞬间涨几十兆 | 直接加载原图未降采样 | 用 ImageIO 按目标尺寸取图 |
| 退出页面内存不释放 | NSCache未清理、闭包强引用、系统缓存残留 | 检查持有链，页面消失时主动清缓存 |
| 首屏滑动卡顿伴随内存峰值 | 懒解码发生在主线程 | 后台预解码，开ShouldCacheImmediately |
| 同一张图文件变小了但内存没变 | 只做了压缩没做降采样 | 改尺寸而非改质量 |
| 偶发被系统终止，无崩溃日志 | 内存峰值触发系统回收 | 看峰值而非均值，控制同时解码数量 |
| 图片显示模糊 | 降采样目标尺寸算小了 | 复核pointSize × scale |
| 图片方向错误 | 未处理 EXIF 方向 | 开CreateThumbnailWithTransform |
6.2 用工具定位的三步走
第一步，看总量。用内存分析工具跑一遍目标页面，看进入前后和退出后的三条线。重点关注两件事：峰值多少、退出后能不能回到基线。回不去基本就是缓存或者引用问题。
第二步，看构成。把内存按类型拆开，找图形相关的区域。如果大头在那里，就是解码后的位图；如果大头在对象堆，那可能是数据缓冲、模型或者字符串。
第三步，看时机。对着操作录一段，标记"滚动开始""滚动结束""页面退出"这几个点，看内存在哪一步跳。很多时候问题不在图片本身，而在于"同时加载了多少张"。把并发数从 10 降到 3，峰值能低一大截。
我一般会先做第三步，因为它最快出结论。并发控制改一行代码，往往比改架构见效快。
6.3 几个反直觉的坑
坑一：缩略图不一定省内存。如果缩略图是提前批量生成的并且全部缓存着，总量可能比按需加载大图还多。缓存策略要和加载策略配套设计，别只做一半。
坑二：UIImageView的image设为nil不一定释放。如果这个图还在缓存里，或者被别的地方强引用，设nil只是断开了一个引用。真正的释放要看引用计数归零。
坑三：后台线程解码也会占主线程的资源。解码是 CPU 密集的，并发度过高会把 CPU 占满，导致主线程抢不到时间片，表现出来还是卡。控制并发数不只是为了内存，也是为了响应性。
坑四：小图数量多的时候，开销在别处。一张 40×40 的图按 4 字节算才 6.4KB，但如果有两千张，光位图就 12MB 以上，再加上每张图的对象开销和纹理对齐浪费，实际可能翻倍。表情列表、贴纸面板这类场景要特别注意。
坑五：模拟器上的内存表现不能当准。模拟器用的是电脑的内存，压力和真机完全不同，很多在模拟器上跑得好好的页面在真机上会告警。涉及内存的验证必须在真机上做，而且至少要覆盖一台低内存设备。
我个人在实际操作中的体会是：图片内存问题九成出在"尺寸没管住"，剩下一成出在"缓存没管住"。把降采样做成统一的入口，让所有图片都必须经过它，比在每个页面零散地打补丁有效得多。这个约束一开始会让写业务的人觉得别扭，但一旦形成习惯，后面基本不会再为图片内存开专项会了。
最后分享一个小技巧：给图片处理入口加一行日志，打出原始像素尺寸、目标像素尺寸、实际耗时，在 Debug 包里聚合一下，你就能看到哪些页面在加载明显超标的图。这个日志成本极低，但比事后翻工具高效得多，我一般在新项目第一天就把它加上。
