这是个一直存在的问题,最近又遇到了感觉很麻烦就拿出来提交一下。
playVoice的播放完成回调在模拟器上会马上完成这个众所周知,今天提交的不是这个,
在安卓真机上playVoice的success回调会在播放完成的时候触发,在手机上会听到“嘀”的一声,回调就触发
问题就出在这里,声音已经播完了但是要在过去差不多1秒左右才会“嘀”一声,才会完成success回调触发的函数,
这样就导致在声音播放完成到“嘀”一声之间再点击播放,在新一次播放期间上一次的回调会触发,会“嘀”一声,
如果我们在success上面绑定了停止播放按钮的图标状态,
那么第二次播放开始时把状态图标变成正在播放,
但是上一次的回调会在这一次播放期间触发
导致在这一次播放期间把播放按钮的图标状态变成了停止了。
这个延迟会特别的长有1秒左右,非常好还原,还原率这么高的bug用户体验会很差,有大神有决绝方案吗?
或者方法修改一下这个这么长的延迟时间吧
当然跟1秒延迟有关系,安卓在这个延迟时间内播放另一条才会出现这个问题,而ios不会,但是ios也会马上触发回调,
@maq ,你说的和我要表达的不是一个意思,我的意思是,回调不仅有延迟而且触发的还是第二条音频的success的内容不是第一条的内容。第一次的回调被第二次的覆盖了,第一次回调触发时其实提前把第二次的回调给触发了。
这是api本身存在的bug问题,不是判断是否中断的问题
1l 你的意思是,没有触发回调之前不让用户播放别的音频吗?平时用户用播放软件的习惯就是点哪条播哪条啊
我再测了一下,问题比我上面描述的更加严重,
在安卓上:在这1秒左右之间播放第二次或者播放其他音频,嘀的意思不是触发上一次的回调而是触发本次的回调,应该是success方法被本次播放重写了。
ios上:甚至在这延迟的1秒之前(即第一次音频播放期间),点击播放第二条音频,success回调会马上触发,而且是第二次音频的success回调,导致第二次的播放状态图标马上变成了停止状态。
显然两次播放音频api用的是同一个playVoice事件,在同一个线程里面,而成功的回调也没有区分起来导致了混乱
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。这就说明上一次的回调内容被覆盖了,而且第二次的回调被提前了。