如何优化iOS与Android应用图片，实现快速加载低内存占用？

多图滚动闪退核心原因是图片加载链路没做内存、任务管控导致的OOM，以下是可直接落地、对齐WhatsApp性能水平的具体方案：

一、核心问题排查方向 #

先对着这几个点核查现有代码，90%的闪退都出在这些环节：

• 端上拉取原图再做缩放：用户上传的原图普遍边长在2000px以上，ARGB_8888格式解码后单张图内存占用为宽*高*4字节，4000px边长的图单张就占64MB内存，一屏放10张就吃掉640MB，系统会直接杀进程
• 列表滑动时无差别加载所有图片：快速滑动时滑出可视区的项还在执行下载、解码任务，CPU、内存瞬间打满
• 内存缓存无淘汰机制：所有加载过的图全存在内存里，滑几屏就触到系统内存上限
• 没做Bitmap复用：每次加载图片都新申请内存块，频繁GC引发卡顿，内存碎片累积到阈值直接触发OOM

二、双端通用必做优化 #

这部分是性能基础，iOS、Android端做完就能解决80%的闪退问题：

• 服务端前置生成多规格缩略图：用户上传头像时直接生成3档尺寸：列表页用9696px、会话页用128128px、个人主页用256*256px，接口按场景返回对应尺寸的图地址，绝对禁止端上拉取原图再缩放
• 搭建标准三级缓存架构：按「内存缓存 -> 磁盘缓存 -> 网络拉取」的优先级取图，内存缓存用LRU淘汰策略，上限设为应用单进程可用内存的1/8；磁盘缓存上限设为200MB，自动删除最久未访问的文件
• 列表滑动做加载节流：列表处于快速滑动（Fling）状态时，暂停所有非可视区域项的图片加载任务，只加载当前完全可见项的图片；滑动停止后再预加载上下相邻一屏的资源，严格复用列表项视图，不要自己实现非原生的虚拟列表逻辑
• 统一图片编码格式：优先用WebP/HEIF格式存储图片，相同画质下体积比JPG小40%以上；无透明通道的头像Android端用ARGB_565格式解码，内存占用直接比ARGB_8888砍半
• 列表项回收时主动解绑资源：列表项滑出可视区被回收时，立刻取消对应ImageView的加载任务，解除ImageView对图片资源的强引用，避免内存泄漏

三、分端专项优化 #

Android端 #

• 优先把Bitmap存到native/共享内存区：Android 8.0以上系统默认将Bitmap像素数据存在native堆，低版本可配置图片库将Bitmap存入Ashmem匿名共享内存，应用堆内存只存Bitmap引用，从根源避免堆OOM
• 开启Bitmap复用池：所有待解码的Bitmap优先从复用池拿已申请的内存块，不要每次新申请内存，复用池大小和内存缓存大小对齐，大幅降低GC频率
• 图片展示项保持硬件加速开启：硬件位图直接存在显存中，不占用应用堆内存，绘制速度比普通位图快3倍，不要随意给ImageView关闭硬件加速
• 严格控制加载并发数：图片解码、下载的线程池核心数和设备CPU核心数对齐，最多不超过4个，避免CPU瞬间打满引发掉帧、ANR

iOS端 #

• 用ImageIO做按需解码：不要把整图全加载进内存再缩放，解码时直接按目标展示尺寸生成对应大小的缩略图，不保留原图尺寸的解码数据
• 内存缓存用NSCache存储，不要用普通字典：NSCache在系统内存不足时会自动淘汰部分缓存资源，不会被系统判定为内存超用强杀进程
• 无透明区域的头像关闭alpha通道，每像素内存占用从4字节降到3字节
• 列表滑动过程中用CATransaction临时禁用隐式动画，避免图片加载完成触发UI重排导致掉帧

四、验收标准（对齐WhatsApp性能） #

• 单页加载200个头像的列表，连续快速滑动100屏无闪退，帧率稳定在60帧
• 列表首屏头像加载耗时不超过300ms
• 中端机测试场景下，列表滑动过程中应用内存峰值不超过200MB

内容的提问来源于stack exchange，提问作者Mohammed Hansa