Open SuperMan-Lfj opened 2 years ago
播放器缓存的功能现在是一个非常普遍并且很重要的一个功能。 通过缓存，可以达到以下目的：
缺点有：增加对文件的占用
想要实现播放器的缓存，有好几种方式：
一般cache库都是针对https做的处理，本质就是一个http代理服务器。当播放的时候，先从cache库中拿到转换后的代理地址，然后设置转换后的地址去播放。这样播放器在播放的时候请求数据，实际就是走到了代理服务器中。此时代理服务器就可以将数据缓存下来。如果下次请求的数据已经缓存过了，就可以直接从代理中返回数据。
这种方式的优点就是：对播放器无缝对接。尤其是对于没有自研播放器能力的时候，这种方式几乎是唯一可行的方式。 缺点的话，无法针对格式做特定的优化，比如HLS.DASH等，有些cache库可能就不支持这些功能。
对有自研能力的播放器来说，大部分是这种方式。
播放器提供一个控制缓存API。当用户开了缓存之后，播放器则边从网络读数据边记录到磁盘上。下次播放的时候，也从磁盘读取数据。
这种方式的优点就是：完全自主可控。 缺点就是：播放器有些情况下并不适合缓存，比如直播流。缓存下来之后，播放的都是过期的内容，显然是不合理的。多码率流如果缓存，从本地读数据的时候，会影响网速的计算，就会对码率切换造成影响。 针对缺点，播放器可以根据实际的媒体类型，比如直播流，多码率流等做不能缓存的控制。但是这样对播放器的模块有入侵：因为数据读取是网络模块，而媒体的信息在其他模块，造成了不能完全解耦。
对于播放器来说，大部分点播流或者部分直播流都是HTTP、HTTPS协议的。而HTTP协议是提供了一套完整的HTTP Cache的缓存控制协议的。所以播放器也是可以通过支持HTTP 的cache control，来实现缓存与否的整个逻辑。
这种方式的优点就是不需要关注媒体信息，只聚焦于http协议的头等信息，就可以知道能否被缓存。这样就能保证模块解耦。 但是这种方式的缺点就是：如果协议没有缓存控制相关的设计，就没有办法处理了。还需要特殊处理。
播放器请求数据并不像一般的下载数据，播放器请求的时候，会有seek等操作，导致请求的数据位置并不是连续的。所以这里就引发出了一个保存文件的结构设计。
一般来说，有三种方式：
即将位置连续的数据放到一个文件中。如果不连续，则放到另一个文件中。必要时还需要合并两个碎片文件。查找的时候，根据请求数据的位置，找到对应的碎片文件，从而找出需要的数据。 这种方式缺点就是文件较多，操作较多。优点是不需要记录其他的信息。
顾名思义，就是先创建一个跟流大小一样大的文件，占用住空间。然后将请求到的数据按照位置写入到文件中。 这种方式的优点就是：不需要做额外的文件合并操作，也没有文件碎片。缺点就是需要记录文件中，哪些地方有数据，哪些没有数据。同时占用磁盘空间看着好像很大。
这种方式就是通过直接追加的方式记录到文件中。 这种方式的优点就是：没有碎片文件，文件大小也是正确的。缺点就是在读取数据的时候，会在文件中来回跳转，处理逻辑要相对复杂一点。
缓存的优点
播放器缓存的功能现在是一个非常普遍并且很重要的一个功能。 通过缓存，可以达到以下目的：
缺点有：增加对文件的占用
播放器缓存的实现
想要实现播放器的缓存，有好几种方式：
一. 外接cache库
一般cache库都是针对https做的处理，本质就是一个http代理服务器。当播放的时候，先从cache库中拿到转换后的代理地址，然后设置转换后的地址去播放。这样播放器在播放的时候请求数据，实际就是走到了代理服务器中。此时代理服务器就可以将数据缓存下来。如果下次请求的数据已经缓存过了，就可以直接从代理中返回数据。
这种方式的优点就是：对播放器无缝对接。尤其是对于没有自研播放器能力的时候，这种方式几乎是唯一可行的方式。 缺点的话，无法针对格式做特定的优化，比如HLS.DASH等，有些cache库可能就不支持这些功能。
二. 播放器内部下载数据
对有自研能力的播放器来说，大部分是这种方式。
缓存控制
播放器提供一个控制缓存API。当用户开了缓存之后，播放器则边从网络读数据边记录到磁盘上。下次播放的时候，也从磁盘读取数据。
这种方式的优点就是：完全自主可控。 缺点就是：播放器有些情况下并不适合缓存，比如直播流。缓存下来之后，播放的都是过期的内容，显然是不合理的。多码率流如果缓存，从本地读数据的时候，会影响网速的计算，就会对码率切换造成影响。 针对缺点，播放器可以根据实际的媒体类型，比如直播流，多码率流等做不能缓存的控制。但是这样对播放器的模块有入侵：因为数据读取是网络模块，而媒体的信息在其他模块，造成了不能完全解耦。
利用协议的缓存控制
对于播放器来说，大部分点播流或者部分直播流都是HTTP、HTTPS协议的。而HTTP协议是提供了一套完整的HTTP Cache的缓存控制协议的。所以播放器也是可以通过支持HTTP 的cache control，来实现缓存与否的整个逻辑。
这种方式的优点就是不需要关注媒体信息，只聚焦于http协议的头等信息，就可以知道能否被缓存。这样就能保证模块解耦。 但是这种方式的缺点就是：如果协议没有缓存控制相关的设计，就没有办法处理了。还需要特殊处理。
下载数据的记录方式
播放器请求数据并不像一般的下载数据，播放器请求的时候，会有seek等操作，导致请求的数据位置并不是连续的。所以这里就引发出了一个保存文件的结构设计。
一般来说，有三种方式：
碎片文件
即将位置连续的数据放到一个文件中。如果不连续，则放到另一个文件中。必要时还需要合并两个碎片文件。查找的时候，根据请求数据的位置，找到对应的碎片文件，从而找出需要的数据。 这种方式缺点就是文件较多，操作较多。优点是不需要记录其他的信息。
空洞文件
顾名思义，就是先创建一个跟流大小一样大的文件，占用住空间。然后将请求到的数据按照位置写入到文件中。 这种方式的优点就是：不需要做额外的文件合并操作，也没有文件碎片。缺点就是需要记录文件中，哪些地方有数据，哪些没有数据。同时占用磁盘空间看着好像很大。
碎片连续文件
这种方式就是通过直接追加的方式记录到文件中。 这种方式的优点就是：没有碎片文件，文件大小也是正确的。缺点就是在读取数据的时候，会在文件中来回跳转，处理逻辑要相对复杂一点。