这是个一直存在的问题，最近又遇到了感觉很麻烦就拿出来提交一下。
playVoice的播放完成回调在模拟器上会马上完成这个众所周知，今天提交的不是这个，
在安卓真机上playVoice的success回调会在播放完成的时候触发，在手机上会听到“嘀”的一声，回调就触发
问题就出在这里，声音已经播完了但是要在过去差不多1秒左右才会“嘀”一声，才会完成success回调触发的函数，
这样就导致在声音播放完成到“嘀”一声之间再点击播放，在新一次播放期间上一次的回调会触发，会“嘀”一声，
如果我们在success上面绑定了停止播放按钮的图标状态，
那么第二次播放开始时把状态图标变成正在播放，
但是上一次的回调会在这一次播放期间触发
导致在这一次播放期间把播放按钮的图标状态变成了停止了。
这个延迟会特别的长有1秒左右，非常好还原，还原率这么高的bug用户体验会很差，有大神有决绝方案吗？
或者方法修改一下这个这么长的延迟时间吧
按你说的这种情况，API 的回调的确跟直觉预期不符。
不妨这样试试，把 fail 和 complete 回调也都加上，观察一下会出现什么情况，也许这个 API 对回调的定义本来就是另一个样子呢，呵呵
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。这就说明上一次的回调内容被覆盖了，而且第二次的回调被提前了。
当然跟1秒延迟有关系，安卓在这个延迟时间内播放另一条才会出现这个问题，而ios不会，但是ios也会马上触发回调，
@maq ，你说的和我要表达的不是一个意思，我的意思是，回调不仅有延迟而且触发的还是第二条音频的success的内容不是第一条的内容。第一次的回调被第二次的覆盖了，第一次回调触发时其实提前把第二次的回调给触发了。
这是api本身存在的bug问题，不是判断是否中断的问题
原来不是“第二次播放”，而是“播放另一个”的意思，明白了。
那这样的话，问题的根源就不在于那 1 秒的空白延迟了，只要是正在播放中，点击启动另一个，都可能会出现问题。
关键是，playVoice 的文档里说，【如果前一个语音文件还没播放完，将中断前一个语音播放】，那么，被中断的那次在回调中能否区分出是【被中断】还是【正常结束】呢？我不知道回调参数是啥样的，如果能区分出来，应该就有办法了。
1l 你的意思是，没有触发回调之前不让用户播放别的音频吗？平时用户用播放软件的习惯就是点哪条播哪条啊
我再测了一下，问题比我上面描述的更加严重，
在安卓上：在这1秒左右之间播放第二次或者播放其他音频，嘀的意思不是触发上一次的回调而是触发本次的回调，应该是success方法被本次播放重写了。
ios上：甚至在这延迟的1秒之前（即第一次音频播放期间），点击播放第二条音频，success回调会马上触发，而且是第二次音频的success回调，导致第二次的播放状态图标马上变成了停止状态。
显然两次播放音频api用的是同一个playVoice事件，在同一个线程里面，而成功的回调也没有区分起来导致了混乱
……只是有一点不明白，既然第一次播放结束的回调还没触发，你怎么会让用户有机会点击开始第二次播放？
另外，有没有这样一种可能，那个音频文件在结尾的地方留了 1 秒钟的空白？这个接口我没有实践经验，只是猜测一种可能性。