playVoice,success回调延迟!!!
发布于 6 年前 作者 liangyan 14118 次浏览 来自 问答

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

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

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

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

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

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

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

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

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

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

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

6 回复

当然跟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。这就说明上一次的回调内容被覆盖了,而且第二次的回调被提前了。

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

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

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

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

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

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

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

回到顶部