playVoice，success回调延迟！！！ - WXOPEN Club

这是个一直存在的问题，最近又遇到了感觉很麻烦就拿出来提交一下。

playVoice的播放完成回调在模拟器上会马上完成这个众所周知，今天提交的不是这个，

在安卓真机上playVoice的success回调会在播放完成的时候触发，在手机上会听到“嘀”的一声，回调就触发

问题就出在这里，声音已经播完了但是要在过去差不多1秒左右才会“嘀”一声，才会完成success回调触发的函数，

这样就导致在声音播放完成到“嘀”一声之间再点击播放，在新一次播放期间上一次的回调会触发，会“嘀”一声，

如果我们在success上面绑定了停止播放按钮的图标状态，

那么第二次播放开始时把状态图标变成正在播放，

但是上一次的回调会在这一次播放期间触发

导致在这一次播放期间把播放按钮的图标状态变成了停止了。

这个延迟会特别的长有1秒左右，非常好还原，还原率这么高的bug用户体验会很差，有大神有决绝方案吗？

或者方法修改一下这个这么长的延迟时间吧

6 回复

gongyong1 楼6 年前

当然跟1秒延迟有关系，安卓在这个延迟时间内播放另一条才会出现这个问题，而ios不会，但是ios也会马上触发回调，

@maq ，你说的和我要表达的不是一个意思，我的意思是，回调不仅有延迟而且触发的还是第二条音频的success的内容不是第一条的内容。第一次的回调被第二次的覆盖了，第一次回调触发时其实提前把第二次的回调给触发了。

这是api本身存在的bug问题，不是判断是否中断的问题

zjin2 楼6 年前

1l 你的意思是，没有触发回调之前不让用户播放别的音频吗？平时用户用播放软件的习惯就是点哪条播哪条啊

我再测了一下，问题比我上面描述的更加严重，

在安卓上：在这1秒左右之间播放第二次或者播放其他音频，嘀的意思不是触发上一次的回调而是触发本次的回调，应该是success方法被本次播放重写了。

ios上：甚至在这延迟的1秒之前（即第一次音频播放期间），点击播放第二条音频，success回调会马上触发，而且是第二次音频的success回调，导致第二次的播放状态图标马上变成了停止状态。

显然两次播放音频api用的是同一个playVoice事件，在同一个线程里面，而成功的回调也没有区分起来导致了混乱

juan903 楼6 年前

playVoice function(url){

if(this.num&&this.num >0){

this.num++

}else{

this.num = 1

}

var thatNum = this.num；

wx.playVoice({

filePath:url,

success:function(){

console.log(“第”+thatNum +“次”);

}

})

}

可以用这个函数测试一下，可以先录一个音，然后用得到的临时地址试一下

在安卓上，在我说的一秒延迟之内 ,点击播放第二次，播放的期间会听到"嘀"的一声，这时上一次的回调就会触发了，

但是输出的log是“第2次”，而第二个音频播放完，嘀的一声则没有输出log。这就说明上一次的回调内容被覆盖了，而且第二次的回调被提前了。

jing314 楼6 年前

按你说的这种情况，API 的回调的确跟直觉预期不符。

不妨这样试试，把 fail 和 complete 回调也都加上，观察一下会出现什么情况，也许这个 API 对回调的定义本来就是另一个样子呢，呵呵

hwen5 楼6 年前

原来不是“第二次播放”，而是“播放另一个”的意思，明白了。

那这样的话，问题的根源就不在于那 1 秒的空白延迟了，只要是正在播放中，点击启动另一个，都可能会出现问题。

关键是，playVoice 的文档里说，【如果前一个语音文件还没播放完，将中断前一个语音播放】，那么，被中断的那次在回调中能否区分出是【被中断】还是【正常结束】呢？我不知道回调参数是啥样的，如果能区分出来，应该就有办法了。

ryan6 楼5 年前

……只是有一点不明白，既然第一次播放结束的回调还没触发，你怎么会让用户有机会点击开始第二次播放？

另外，有没有这样一种可能，那个音频文件在结尾的地方留了 1 秒钟的空白？这个接口我没有实践经验，只是猜测一种可能性。