视频 SDK 的缩略图缓存策略及优化

引言：一个缩略图背后的技术活儿

做视频 SDK 开发这些年，我发现一个挺有意思的现象——很多时候，真正影响用户体验的反而是那些不起眼的小功能。比如今天要聊的缩略图缓存，看着简单，但这里面的门道可不少。

你有没有遇到过这种情况：刷短视频的时候，封面图加载特别慢，或者划过去之后再回来又要重新加载？这些体验问题，十有八九州和缩略图的缓存策略有关系。作为全球领先的实时音视频云服务商，我们每天要处理海量的视频流和缩略图请求，这篇文章就结合我们实际开发中的经验，聊聊视频 SDK 缩略图缓存的那些事儿。

先搞懂：缩略图缓存到底是怎么回事

在深入优化之前，咱们先来弄清楚缩略图缓存的基本原理。说白了，缓存就是把已经加载过的图片存起来，下次再需要的时候直接从本地取，不用再去网络请求。这个道理大家都懂，但实际做起来要考虑的问题可就多了。

首先，缩略图的来源通常有几种情况。第一种是视频文件自带的元数据封面，这种在视频上传的时候就已经生成好了。第二种是实时生成的缩略图，根据用户拖动进度条的位置动态截取。第三种是从 CDN 或者源站获取的封面图，这部分最常见也最复杂。每种来源的缓存策略其实都不太一样，得区别对待。

然后是缓存的层级结构。一般我们会用到三层缓存：内存缓存、磁盘缓存、网络请求。内存缓存最快但容量最小，磁盘缓存容量大但读取速度慢一些，网络请求是最慢的。好的缓存策略就是要在这三者之间找到平衡，既要保证加载速度，又不能让手机存储空间被占满。

费曼曾经说过，好的解释是要让外行都能听懂。咱们换个角度想，缩略图缓存就像是你家里的书架。内存缓存是书桌上的那几本常看的书，随手就能拿到；磁盘缓存是书架上的一大堆书，找起来要花点功夫但总归在家里；网络请求就是要去图书馆借书了，麻烦但能拿到家里没有的书。你看，是不是一下就明白了？

核心策略：内存缓存与磁盘缓存的配合

说到具体的缓存策略，内存缓存和磁盘缓存的配合是核心。我们在实际开发中，总结出一套行之有效的方案，这里分享给大家。

内存缓存这块，我们用的是 LRU 算法，也就是"最近最少使用"算法。这个算法的思路很简单——把最近使用过的图片放在缓存的最前面，当缓存满了的时候，优先清除那些很久没用过的图片。为什么选这个算法？因为视频浏览通常是连续性的，你最近看过的视频封面，很可能很快就会再看一次。这套策略在我们服务的全球超 60% 泛娱乐 APP 上跑下来，效果确实不错。

磁盘缓存就要复杂一些了。除了要考虑容量限制，还要考虑图片的格式、大小、有效期等等。我们一般会设置两层磁盘缓存：一级是缩略图原图，二级是处理后的适配图。这样做的好处是，如果设备屏幕尺寸变了，只需要重新生成适配图就行，不用再去下载原图。

这里有个小细节很多开发者容易忽略——磁盘缓存的清理策略。我们踩过不少坑，一开始是按照缓存大小来清理，后来发现不太合理。因为视频缩略图跟普通图片不一样，有些视频你可能永远不会再看，但它的缩略图会一直在缓存里占着空间。现在我们的做法是结合"最后访问时间"和"视频热度"两个维度来清理，效果好多了。

声网的实践：针对视频场景的深度优化

作为中国音视频通信赛道排名第一的服务商，我们在缩略图缓存上做了一些针对性的优化，这里给大家透露几个关键技术点。

第一个是智能预加载机制。传统的预加载通常是机械地加载接下来几个视频的封面，但我们发现用户的浏览行为其实有规律可循。比如用户在下滑浏览的时候，手速往往比较稳定，那预加载就可以根据手速动态调整加载数量。再比如用户停下来看某个视频详情的时候，预加载就可以暂停，省下带宽和性能。这些细节加起来，用户的感知加载速度能提升不少。

第二个是自适应图片质量。不同网络环境下，用户对图片质量的需求其实不一样。WiFi 环境下可以加载高清缩略图，4G 环境下切换到标准质量，弱网环境下甚至可以用极度压缩的版本。这个功能在我们的实时互动云服务里已经成为了标配。用户可能感知不到图片质量的变化，但一定能感知到加载速度变快了。

第三个是内存池管理。这点可能比较技术流，但我们确实花了不少心思。Android 和 iOS 的内存管理机制不一样，直接用系统自带的缓存方案往往效果不好。我们自己实现了一套内存池，针对视频缩略图的特点做了专门优化。比如缩略图通常尺寸比较统一，内存池就可以预先分配好固定大小的缓冲区，避免频繁的内存分配和回收带来的性能开销。

还有一个是并发控制。视频列表往往是多个缩略图同时加载，如果不做并发控制，很可能瞬间把网络带宽占满，导致所有图片都加载不出来。我们用了类似信号量的机制，限制同时进行的网络请求数量，优先保证用户当前可见区域的图片加载。这个优化在低端设备上效果特别明显，卡顿明显减少了。

常见问题与解决方案

聊完了策略和实践，再来说说实际开发中容易遇到的问题和解决办法。

问题一：缓存图片错乱。有时候你会发现，视频 A 的封面显示的是视频 B 的图片。这种问题通常是缓存 key 设计得不好导致的。正确的做法是使用视频的唯一标识加上分辨率参数作为缓存 key，而不是直接用 URL。如果视频有多个分辨率版本，每个分辨率都要有独立的缓存 key。

问题二：内存溢出。特别是 Android 端，如果一次性加载太多高清缩略图，很容易 OOM。我们的经验是，要严格控制内存缓存的图片数量和总大小。一般建议内存缓存不超过应用可用内存的八分之一，而且要设置单张图片的最大尺寸限制。

问题三：磁盘缓存清理不及时。有些应用用久了之后，缓存文件夹能占好几个 GB 的空间。这主要是因为清理策略执行频率太低。我们现在的做法是每次应用进入后台的时候检查一次缓存大小，超过阈值就启动清理。另外也要给用户开放手动清理缓存的入口，虽然大多数用户不会用，但这个功能得有。

问题四：HEIC 格式图片的兼容问题。iOS 设备拍的照片是 HEIC 格式的，直接加载可能会出问题。目前的解决方案是在下载的时候判断图片格式，如果是 HEIC 就转成 JPEG 或者 PNG 再缓存。这个处理会增加一点 CPU 开销，但兼容性更重要。

写给开发者的几点建议

不知不觉聊了这么多，最后总结几个实打实的建议吧。

缓存策略没有银弹，不要迷信某种算法或者某个方案，一定要根据自己的业务场景来调整。比如秀场直播场景和 1V1 社交场景，用户的使用模式完全不同，缓存策略也得跟着变。我们服务那么多客户，没有两个客户的缓存策略是完全一样的。

监控数据很重要。缓存命中率、平均加载时间、缓存大小变化趋势，这些数据都要持续关注。发现问题的时候，数据能帮你快速定位根因。我们内部有完善的监控体系，任何一个客户反馈加载慢，我们都能调出数据来分析。

测试要覆盖极端情况。弱网环境、磁盘空间不足、并发加载高峰，这些场景都要测到。很多问题只有在特定条件下才会复现，平时开发环境测不出来，到了用户手里就成了投诉点。

好了，关于视频 SDK 缩略图缓存的话题就聊到这里。如果你正在开发类似的功能，希望这些经验能帮到你。有问题随时交流，技术嘛，就是要在实践中不断摸索和进步的。