反思 | Android 音视频缓存机制的系统性设计

Posted 2022-11-27 却把清梅嗅

反思 系列博客是我的一种新学习方式的尝试，该系列起源和目录请参考 这里 。

背景

在自媒体的时代，音视频播放 俨然已成为内容类型 APP 最基础的能力，对于 android 开发者而言，无论是 Google 开源的 ExoPlayer ，还是 Bilibili 开源的 ijkplayer ， 都是构建应用音视频播放能力时优秀的选择。

虽然上述的三方播放器都自带完善的缓存功能，但对于内容和形式都日新月异的一众互联网产品来说，想要打造完美契合自家产品的用户体验，播放器自身的缓存机制已逐渐无法满足需求。

最具代表性的产品是 抖音。 在播放短视频内容时，保证浏览、上下切换时 无缝链接 般丝滑的用户体验，可以说是重中之重的性能要求，而这对于传统的播放器缓存机制而言是远远满足不了要求的。

因此，构建自定义音视频缓存机制势在必行。

本文将针对 Android 音视频缓存解决方案中，先驱级别的 AndroidVideoCache 库进行深入的剖析，读者不应关注具体的代码细节，而应关注整体的设计思想及流程实现。

文章整体结构如下：

现有方案对比

1、文件整体缓存

这是最简单的缓存方案，即 先下再播 ，只有文件完整下载完毕，才能进行播放。

严格来说，在某些特殊的业务场景，这种方案简单、粗暴但却 有效 ，比如微信聊天中的小视频，经过限制时长以及高效的压缩算法，视频整体被压缩的非常小，对于 4G 早已覆盖的用户群体而言，加载、播放视频整个流程中几乎不受影响。

在其他下载成本略高的场景，诸如短视频、播放音乐，这种方案就不太适合，更不论电视剧、电影这类更重的应用场景了。

2、基于源码修改

第二个方案，是基于播放器源码进行修改，优势在于简洁直接，能够以较低开发成本满足业务需求，但缺点有二：

首先，当播放器为三方SDK时，源码修改成本变高，同时，当需要替换播放器SDK时，需针对缓存机制重新开发。

其次，缓存机制不可避免会涉及实际业务，这会提升业务层与底层播放能力之间的耦合。

3、音视频缓存代理方案

由此可见，我们更期望能够在 业务层 和 播放器层 之间搭建一个中间商，由这个新的角色 代理 与业务层的通信，然后 分发 与 执行 播放器层的音视频缓存任务。

4、更多优势

从长远来看，针对现有的架构设计，额外定义一个 缓存层 是很有必要的，这意味着容易实现和扩展 更多细节性的需求；比如同时针对多个音视频进行缓存、针对不同优先级缓存任务速度的限制策略等等，对于月活千万或上亿的头部应用而言，这些都是保证极致用户体验的必要实现。

整体设计

如何构建音视频缓存的代理？首先，我们需要了解 APP 音视频的常规缓存模式及其弊端：

如图所示，常规方式中，缓存相关逻辑是由播放器本身提供的，开发者仅需将视频地址的url交给播放器，播放器会自动进行加载播放。

这种方式下，想要自定义缓存就必须深入播放器源码，对于开源播放器而言，虽然源码上手成本较高，但至少是可针对源码进行定制，但对于部分非开源的播放器而言，开发者几乎无法直接触达内部缓存机制。

---

我们更希望，无论播放器本身是否开源，都能够在 不涉及理解和修改播放器源码 的情况下，完全控制音视频的缓存机制——我们先将这个中间角色称为 CacheService，整体流程如下：

如图所示，播放器层的播放和加载流程都委托给 CacheService，后者内部实现了包括文件下载、文件读写等一系列的相关逻辑，最终转交给播放器进行播放。

需要注意的是，由于 CacheService 完全是由我们自己定义的，因此我们也可以监听到音视频文件的整个缓存流程，并直接回调通知给最上层的 APP（上图中onCacheStart()等回调），且整个过程完全是 响应式 的。

读者应该理解，之所以 直接回调通知最上层 ，是有这个前提——我们希望整个缓存流程都不会涉及到播放器层的改动，比如 Android 系统的 MediaPlayer，我们无法也不应该修改它。

具体实现

1、逻辑冲突

设计的伊始谈到，为了保证解耦， 我们希望缓存机制 不能修改播放器源码 ，但 MediaPlayer 如何在不改源码的情况下，将自身的缓存加载逻辑交给我们的 CacheService 呢？

如下述代码中所展示的，这种实现似乎无法避免：

public class MyMediaPlayer extends MediaPlayer 
  
  public final CacheService mProxy;
  
  @Override
  public void setDataSource(String url) 
    // super.setDataSource(url);
    mProxy.setDataSource(url);
  

必须承认，这也是一种与播放器的耦合，不能修改播放器源码 的设定似乎并不符合常理。

这里体现出了作者本身优秀的创造力，通过创建一个设备的本地代理服务 CacheService，在将视频资源的url交给播放器之前，先进行本地的一次转换，并将初始的url作为参数，拼接在本地代理的url上:

1.建立本地代理：比如 http://127.0.0.1:8090
2.拿到要缓存的视频地址，比如 https://xxx.mp4
3.拼接为新的地址：http://127.0.0.1:8090/https://xxx.mp4

拿到新的 url 并交给任意播放器后，播放器的加载都指向本地服务的新地址——即通过 Socket 连接建立的本地服务 CacheService，后者通过解析出请求中真正的 https://xxx.mp4 地址，创建对应的下载任务，并从下载的文件缓存中，读取 buffer 返回给播放器；同时，监控整个流程的 CacheService 响应式地回调过程中所有大大小小的事件。

经过这样设计，整个流程的调用变得非常简单：

public class MainActivity extends Activity 
  
  public final MediaPlayer mPlayer;
  
  @Override
  public void playVideo(String url) 
    final String proxyUrl = VideoUtils.getProxyUrl(url);
    // url = https://xxx.mp4
    // proxyUrl = http://127.0.0.1:8090/https://xxx.mp4
    mPlayer.setDataSource(proxyUrl);
  

2、创建代理服务器

接下来，笔者通过伪代码的形式，简单阐述下创建本地代理连接的过程。

上文提到的本地服务 CacheService在创建时，会自动初始化一个本地代理服务器，配置ip和自动分配端口号，这之后，服务完成初步建立，并立即开启一个线程，等待接收客户端的后续连接。

// 实际类名 HttpProxyCacheServer.java
public final class CacheService 
  
  private CacheService(Config config) 
        // 初始化ip和端口号
        InetAddress inetAddress = InetAddress.getByName("127.0.0.1");
        this.serverSocket = new ServerSocket(0, 8, inetAddress);
        this.port = serverSocket.getLocalPort();
        // 开启新的线程，等待后续接收客户端的连接
        this.waitConnectionThread = new Thread(new WaitRequestsRunnable());
        this.waitConnectionThread.start();
    

3、处理缓存请求

本地服务建立完毕，当用户尝试播放音视频时，播放器实际上访问类似 http://127.0.0.1:8009/https://xxx.mp4 的地址，这时我们的 CacheService 中接到了对应的消息。

针对每一次请求，我们都能解析到真实音视频文件的地址（https://xxx.mp4），为了提高复用性，我们声明一个HttpProxyCache类，为每一个音视频配置一个对应的 HttpProxyCache 以进行管理:

class HttpProxyCache extends ProxyCache 
    // 视频资源的url地址
    private final HttpUrlSource source;
    // 视频资源的本地文件信息
    private final FileCache cache;

实际上还不够，我们还需要针对每个音视频缓存过程的回调进行管理，因此，基于此再封装一层，使用 HttpProxyCacheServerClients 管理一个音视频资源：

final class HttpProxyCacheServerClients 
    private final String url;       // 视频资源url
    private volatile HttpProxyCache proxyCache;  // 缓存信息
    private final List<CacheListener> listeners = new CopyOnWriteArrayList<>(); // 缓存监听

简单概括一下，针对一次新的音视频资源加载，会构建一个新的 HttpProxyCacheServerClients，内部除了相关信息的成员，还包含了 HttpProxyCache 对象用于读取和加载缓存。

4、远程加载流程

抽象地看待音视频的源，分为 远程音视频资源 和 本地音视频资源，当不使用缓存时，必然会从远程进行下载，并不断将音视频的流通过 Socket 向播放器传输。

这里我们将 源 抽象为 Source:

public interface Source 

    // 建立打开资源
    void open(long offset) throws ProxyCacheException;

    // 获取音视频的长度
    long length() throws ProxyCacheException;

    // 不断读取音视频数据
    int read(byte[] buffer) throws ProxyCacheException;

    // 关闭释放资源
    void close() throws ProxyCacheException;

对于远程加载的完整流程，本质上就是建立、打开、读取和关闭一个远程连接 HttpURLConnection的过程，核心代码如下:

public class HttpUrlSource implements Source 
    @Override
    public void open(long offset)
      HttpURLConnection connection = openConnection(offset, -1);
    
    
    @Override
    public int read(byte[] buffer)
      return inputStream.read(buffer, 0, buffer.length);
    
    // ...

5、缓存加载流程

更多的时候，无论音视频资源是否已下载，我们都希望通过缓存统一加载管理：

1、文件已下载：直接读取本地文件，将数据通过Socket不断传回给播放器；

2、文件未下载：新建一个本地文件，并开启远程下载任务，下载过程中，数据流不断涌入本地文件，本地文件大小、下载进度的变更都会响应式通知上层；除此之外，新的音视频流数据会通过Socket不断传回给播放器，播放器也会不断的推进播放进度。

由此可见，无论文件是否下载，缓存流程都是围绕 本地缓存文件 进行的，这也符合软件开发中的 唯一可信源 的概念。

---

接下来笔者针对部分细节问题进行探讨。

6、自定义缓存策略

缓存所占用的空间往往会成为迫使用户卸载应用的最后一根稻草。

开发者不能无上限对音视频资源进行缓存，通常的维护手法是通过 限制空间大小，比如，用户通常可以接受视频类应用有 1G 左右的缓存空间，即时通信类应用也许会更大些。

因此我们的缓存库也需要提供这样的能力，可通过实现DiskUsage接口，实现不同的缓存策略。

// 缓存空间管理类
public interface DiskUsage 

    void touch(File file) throws IOException;

可以预设一些缓存策略供开发选择：

• TotalCountLruDiskUsage：限制缓存数量
• TotalSizeLruDiskUsage：限制缓存大小
• UnlimitedDiskUsage：没有缓存限制

对于这样的诉求，通用的解决方案仍然是经典的 LruCache，通过最近最少算法，缓存达到上限时，清理掉最久远的缓存文件。

7、缓存文件生成策略

类似的还有缓存文件的文件名生成策略，默认是使用的 MD5 方式生成 key，考虑到一些业务逻辑，我们也可以自定义一个 FileNameGenerator 来实现自己的策略:

public interface FileNameGenerator 

    String generate(String url);

展望 & 更多问题

看起来，目前 AndroidVideoCache 库已经非常全面——这也正是目前 GitHub 上源码中提供现有的全部功能。

实际上，对于市面上复杂的音视频产品而言，部分功能还有所欠缺，简单列举几条如下：

1、视频文件类型支持不够

针对体量较小的产品系统而言，针对 mp3、mp4 这种简单的音视频文件的缓存完全够用，但对于复杂庞大的系统，更多类型的音视频资源一旦涌入，现有实现变得捉襟见肘。

m3u8 格式视频的缓存是典型的场景，由于是切片的数据，因此需要特殊的处理方式，缓存需要考虑切片索引以及视频文件的拼接。

2、Seek功能的缓存支持

缓存加载流程 一节中，笔者针对 文件已下载 和 文件未下载 进行了简单的概括。

事实上，用户真实的交互非常复杂，Seek操作是一个典型的操作：当用户播放时长10分钟的视频时，当缓存预加载到第4分钟时，用户直接操作进度条，从第1分钟切到了第8分钟。

此时，由于缓存尚未预加载到指定的位置，而目前的实现仅仅对一个本地文件进行读和写的操作，因此我们不能直接在现有的缓存文件上（第4分钟）直接追加断裂的（第8分钟）数据。

因此现有实现的方式是，针对这种情况，直接结束缓存过程，直接加载远程数据——即切换到 远程加载流程，不再写入和读取本地缓存文件。

这就导致一个额外的后果，当用户下一次点击播放这个视频，本地的缓存文件中只有4分钟的缓存，用户依然要浪费相当一部分的流量。

3、多任务缓存 & 限速策略

文章开始我们说到，针对部分业务场景，产品需要提供 多任务同时缓存 的能力，依然以 抖音 为例，在播放第一个短视频时，同时针对后续的 1-3 条短视频进行 预加载 是完全有必要的。

除此之外，我们还需要针对不同类型的缓存任务设置不同的 缓存优先级，通过维护一个 任务队列，保证任务能够按需分配，按优先级及时执行。

最后，针对不同优先级的缓存任务，还需要分配不同的 限速策略，保证多个 多任务同时缓存 时，前台的视频不会被后台的任务影响，保证用户的视听体验。

阶段性小结

当然，即使 AndroidVideoCache 目前的实现还有一些不足，我们依然无法否定它在 Android 音视频缓存领域做出的巨大贡献。

换句话说，AndroidVideoCache 现有的实现已经为我们提供了通用性的解决方案，对于小型项目完全可以直接使用；对于大型项目，我们只需在现有的基础上，对自身业务进行补充，也完全可以达到 产品化 的目的。

同时，这种 建立本地代理服务 、 响应式的缓存机制 的思想是非常优秀的，即使是若干年后 Google 推出的 Jetpack Paging 分页组件，也隐约可以看到这种思想的影子，读者可仔细理解这种设计理念，并尝试应用到更多的业务架构设计上去。

针对上一节中几个问题的解决方案，限于篇幅原因，笔者在下一篇文章 Android音视频缓存机制的产品化实现 中进行扩展性的讲述，敬请期待。

---

参考文章

本文旨在将 Android 音视频缓存机制进行系统性阐述，只有读者学会了理论，针对代码细节才能更高效、更深入地理解，下面是几篇源码分析非常优秀的文章，有兴趣的读者可以选择性参考。

• AndroidVideoCache-视频边播放边缓存的代理策略 @sheepm

• 视频缓存AndroidVideoCache攻略 @juexingzhe

• Android主流视频播放及缓存实现原理调研 @罗拙呓

• 音视频开发之旅（49)-边缓存边播放之AndroidVideoCache @yabin小站

关于我

Hello，我是 却把清梅嗅 ，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的 博客 或者 GitHub。

• 我的Android学习体系
• 关于文章纠错
• 关于知识付费
• 关于《反思》系列