1. 内存受限的挑战：为什么移动端/嵌入式设备需要特殊处理图片？
说实话，我做了这么多年移动端开发，最怕的就是半夜被运维电话叫醒——"App 又 OOM 了"。你想想看，用户正刷着朋友圈呢，突然闪退，这体验得多糟糕。
内存受限，说白了就是你的设备"钱"不够花。移动端和嵌入式设备不像服务器，内存就那么几百 MB 到几 GB，还得跟系统、其他 App 抢着用。图片呢？一张 1920×1080 的普通照片，解码成 RGBA 位图就要吃掉 8MB 左右。要是用户相册里有个 4000 万像素的 RAW 文件……嗯，你懂的。
为什么图片是内存杀手？
我习惯把图片加载比作"搬砖"。原始文件是压缩过的砖块（JPEG/PNG），但你要用的时候，得把它展开成完整的砖墙（位图）。这个展开过程，就是内存暴涨的时刻。
| 图片格式 | 文件大小（压缩后） | 解码后内存占用 | 膨胀倍数 |
|---|---|---|---|
| JPEG 1920×1080 | ~500KB | ~8MB | 16x |
| PNG 1920×1080 | ~2MB | ~8MB | 4x |
| RAW 4000×3000 | ~20MB | ~48MB | 2.4x |
你看，一张 500KB 的 JPEG，解码后直接变成 8MB。要是列表里同时加载 20 张，160MB 就没了。我见过一个项目，产品经理说"就加载几张高清图嘛"，结果测试机直接黑屏重启。
OOM 的典型场景分析
我在项目中遇到过好几次 OOM，总结下来，无非就这几个坑：
- 列表滑动加载：用户快速滑动，图片加载器来不及回收，内存里堆了几十张位图
- 大图直接解码：原图 4000×3000，直接塞进 ImageView，也不管屏幕才 1080p
- 缓存策略不当：LRU 缓存设得太大，或者根本没设上限
- Bitmap 引用泄漏：Activity 销毁了，但图片还被某个异步任务拽着不放
嵌入式设备更敏感
嵌入式设备的内存更紧张。我做过一个智能相框的项目，总共 256MB 内存，系统占掉 150MB，留给应用的只有 100MB 左右。一张 1080p 的图片就吃掉 8MB，你想想看，能同时放几张？
而且嵌入式设备通常没有 Swap 分区，内存用完了就是真的用完了。不像 PC 还能往硬盘里倒腾一下。所以，图片加载方案在嵌入式设备上，不是优化问题，而是生存问题。
核心矛盾：用户体验 vs 内存限制
用户想要高清、流畅、秒开。但设备说"我只有这么多内存，你看着办"。这个矛盾，就是咱们这门课要解决的核心问题。
一句话总结： 图片加载的本质，是用有限的内存，在正确的时间，展示正确尺寸的图片。多一分浪费，少一分模糊。
💡 我的建议： 开始优化之前，先搞清楚你的目标设备内存上限。我习惯在项目初期就定一个"内存预算"——比如"图片缓存不超过 32MB，单图解码不超过 4MB"。有了预算，后面就好办了。
好了，这一章咱们把"为什么"讲清楚了。接下来，我会带你一步步拆解，怎么在内存受限的环境下，把图片加载这件事做好。记住，不是所有图片都需要原图，不是所有场景都需要高清。学会做减法，才是真本事。