按理说，

摘要图文类 App 最难的不是“把列表做出来”。而是把首屏速度、滑动流畅度、弱网体验和内存稳定性一起做好。这篇文章结合一个 UIKit 图文流项目。完整拆解图片双层缓存、RunLoop 空闲解码、SQLite 冷启动回填、弱网降级、Memory Warning 止血与埋点观测闭环，并附带主要代码与流程图。

使用者痛点

• 首屏加载慢，使用者先看到白屏或空列表。
• 滚动时图片出现卡顿或“停下来才补图”。
• 弱网下频繁刷新失败，体验极差。
• 多图场景下内存飙升，被程序强制杀掉。
• 内存告警后仍出现闪退或资源使用情况反弹。

一、从卡顿白图到稳定可用：双层缓存、弱网降级与 OOM 治理

1) Feed 数据双层缓存：先把内容尽快展示来

列表内容的体验第一原则不是“永远最新”。而是先尽快有内容，再异步校准。

L1这方面，SQLite 本地缓存 L2的观点是，FeedAPI 网络数据

1. 先尝试从 SQLite 读取缓存
2. 如果有数据。先展示来
3. 再异步发起 refresh，拿最新数据覆盖并回写 SQLite

func loadInitial async {
if featureFlags.bool {
if let cached = try?其实，store.fetchLatest,!cached.isEmpty {
posts = cached
analytics.track
onStateChanged?}
}
await refresh
}

2) 图片双层缓存：决定滚动体验的关键

• L1的观点是，LRUCache,缓存已解码图片 说到L2，URLCache.shared。缓存原始响应 data

L1 命中直接回调

if let cached = memoryCache.value {
log.debug")
AnalyticsTracker.shared.track
completion)
return token
}

L2 没命中才走网络

let config = URLSessionConfiguration.default
config.requestCachePolicy = .useProtocolCachePolicy
config.urlCache = .shared
config.httpMaximumConnectionsPerHost = session
let session = URLSession

downsample 后再写回 L1

3) RunLoop 空闲调度解码：让滚动更平滑不掉帧

DPI 场景下下载完成后的 data 并不会立刻去解码，而是先丢进 RunLoopIdleWorkScheduler，在主线程空闲时再派发后台解码任务。

RunLoopIdleWorkScheduler.shared.enqueue { in
guard let self else { return }
self.decodeQueue.async {
let image = ImageDownsampler.downsample(
从data来看，data,to: targetPixelSize,scale: UIScreen.main.scale)
if let image {
let cost = ImageLoader.approxCost
self.memoryCache.setValue
self.finish)
} else {
self.finish(key: key。result: .failure))
}
}
}

This means：

• User scrolling fast → main thread busy → RunLoop rarely idle → decoding tasks queued.
• User stops → RunLoop drains → decoding runs → images appear.
• No frame drops because decoding is delayed until idle.

4) 请求去重

Ahead of multiple requests for same URL,we merge m via an in-flight map.

if var inflight = inFlight {
inflight.tokens.insert
inflight.completions.append
inFlight = inflight
lock.unlock
return token
}

5) LRU Cache 按成本淘汰 而非仅按张数

A small icon and a big photo consume very different memory;hence we maintain totalCost and evict from tail when exceeding limit.

func setValue {
lock.lock
defer { lock.unlock }
if let node = dict {
totalCost -= node.cost
node.value = value
node.cost = max
totalCost += node.cost
moveToHead
} else {
let node =
Node)
dict =
node
insertAtHead
totalCost += node.cost
}
evictIfNeeded
}
private static func approxCost -> Int{
guard let cg=image.cgImage else { return }
return cg.bytesPerRow * cg.height
}

6）弱网降级策略

• 离线时优先展示已有本地缓存；不过，
• 有内容时不打扰使用者；
• 没内容时给出明确提示；
• 阻止无意义刷新和分页。
• 配合 SQLite 冷启动，让弱网/离线场景更友好。

  
  if featureFlags.bool,networkMonitor.isOnline == false {
  if posts.isEmpty {
  onError?}
  return
  }
  

  七）OOM 根因及治理

  • 原因的观点是，峰值瞬时太高。
  • 说到对策，
    • 减少不必要的大对象生成
    • 去重重复解码
    • 停止不可见资源工作
    • Memory Warning 时立即止血

  八）Memory Warning 后不能只清缓存

  swfit@objc private func didReceiveMemoryWarning { let cacheCost=ImageLoader.shared.currentCacheCost let inFlightCount=ImageLoader.shared.currentInFlightCount log.warning inflight=\") AnalyticsTracker.shared.track(.memoryWarning。properties:)

  FeatureFlagCenter.shared.set(false,for:.imagePrefetchEnabled)

  imageCache?.removeAll

  ImageLoader.shared.cancelAllLoads }

  swfitfunc cancelAllLoads{ lock.lock let tasks=inFlight.values.map tokenToKey.removeAll inFlight.removeAll lock.unlock

   tasks.forEach{ $0.cancel }
  RunLoopIdleWorkScheduler.shared.removeAll
  

  }

  意义 * 清空 LRU Cache * 取消所有 In‑flight 请求 * 清理待执行 decode queue * 自动关闭预取进入低内存降级模式
  
  
  

  九）取消策略三层防护

  swfitoverride func prepareForReuse{ super.prepareForReuse cancelImageLoading imageViews.forEach{ $0.image=nil } lastPostID=nil }

  swfitfunc tableView(_ tableView:UITableView。 didEndDisplaying cell:UITableViewCell,forRowAt indexPath:indexPath){ .cancelImageLoading prefetchTokensByIndexPath.removeValue?. forEach{imageLoader.cancelLoad} }

  swfitfunc tableView(_ tableView:UITableView,cancelPrefetchingForRowsAt indexPaths:){ for indexPath in indexPaths{ guard let tokens=prefetchTokensByIndexPath. removeValueelse{continue} tokens.forEach{imageLoader.cancelLoad} } }

  十）可观测性闭环

  埋点	用途
  feedCacheHit	首屏是否命中本地缓存
  imageCacheHit	内存 Cache 命中率
  imageLoadSuccess / Failure	图片加载成功率
  memoryWarning	内存告警时成本 & In‑flight 数量
  oomTrigger	OOM 前预取/Decode 阶段情况

  通过这些事件可以回答：

  • 首屏缓存命中率高吗？
  • 图片内存 Cache 是否有效？
  • 是否出现异常失败率上升？

  这对定位线上 OOM 非常关键。

  十一）完整链路流程图

  mermaid flowchart TD A --> B A --> C C --> D D --> E{L1 内存 Cache 命中?} E -->|是| F E -->|否| G{已有 In‑flight 请求?} G -->|是| H G -->|否| I I --> J{URLCache 命中?} J -->|是| K J -->|否| L L-->K K --> M M --> N{主线程空闲?} N -->|否| O N -->|是| P P --> Q Q --> R R-->F

  F-->S{Cell 离屏/快速滑过?} S-->T S-->U

  F-->V{Memory Warning?} V-->W W-->X X-->Y Y-->Z

  Z--->A # loop back to feed reload if needed

  十二）实际收益

  对使用者

  • 首屏更快，即使离线也能看到内容。话说回来，
  • 滚动更平稳。无明显卡顿，
  • 弱网/离线场景验更友好。
  • 内存告警后闪退风险大幅降低。

  对研发

  • 有可观测事件支持定位问题。
  • 各模块独立演进，可按需调整。
  • 性能调整从经验走向可衡量、可复现。

  十三）

  图文流性能调整不是单个技巧，而是一套程序设计：

  1. 先尽快让内容出现。
  2. 平滑补齐图片。
  3. 弱网无意义工作降级。
  4. 低内存即刻止血。
  5. 埋点闭环——实时监控每一步。

  一句话概括这方面。图文类 App 的性能稳定性，本质上就是资源生命周期管理与可观测性的闭环协同。

  项目链接请自行搜索相关开源实现以获取更多细节。