核心是分层调度异步图片加载：按需加载、可见性驱动、三级缓存、优先级队列与防复用污染。iOS用UIScrollViewDelegate+NSOperationQueue，Android用RecyclerView滚动监听+ThreadPoolExecutor，鸿蒙用ScrollListener+LazyForEach；内存缓存用LRUMap，磁盘缓存存WebP，网络兜底加CDN缓存；任务按priority排序，高优走独立线程池；ImageView设tag校验防错位。
处理大量异步图片加载任务，核心在于“不抢资源、不乱顺序、不卡主线程”。关键不是让所有图同时开跑，而是分层调度：优先保障可见区域与用户焦点，延迟或跳过非必要内容，并用缓存和压缩压低重复开销。
按需加载 + 可见性驱动
列表或瀑布流中一次性加载全部图片必然拖垮内存和网络。应结合滚动监听与视口计算，只对即将进入可视区域（如提前1–2屏）的图片触发加载。
- iOS 可用 UIScrollViewDelegate 检测偏移，配合 NSOperationQueue 控制并发数（建议设为3–6），避免线程爆炸
- Android 中 ListView/RecyclerView 应监听 onScrollStateChanged，在 SCROLL_STATE_IDLE 时批量加载，滚动中暂停或节流
- 鸿蒙使用 ScrollListener + LazyForEach，配合 imageCacheSize 限制内存缓存容量
三级缓存策略落地
避免反复下载和解码，必须建立稳定缓存链路：内存 → 磁盘（本地存储） → 网络。
- 内存缓存：用 LRUMap 或框架内置缓存（如 Glide 的 ActiveResources + MemoryCache），大小建议设为可用堆内存的 1/8～1/4
- 磁盘缓存：对已解码的 Bitmap 存为 WebP（比 PNG 小 25%～35%），文件名用 URL MD5 + 宽高后缀（如 abc123_300x200.webp），避免尺寸错配
- 网络兜底：仅当两级缓存都未命中时才发起请求；HTTP Header 加 Cache-Control: public, max-age=86400 复用 CDN 缓存
加载顺序主动干预
异步本身不保序，但业务有强优先级——首屏图、头像、主商品图必须先到，广告位、装饰图、彩蛋可延后甚至懒初始化。
- 给每个加载任务打标：priority: 'high' / 'normal' / 'low'，队列按 priority + 入队时间排序
- 高优任务走独立线程池（如 iOS 的 high-priority QoS，Android 的 ThreadPoolExecutor with CORE_POOL_SIZE=2）
- 低频模块（如“生成海报”按钮背后的头像合成）完全不预加载，点击后再 import('./AvatarComposer.vue') 动态引入
防错位 + 防复用污染
RecyclerView/ListVIew 复用机制易导致图片“张冠李戴”，尤其在网络延迟不均时。
- 加载前为 ImageView 设置唯一 tag：imageView.tag = imageUrl
- 回调时校验 tag 是否仍匹配，不匹配则丢弃结果（Glide/Picasso 默认已做此保护）
- 避免在 ViewHolder 中持有 Bitmap 引用，防止内存泄漏；用 WeakReference 包装监听器
