技术探索与实践：从一次iOS本地缓存优化说起
引言
我是小李，一名在某中大型互联网公司工作的iOS开发工程师，入行已有6年时间。从刚毕业时写点按钮和列表的“小白”到现在能主导模块设计和性能调优的“老手”，一路走来，踩过不少坑，也积累了不少经验。今天想通过一个实际的项目案例——iOS本地缓存机制的优化实践，聊聊我对技术探索与实践的理解。
这个故事发生在去年我们公司主推的一次版本迭代中。业务方希望我们在现有App上增加一项「离线浏览」功能，让用户在网络较差或无网环境下依然可以查看部分核心内容。听起来不复杂，但实际落地过程中却暴露了很多隐藏已久的技术问题，特别是在缓存策略的设计和实现上。
这篇文章会从项目背景讲起，带大家看看我们是怎么一步步找到问题、设计技术方案、实施代码改造，并最终达成目标的。中间也会分享一些具体的技术细节、踩过的坑，以及我在整个过程中的思考和总结。希望能给同样在一线做开发的同学带来一点启发。
项目背景
我们的产品是一个泛娱乐类的内容消费App，主要为用户提供短视频和图文内容推荐。虽然大部分场景下都依赖网络请求，但在地铁、公交等弱网环境中，体验非常糟糕。为了提升用户的使用粘性，产品经理提出了「离线浏览」的设想：在用户正常浏览的过程中，将部分内容自动缓存到本地，即使断开网络也能继续观看最近浏览过的数据。
听起来是个很合理的诉求。技术侧初步评估之后，认为主要是两个方向的工作：
- 后端配合生成可被缓存的数据结构
- 客户端设计并实现本地缓存机制
我负责的是客户端部分，重点在于如何高效地管理本地缓存、控制存储大小、避免重复缓存、保证缓存一致性，并提供一个易用且稳定的接口供业务层调用。
遇到的挑战
一、原有缓存逻辑混乱不堪
接手任务的第一天我就发现了问题。原有的缓存模块是早期一位同事写的，简单来说就是用NSUserDefaults + FileManager手动管理文件路径，在内存和磁盘间来回拷贝。随着业务发展，不同模块各自加了自己的缓存逻辑，导致：
- 同一份数据可能有多个缓存副本
- 清理缓存时找不到完整的清理入口
- 缓存命中率低，经常出现取不到数据的情况
- 磁盘占用高，但没留下有用的数据
这相当于从0开始搭建一套新的缓存体系，而且还要考虑历史数据迁移的问题。
二、内存 & 存储效率无法兼顾
在调研阶段我们做了性能测试，发现在频繁读取缓存时，主线程会有明显的卡顿。这是因为很多地方都是在主线程同步读取磁盘数据（例如图片、模型对象的反序列化），导致UI线程阻塞。同时，由于缺乏统一的清理机制，随着时间推移，App的本地存储空间越来越大，严重影响用户体验。
三、缓存一致性难以保障
在并发写入的情况下，还出现了「脏数据」问题。比如，某个接口更新了缓存内容，而另一个接口却还在使用旧的数据，甚至在某些极端情况下出现数据错乱。
这些问题说明我们原来那套缓存系统已经不能满足业务快速发展的需求。我们必须重新设计一套更合理、稳定、高效的本地缓存方案。
解决思路与技术选型
目标明确
我们设定的目标是：
✅ 实现高效、安全、易维护的本地缓存系统
✅ 支持多类型数据缓存（JSON、图片、视频等）
✅ 具备内存缓存 + 持久化双层结构
✅ 提供清晰的生命周期管理和清理接口
✅ 尽量减少对业务层的侵入性，做到即插即用
技术选型参考
iOS本身提供了几种主流的缓存方案：
| 方式 | 优点 | 缺点 |
|---|---|---|
| NSCache | 系统原生支持，线程安全 | 不支持持久化 |
| DiskCache | 可持久化，容量可控 | 需要自行实现封装 |
| CoreData | 功能强大，结构清晰 | 适合关系型数据，复杂度较高 |
| Realm / SQLite | 可以替代CoreData | 对简单缓存来说有点重 |
| 自定义 FileManager + GCD | 完全可控，灵活性强 | 易出错，需处理大量底层细节 |
综合比较下来，我们决定采用组合方式：用NSCache做一级内存缓存，用DiskCache做二级持久化缓存，并通过一个统一的封装层对外暴露接口。这样既保证了访问速度，又能持久化保存热点数据。
最后我们选择了开源库 SDWebImage 中的缓存组件作为磁盘缓存的基础模块，再结合自己的需求进行扩展。之所以选择它，一是因为其成熟度高、社区活跃；二是因为它内部已经实现了LRU策略、线程调度、异步IO等关键特性。
核心实现细节
1. 设计统一缓存接口
我们抽出了一个协议 Cacheable，用于规范各种类型数据的缓存行为：
protocol Cacheable {
associatedtype T
func get(forKey key: String, completion: @escaping (T?) -> Void)
func set(_ value: T, forKey key: String, expiry: Expiry?)
func remove(forKey key: String)
func clear()
}
这里的 Expiry 是一个枚举，用来表示缓存的有效期：
enum Expiry {
case never // 永不过期
case seconds(Int) // 几秒后失效
case date(Date) // 到指定日期失效
}
这样做的好处是，业务层只需关心怎么用，无需理解底层实现细节。
2. 内存+磁盘双层缓存实现
内存层使用 NSCache，磁盘层基于 SDWebImage 的 SDMemoryCache 和 SDDiskCache 进行包装：
class DoubleLevelCache<T>: Cacheable where T: Codable {
private let memoryCache = NSCache<NSString, AnyObject>()
private let diskCache: SDDiskCache
init(diskCache: SDDiskCache) {
self.diskCache = diskCache
}
func get(forKey key: String, completion: @escaping (T?) -> Void) {
if let cached = memoryCache.object(forKey: key as NSString) as? T {
completion(cached)
return
}
diskCache.asyncGetData(forKey: key) { data in
guard let data = data else {
completion(nil)
return
}
do {
let decoded = try JSONDecoder().decode(T.self, from: data)
self.memoryCache.setObject(decoded as AnyObject, forKey: key as NSString)
completion(decoded)
} catch {
completion(nil)
}
}
}
func set(_ value: T, forKey key: String, expiry: Expiry? = .never) {
memoryCache.setObject(value as AnyObject, forKey: key as NSString)
diskCache.setData(try? JSONEncoder().encode(value), forKey: key, expiresAt: expiry?.toDate())
}
// ...其他方法略
}
这段代码看起来有点长，其实核心逻辑很简单：先查内存，命中就返回；没命中再去查磁盘缓存，解析成功后回填到内存。
3. 缓存路径与命名策略
为了避免键冲突，我们统一采用了模块名 + 唯一标识符的方式来组织 key：
struct CacheKeys {
static func videoDetail(withId id: Int) -> String {
return "video.detail.\(id)"
}
}
同时，针对大文件（如高清图片、视频）设置了不同的子目录和独立缓存池，防止它们挤占常规数据的空间。
踩过的坑 & 解决办法
❗️坑一：编码解码异常导致崩溃
在初期上线后，我们发现有一小部分用户上报了崩溃日志，原因是有些数据在解析时抛出了异常。经过排查发现，是某些字段类型变更或为空导致的 DecodingError。
我们后来做了两点改进：
- 在获取数据时捕获异常并记录埋点日志；
- 引入 fallback 机制，如果失败则直接清理该缓存项，下次再拉取新数据。
do {
let model = try JSONDecoder().decode(MyModel.self, from: data)
} catch DecodingError.typeMismatch(_, _) {
// 埋点记录兼容错误
LogService.log("decode error")
cache.remove(forKey: key) // 删除错误缓存
}
❗️坑二：后台清理逻辑耗时过高
我们原本使用了一个串行队列来做缓存清理操作，结果遇到极端情况会导致主线程等待资源释放，进而卡顿。
解决办法是：将所有缓存操作切换到并发队列，并通过 DispatchGroup 控制异步回调流程：
let queue = DispatchQueue(label: "cache.queue", qos: .utility, attributes: .concurrent)
let group = DispatchGroup()
queue.async(group: group) {
// 执行耗时任务...
}
group.notify(queue: .main) {
// 回调主线程
}
❗️坑三：模拟器调试看不到缓存数据？
这个问题是我个人调试的时候踩的。因为我们使用的是CachesDirectory目录，而Xcode的模拟器沙盒中默认只显示少量目录。如果你在Finder里打开 .app 文件夹没看到缓存数据，记得执行以下命令：
open $(getconf DARWIN_USER_CACHE_PATH)
或者在代码中打印缓存路径：
print(FileManager.default.urls(for: .cachesDirectory, in: .userDomainMask).first!.path)
最终效果与收益
经过两周的重构和灰度发布，我们在正式版上线后做了AB实验对比：
| 指标 | 对照组 | 新增缓存策略 |
|---|---|---|
| 页面加载速度提升 | - | 平均快约0.3s |
| 离线可用率 | 18% | 提升至72% |
| 用户留存率 | 保持平稳 | 上涨4.2% |
| 存储占用（MB） | 58.3 | 控制在35以内 |
从数据上看，这次优化不仅提升了整体体验，也让我们的缓存模块变得更有弹性、更易维护。更重要的是，我们建立了一套标准化的缓存接口，后续其他模块接入成本大幅降低。
个人心得与建议
回顾整个过程，我学到最多的不是技术本身，而是几个关键的认知转变：
🧭 1. 技术方案要服务于业务目标
有时候我们会陷入追求极致性能或炫技的陷阱，但实际上，解决问题才是第一位的。我们没有盲目引入新技术栈，而是基于已有的能力做了适度的抽象和封装，反而更容易推动落地。
🧱 2. 分层设计非常重要
无论是缓存还是其他功能模块，都需要分层清晰、职责单一。把复杂的逻辑拆开来，每一层各司其职，才能保证系统的可扩展性和可维护性。
🐛 3. 日志和监控不可忽视
如果没有线上日志和异常采集系统，那次崩溃很可能不会那么早被发现。建议大家在日常开发中就养成加打点、设异常兜底的好习惯。
📦 4. 开源工具不是万能的，要学会定制
像SDWebImage这样的优秀库虽然能大大减少工作量，但我们仍然需要根据实际业务需求做出调整。不要怕改库，只要你能理解原理、有能力维护，就能为我所用。
结语
技术探索从来都不是一个孤立的过程，而是不断在实践中发现问题、解决问题、验证成果的循环。这一次本地缓存的优化，让我深刻体会到：好的架构不是一开始就设计出来的，是在持续迭代中逐渐沉淀下来的。
如果你也在做类似的优化或架构重构，不妨从小处着手、分段推进、及时验证。哪怕每次只做一个小模块，只要方向正确，假以时日就会积少成多，形成自己的一套工程体系。
愿我们都能在这个飞速变化的行业中，既不失热情，也不失理性，脚踏实地走出属于自己的技术之路。
文章完。欢迎留言交流你的技术探索经历或缓存实战经验，我们一起成长。
评论 0