操作系统:Windows8.1

显卡:Nivida GTX965M

开发工具:Android studio 2.3.3 | ExoPlayer r2.5.1


使用 ExoPlayer已经有一段时间了,对播放器的整体架构设计 到 具体实现 佩服至极,特别建议开发播放器的同学有机会一定要看看,相信会受益匪浅。这次分享的内容主要关于缓存策略优化。

Default Buffer Policy


Google ExoPlayer提供了默认的AV数据的缓存策略,并通过 DefaultLoadControl 组件实现。该加载器组件本身没有问题,只不过在一些情景下,这种默认缓存策略,会减损"缓存"本身的效果。在 DefaultLoadControl中有如下代码片段:

  @Override  
public boolean shouldContinueLoading(long bufferedDurationUs)
{
...
isBuffering = bufferTimeState == BELOW_LOW_WATERMARK || (bufferTimeState == BETWEEN_WATERMARKS && isBuffering && !targetBufferSizeReached); ...return isBuffering;
}

该函数由于播放器调用,以确定是否应该继续加载缓存AV数据。

/**
* The default minimum duration of media that the player will attempt to ensure is buffered at all
* times, in milliseconds.
*/
public static final int DEFAULT_MIN_BUFFER_MS = 15000; /**
* The default maximum duration of media that the player will attempt to buffer, in milliseconds.
*/
public static final int DEFAULT_MAX_BUFFER_MS = 30000; /**
* The default duration of media that must be buffered for playback to start or resume following a
* user action such as a seek, in milliseconds.
*/
public static final int DEFAULT_BUFFER_FOR_PLAYBACK_MS = 2500; /**
* The default duration of media that must be buffered for playback to resume after a rebuffer,
* in milliseconds. A rebuffer is defined to be caused by buffer depletion rather than a user
* action.
*/
public static final int DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS = 5000;

DEFAULT_MIN_BUFFER_MS  常量定义了播放器触发加载AV数据的时机,即当前缓冲区AV数据 duration time 小于15秒。

DEFAULT_MAX_BUFFER_MS 常量定义了播放器进行加载AV数据的上限,即当前缓冲区AV数据 duration time 小于30秒。

DEFAULT_BUFFER_FOR_PLAYBACK_MS 常量定义了播放器播放AV数据的条件,即缓冲区必须满足AV数据 duration time 不小于2.5秒。

DEFAULT_BUFFER_FOR_PLAYBACK_AFTER_REBUFFER_MS 常量定义了播放器从 REBUFFER状态(REBUFFER是由于运行时缓冲区耗尽触发导致) 恢复为可播放状态后可播放AV数据的条件,即缓冲区必须满足AV数据 duration time 不小于5秒。

所以根据以上代码了解,前两个参数用于描述加载时序,后两个参数用于描述是否有足够的缓冲数据来播放。

我们可以概述默认加载器组件会按照如下方式工作:

  1. 加载组件持续加载,直到缓冲AV数据大于30秒,停止加载,进入等待状态。
  2. 当缓冲AV数据小于15秒时,加载器重新执行加载逻辑。
  3. 播放器根据当前缓冲区AV数据 duration time 控制是否播放。

那么问题来了,这样设计的目的是什么?很难想到一个情景应用该策略,换句话说是否可以自定义修改15秒30秒这样的数值呢?

What about Buffering?


There are arguments that mobile carriers prefer this kind of traffic pattern over their networks (i.e. bursts rather than drip-feeding). Which is an important consideration given ExoPlayer is used by some very popular services. It may also be more battery efficient.

Whether these arguments are still valid is something we should probably take another look at fairly soon, since the information we used when making this decision is 3-4 years old now. We should also figure out whether we should adjust the policy dynamically based on network type (e.g. even if the arguments are still valid, they may only hold for mobile networks and not for WiFi).

关于此问题已经有人问询过,其中一个ExoPlayer开发人员给出这样的答复,大致意为,目前主流移动运营商将作为ExoPlayer的相关实现重要考虑对象,有证据表明运营商们更倾向于这种被称为 bursts 的流量模式,而不是 drip-feeding 类的流量模式。除此之外也会提升电池使用效率。无论这些证据是否有效,很快会再次的了解一下,因为做出这个决定所参考的是3-4年前的信息了。还应该确定是否有必要根据网络类型动态调整策略(即使这些参数仍然使用,它们只适用于移动网络,而不是WiFi)。

尽现在使用的默认缓存策略比较通用,但不可能满足所有的情况。为了更好的点播体验,增加缓冲数据 duration time 为1分钟或者更久,接下来我们进一步分析ExoPlayer默认缓存策略的实现原理,并在最后给出一般性的优化例子。

Water Marks


在默认的缓存策略实现中,有一个 water marks 的概念,类似水桶盛水过程中变化的"水位 ",具体代码为:

  private static final int ABOVE_HIGH_WATERMARK = 0;
private static final int BETWEEN_WATERMARKS = 1;
private static final int BELOW_LOW_WATERMARK = 2;

三个级别的水位与前面提到的四个常量的关系如图所示:

参考完整的 getBufferTimeState() 与 shouldContinueLoad() 函数,其中 getBufferTimeState() 根据当前的缓存AV数据的 duration time 来判断处于哪个水位。

private int getBufferTimeState(long bufferedDurationUs)
{
return bufferedDurationUs > maxBufferUs ? ABOVE_HIGH_WATERMARK
: (bufferedDurationUs < minBufferUs ? BELOW_LOW_WATERMARK : BETWEEN_WATERMARKS);
}
@Override
public boolean shouldContinueLoading(long bufferedDurationUs)
{
int bufferTimeState = getBufferTimeState(bufferedDurationUs);
boolean targetBufferSizeReached = allocator.getTotalBytesAllocated() >= targetBufferSize;
boolean wasBuffering = isBuffering; isBuffering = bufferTimeState == BELOW_LOW_WATERMARK || (bufferTimeState == BETWEEN_WATERMARKS && isBuffering && !targetBufferSizeReached); if (priorityTaskManager != null && isBuffering != wasBuffering)
{
if (isBuffering)
{
priorityTaskManager.add(C.PRIORITY_PLAYBACK);
}
else
{
priorityTaskManager.remove(C.PRIORITY_PLAYBACK);
}
} return isBuffering;
}

一个典型的加载行为经过 A、B、C 三个阶段:

Pass A

起始阶段,加载器开始连续的加载AV数据,一直达到或者超过 maxBufferUs 水位为止,需要注意的是这个时候时间线为停顿在 t1 ,如下图所示:

Pass B

t1 时间后,播放器消费缓冲区AV数据,但 isBuffering = false 并且 bufferTimeState == BETWEEN_WATERMARK,所以 shouldContinueLoading() 仍然返回 false,即不需要加载AV数据,时间线停顿在 t2 ,如下图所示:

Pass C

来到最后一个阶段,当播放器持续消费缓冲区AV数据,直到水位低于 minBufferUs ,即 bufferTimeState == BELOW_LOW_WATERMARK 时候,我们恢复加载程序,时间线停顿在 t3 ,如下图所示:

作为一个小节,通过三个阶段的图示我们了解到,从 t1t3 之间区间内,加载器没有做任何加载操作。因此会遇到这种情景,某时刻缓冲区中只有仅仅15秒的缓冲数据。

除此之外,对于缓冲区大小也是有限制的,一般来说当网络状况良好时,一般都可以缓存 15 到 30 秒的AV数据,换句话说,有可能根据需求扩展缓冲区大小。

How to customize the buffer?


应用前面提到的 drip - feeding 滴灌方式,移除缓冲区的上线限制,代码如下:

isBuffering = bufferTimeState == BELOW_LOW_WATERMARK
|| (bufferTimeState == BETWEEN_WATERMARKS
/*
* commented below line to achieve drip-feeding method for better caching. once you are below maxBufferUs, do fetch immediately.
*/
/* && isBuffering */
&& !targetBufferSizeReached);

同时扩大 maxBufferUsminBufferUs

/**
* To increase buffer time and size.
*/
public static int BUFFER_SCALE_UP_FACTOR = 4;
....
minBufferUs = BUFFER_SCALE_UP_FACTOR * minBufferMs * 1000L;
maxBufferUs = BUFFER_SCALE_UP_FACTOR * maxBufferMs * 1000L;
...

可以在 shouldContinueLoading() 函数下面添加日志,验证修改前后的不同表现。

Log.d(CustomLoadControl.class.getSimpleName(), "current buffer durationUs: " + bufferedDurationUs + ",max bufferUs: " + maxBufferUs + ", min bufferUs: " + minBufferUs + " shouldContinueLoading: " + isBuffering);

修改之前的LOG如下,可以观测到只有第一次水位达到 maxBufferUs ,之后的缓存策略一直维持在 minBufferUs

D/DefaultLoadControl:    current    buffer    durationUs:    0,max    bufferUs:    30000000,    min    bufferUs:    15000000    shouldContinueLoading:    TRUE
D/DefaultLoadControl: current buffer durationUs: 981333,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: TRUE
D/DefaultLoadControl: current buffer durationUs: 2154666,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: TRUE
D/DefaultLoadControl: current buffer durationUs: 3136000,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: TRUE
...
D/DefaultLoadControl: current buffer durationUs: 15160125,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: TRUE
D/DefaultLoadControl: current buffer durationUs: 15973479,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 15973479,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 15963667,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
...
D/DefaultLoadControl: current buffer durationUs: 15003688,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 14993604,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: TRUE
D/DefaultLoadControl: current buffer durationUs: 15975896,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 15975896,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 15964834,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
...
D/DefaultLoadControl: current buffer durationUs: 15005417,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 14994542,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: TRUE
D/DefaultLoadControl: current buffer durationUs: 15891750,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 15891750,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 15880042,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
...
D/DefaultLoadControl: current buffer durationUs: 15003708,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 14992667,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: TRUE
D/DefaultLoadControl: current buffer durationUs: 15601000,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 15601000,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 15588708,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
...
D/DefaultLoadControl: current buffer durationUs: 15004458,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE
D/DefaultLoadControl: current buffer durationUs: 14993416,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: TRUE
D/DefaultLoadControl: current buffer durationUs: 16081313,max bufferUs: 30000000, min bufferUs: 15000000 shouldContinueLoading: FALSE

修改之后,缓冲区扩大,持续加载,维持在 maxBufferUs

D/CustomControl:    current    buffer    durationUs:          0,max bufferUs:120000000,    min    bufferUs:60000000    shouldContinueLoading:    TRUE
D/CustomControl: current buffer durationUs: 981333,max bufferUs:120000000, min bufferUs:60000000 shouldContinueLoading: TRUE
D/CustomControl: current buffer durationUs: 2154666,max bufferUs:120000000, min bufferUs:60000000 shouldContinueLoading: TRUE
...
D/CustomControl: current buffer durationUs: 53194146,max bufferUs:120000000, min bufferUs:60000000 shouldContinueLoading: TRUE
D/CustomControl: current buffer durationUs: 54319750,max bufferUs:120000000, min bufferUs:60000000 shouldContinueLoading: TRUE
D/CustomControl: current buffer durationUs: 55313834,max bufferUs:120000000, min bufferUs:60000000 shouldContinueLoading: TRUE

Ok,本次分享的内容就到这里了,以上内容如有不对之处,请多多指正。

ExoPlayer Talk 01 缓存策略分析与优化的更多相关文章

  1. iOS网络加载图片缓存策略之ASIDownloadCache缓存优化

    iOS网络加载图片缓存策略之ASIDownloadCache缓存优化   在我们实际工程中,很多情况需要从网络上加载图片,然后将图片在imageview中显示出来,但每次都要从网络上请求,会严重影响用 ...

  2. 详解服务器性能测试的全生命周期?——从测试、结果分析到优化策略(转载)

    服务器性能测试是一项非常重要而且必要的工作,本文是作者Micheal在对服务器进行性能测试的过程中不断摸索出来的一些实用策略,通过定位问题,分析原因以及解决问题,实现对服务器进行更有针对性的优化,提升 ...

  3. tomcat压缩优化和缓存策略

    tomcat压缩内容 tomcat的压缩优化就是将返回的html页面等内容经过压缩,压缩成gzip格式之后.发送给浏览器,浏览器在本地解压缩的过程. 对于页面量信息大或者带宽小的情况下用压缩方式还是蛮 ...

  4. Universal-Image-Loader源码分析,及常用的缓存策略

    讲到图片请求,主要涉及到网络请求,内存缓存,硬盘缓存等原理和4大引用的问题,概括起来主要有以下几个内容: 原理示意图 主体有三个,分别是UI,缓存模块和数据源(网络).它们之间的关系如下: ① UI: ...

  5. okhttp缓存策略源码分析:put&get方法

    对于OkHttp的缓存策略其实就是在下一次请求的时候能节省更加的时间,从而可以更快的展示出数据,那在Okhttp如何使用缓存呢?其实很简单,如下: 配置一个Cache既可,其中接收两个参数:一个是缓存 ...

  6. 【腾讯Bugly干货分享】彻底弄懂 Http 缓存机制 - 基于缓存策略三要素分解法

    本文来自于腾讯Bugly公众号(weixinBugly),未经作者同意,请勿转载,原文地址:https://mp.weixin.qq.com/s/qOMO0LIdA47j3RjhbCWUEQ 作者:李 ...

  7. Http协议:彻底弄懂 Http 缓存机制 - 基于缓存策略三要素分解法

    转载:http://mp.weixin.qq.com/s/uWPls0qrqJKHkHfNLmaenQ 导语 Http 缓存机制作为 web 性能优化的重要手段,对从事 Web 开发的小伙伴们来说是必 ...

  8. 高性能Linux服务器 第10章 基于Linux服务器的性能分析与优化

    高性能Linux服务器 第10章    基于Linux服务器的性能分析与优化 作为一名Linux系统管理员,最主要的工作是优化系统配置,使应用在系统上以最优的状态运行.但硬件问题.软件问题.网络环境等 ...

  9. 【转载】HTTP 缓存的四种风味与缓存策略

    原文地址:https://segmentfault.com/a/1190000006689795 HTTP Cache 通过网络获取内容既缓慢,成本又高:大的响应需要在客户端和服务器之间进行多次往返通 ...

随机推荐

  1. 为Dynamics 365写一个简单程序实现解决方案一键迁移

    关注本人微信和易信公众号: 微软动态CRM专家罗勇 ,回复258或者20170627可方便获取本文,同时可以在第一间得到我发布的最新的博文信息,follow me!我的网站是 www.luoyong. ...

  2. Java纸牌小demo以及日历小demo

    //卡牌类 public class Card { //定义卡牌的点数 public static final String[] cardName = { "3", "4 ...

  3. Adobe系列软件下载地址

    在前些上传的文章中已经讲了如何激活Adobe系列软件,在这放上Adobe系列软件下载地址: 1.Adobe After Effects 2017-14.0 32位下载地址: 链接:http://pan ...

  4. OCP 11G 实验环境安装文档 ( RedHat5.5 + Oracle11g )

    RedHat5.5 linux下Oracle11g软件安装 一.配置虚拟机 为了创建和配置虚拟机,你需要添加硬件设备如磁盘和cpu,在你开始安装之前,创建一个windows目录作为存放虚拟机的目录 目 ...

  5. Phpcms安装前后域名默认访问路径

    一.安装前 phpcms下载后index.html文件内容如下图,在本地服务器配置项目虚拟域名后,访问域名后直接跳到:域名/install/install.php,然后出现安装界面. 二.安装之后 提 ...

  6. webgl开发第一道坎——矩阵与坐标变换

    一.齐次坐标 在3D世界中表示一个点的方式是:(x, y, z);然而在3D世界中表示一个向量的方式也是:(x, y, z);如果我们只给一个三元组(x, y, z)鬼知道这是向量还是点,毕竟点与向量 ...

  7. log4j(一)——为什么要用log4j?

    一:试验环境 OS:win7 JDK:jdk7 Log4j:1.2.17(好尴尬,原本是想试验下log4j2的,结果阴差阳错用了这个版本,不过幸好,试验也不白试验,试验的作用是一样的) 二:先看两个简 ...

  8. Objective-C 自定义UISlider滑杆 分段样式

    效果 自定义一个功能简单的分段的滑杆 可显示分段名 为了显示效果,我们将滑块和节点都设置为不规则 这里只实现了分段的slider,未分段的没有实现,有兴趣的可以定义另一种类型做个判断修改下 需求分析 ...

  9. post提交数据长度限制问题

    最近做手机拍照照片上传时,由于图片较大,base64后字符串长度太长,所以提交失败. 修改Tomcat服务器的maxPostSize=0,解决完成! <Connector connectionT ...

  10. ORACLE - 用户和角色的权限管理

    在ORACLE中,创建用户后需要授权才能使用. 一.用户管理 1. 用户和角色信息查询 --查询所有用户 SQL> select * from dba_users; --经授予的用户或角色的系统 ...