请教一下各位音频大佬，同一个音频如何实现第一次播放正常，重复播放卡顿呢？

[opp]

我开发了一个小程序，收到用户反馈，同一个音频，第一次播放正常，再次播放就卡顿，再播放其他音频又正常，但一旦播放第二次，就卡顿。都是来自安卓机型的反馈。

已经在小程序开发社区反馈，一直没解决，社区已有多例反馈。想请教一下这样的特性是如何优化出来的呢？

现在想到的解决方案，是每次播放同一个音频时，给 url 加随机参数，从 1 加到 10 ，最多允许用户重复播放 10 次（用户流量和我的 CDN 流量都在滴🩸）。

[okakuyang]

下载下来播放

[jnliyan1]

回源播放看看能否复现，是不是 cdn 问题

[dyexlzc]

我猜可能是底层播放组件 buffer 清理相关问题，没正确清理，导致第二次播放会有问题，试试看其他办法播放吧

[MozzieW]

看一下系统资源占用？猜测播放器资源没有正确释放

[opp]

@okakuyang 没用的，怀疑小程序底层用资源 URL 作为 key 做了什么处理，之前一直没问题，三月份开始有用户反馈，同一 URL 二次播放必卡。

[opp]

@jnliyan1 跟 cdn 没关，其他开发者也反馈同样问题。

[opp]

@dyexlzc 猜是以音频 URL 作为 key 。现在只能给 URL 加参数，用户和我的流量者白花。

[opp]

@MozzieW 但播放 URL 变化就没问题了，即使是同一音频，加上参数就正常。

[MozzieW]

@opp #8 你把复现代码抽出来，给人看能解决的几率大一点。不然只能猜。
卡顿这问题，我能想到的至少分两种，来不及播放、播放太快把内容丢了。比如正常 播放 12345 ，
可能是：1245 ，也可能是 12___3__45 （下划线表示停顿）。
去做一个音频解码+播放的落就懂了。解码太快了，解码后马上给播放器同时丢掉之前没有播放的音频，就会出现 1245. 音频播放器一般要等，但可能有些情况的确要去掉来不及播放的内容的（比如游戏模拟器）。
来不及解码，播放后要等，就会出现 12___3__45 。

具体情况有很多可能，比如在线音频网络卡顿，容易出现 12___3__45 。

不管怎么样，从系统资源能看到内存、CPU 异常，找到排查的方向。