在古尔冈，那是一个寒冷多雾的夜晚。 来自Wynk团队的一群人在谈论印度娱乐消费者正在经历的转变。 大多数都从传统的下载/购买和播放模式转变为新时代的流媒体模型。
为了使用户从下载/购买过渡到流媒体，并鼓励他们的朋友效仿，流媒体模型必须同样受到信任。 这提出了一项重大挑战。 虽然流媒体为用户提供了范围更广的音乐选项，但该用户还受他们可用的互联网带宽的支配。
我们的讨论提出了两个主要想法：
- 流内容需要与下载的内容一样快地运行，以便用户获得即时满足。
- 用户体验不应因互联网带宽可用性的变化而波动。
当我们大多数人第二天忘记了这次对话时，我和Ankit决定接受这一挑战。 第二天我们再次见面，并在白板上写下了问题。 我们认为我们想要影响的最重要的指标是：
单击播放时间或CTP（当有人在Wynk App中按播放时播放音乐所花费的时间）
我们很快就赶上了CTO Sudipta。 他建议，与其尝试解决所有媒体流的问题，不如先解决重复播放的问题（歌曲第一次不播放）。 完全有意义，因为此类歌曲占Wynk播放的歌曲的35％。
作为优秀的工程师，我们问自己当前的指标是什么样的。 大多数用户（75％）的CTP 平均为10秒。 尽管这看起来并不多，但每毫秒减少的时间可能会破坏用户体验。 我们为自己设定了将这个数字减少3倍的大胆目标。
关于Wynk音乐流的一些知识
在过去，流式传输mp3 / mp4文件意味着将其完全下载并在用户设备上播放。 幸运的是，我们已经超越了石器时代。 Wynk的流媒体使用了Apple率先使用的HLS协议，并由Google烘焙到了开源Exoplayer的一个分支版本中。 它的工作方式是将每首歌曲分解为：
- 1个主文件（包含指向不同比特率文件的URL）
- 索引文件（包含指向10秒段的URL）
- 10秒段文件。
回到大胆的目标
为了将CTP降低3倍，我们分析了整个播放周期，并列出了可能影响CTP的各个方面。
我们处理的第一件事是在开始播放歌曲时进行的API调用。 通常，每次播放至少需要4个API调用。第一个要获取经过身份验证的主URL。 第二个获取实际的主文件。 第三个获取正确的索引文件（由带宽确定），第四个获取第一个段文件。 但是，我们意识到，对于先前播放的文件，如果我们在用户的缓存中已经有了主文件和索引文件，则可以排除前两个调用。 这将意味着即时回放🙂通过使用这种方法，我们能够修改代码以使用本地数据（如果数据存在于用户的缓存中）而不是API调用。
为了使上述更改显示其真正的潜力，我们还必须改善缓存。 这使我们获得了第二项改进，即缓存。
缓存
LRU（最近最少使用）缓存是一种缓存替换算法，可清除最近最少使用（触摸）的文件的缓存。 我们的原始LRU缓存的简化版本是这样工作的。
当缓存已满并且我们必须在其中存储新歌曲时，我们只是删除了最早接触的文件（包括主文件/索引文件以及所有段）。 这意味着在任何时间点只能立即播放少量歌曲。
我们必须修改LRU缓存，以便能够即时开始播放尽可能多的歌曲。 因此，我们优化了LRU缓存，以优先处理主文件/索引文件和第一段文件。
这意味着现在当缓存溢出时，我们没有删除整个歌曲，而是仅删除了第四段。 这允许更多歌曲立即开始播放，并继续通过流播放。
比较原始LRU缓存和V2 LRU缓存，我们可以看到现在可以立即播放更多歌曲。
即使进行了这些修改，我们仍意识到有些用户面临着较长的CTP时间。 经过仔细检查，我们发现这几乎总是发生在流音乐时带宽突然变化的用户身上。 我们进一步调查发现，由于带宽的变化，Wynk播放器正在向服务器请求更高质量的流（让我们说320kbps），同时使用户等待，即使缓存中存在质量较低的流（比如说128）。 kbps）。 我们迅速进行了更改，以允许播放器退回到较低质量的流上并继续播放，同时一路获取较高质量的流，并在可用时立即切换到较高质量。
上述变化的结合使CTP时间从10秒减少到2.8秒 -我们实现了将时间减少3倍的大胆目标！ 我们的用户现在以低等待时间欣赏了超过50亿首歌曲，这得益于当晚的即兴讨论，以及我们工程部门领导层的信任，即即使影响到我们产品的核心，团队中的任何人都可以提出并执行以用户为中心的想法。
