这是一个创建于 189 天前的主题，其中的信息可能已经有所发展或是发生改变。
我开发了一个小程序，收到用户反馈，同一个音频，第一次播放正常，再次播放就卡顿，再播放其他音频又正常，但一旦播放第二次，就卡顿。都是来自安卓机型的反馈。
已经在小程序开发社区反馈，一直没解决，社区已有多例反馈。想请教一下这样的特性是如何优化出来的呢？
现在想到的解决方案，是每次播放同一个音频时，给 url 加随机参数，从 1 加到 10 ，最多允许用户重复播放 10 次（用户流量和我的 CDN 流量都在滴）。
 | 1 okakuyang 2025 年 7 月 27 日  1 下载下来播放 |
 | 2 jnliyan1 2025 年 7 月 28 日 1 回源播放看看能否复现，是不是 cdn 问题 |
 | 3 dyexlzc 2025 年 7 月 28 日 1 我猜可能是底层播放组件 buffer 清理相关问题，没正确清理，导致第二次播放会有问题，试试看其他办法播放吧 |
 | 4 MozzieW 2025 年 7 月 28 日 1 看一下系统资源占用？猜测播放器资源没有正确释放 |
 | 5 opp OP @okakuyang 没用的，怀疑小程序底层用资源 URL 作为 key 做了什么处理，之前一直没问题，三月份开始有用户反馈，同一 URL 二次播放必卡。 |
| 9 MozzieW 2025 年 7 月 28 日 @opp #8 你把复现代码抽出来，给人看能解决的几率大一点。不然只能猜。 卡顿这问题，我能想到的至少分两种，来不及播放、播放太快把内容丢了。比如正常 播放 12345 ， 可能是：1245 ，也可能是 12___3__45 （下划线表示停顿）。 去做一个音频解码+播放的落就懂了。解码太快了，解码后马上给播放器同时丢掉之前没有播放的音频，就会出现 1245. 音频播放器一般要等，但可能有些情况的确要去掉来不及播放的内容的（比如游戏模拟器）。 来不及解码，播放后要等，就会出现 12___3__45 。 具体情况有很多可能，比如在线音频网络卡顿，容易出现 12___3__45 。 不管怎么样，从系统资源能看到内存、CPU 异常，找到排查的方向。 |
Select Language