操作系统: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秒。
所以根据以上代码了解，前两个参数用于描述加载时序，后两个参数用于描述是否有足够的缓冲数据来播放。
我们可以概述默认加载器组件会按照如下方式工作：
- 加载组件持续加载，直到缓冲AV数据大于30秒，停止加载，进入等待状态。
- 当缓冲AV数据小于15秒时，加载器重新执行加载逻辑。
- 播放器根据当前缓冲区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 ，如下图所示：
作为一个小节，通过三个阶段的图示我们了解到，从 t1 到 t3 之间区间内，加载器没有做任何加载操作。因此会遇到这种情景，某时刻缓冲区中只有仅仅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);
同时扩大 maxBufferUs 和 minBufferUs 。
/**
* 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，本次分享的内容就到这里了，以上内容如有不对之处，请多多指正。