关于Vue中nextTick异步调用video&audio的方法失效解决方案

最新推荐文章于 2024-06-20 16:28:03 发布

mpr0xy

最新推荐文章于 2024-06-20 16:28:03 发布

阅读量2.5k

点赞数

文章标签： vue audio video

原文链接：https://qq282126990.github.io/2018/02/10/

版权

原文地址：https://qq282126990.github.io/2018/02/10/

nextTick
JS的运行机制：JS执行是单线程的,它是基于事件循环的对于事件循环的理解大致分为以下几个步骤：

所有同步任务都在主线程上执行,形成一个执行栈。
主线程以外,还存在一个“任务队列”。只要异步任务有了运行结果,就在“任务队列”之中放置一个事件。
一旦”执行栈”中的所有同步任务执行完毕,系统就会读取“任务队列”,看看里面有哪些事件对应的那些异步任务, 结束等待,进入执行栈,开始执行。
主线程不断重复上面的第三步。

主线程的执行过程就是一个tick,而所有的异步结果都是通过“任务队列”来调度被调度。消息队列中存放的是一个个的任务(task)。规范中规定 task 分为两大类，分别是 macro task 和 micro task，并且每个 macro task 结束后，都要清空所有的 micro task。

简单通过一段代码演示他们的执行顺序：

for (macroTask of macroTaskQueue) {
    // 1. Handle current MACRO-TASK
    handleMacroTask();
      
    // 2. Handle all MICRO-TASK
    for (microTask of microTaskQueue) {
        handleMicroTask(microTask);
    }
}

在浏览器环境中，常见的 macro task 有 setTimeout、MessageChannel、postMessage、setImmediate；常见的 micro task 有 MutationObsever 和 Promise.then。

回到Vue的nextTick,nextTick其实就是下一个tick,Vue内部实现了nextTick,并把它作为一个全局API暴露出来,它支持传入一个回调函数,保证回调函数的执行时机就是下一个tick。

官网文档介绍了Vue.nextTick 的使用场景：

使用：在下次DOM更新循环结束之后执行延迟回调,在修改数据之后立即只用这个方法,获取更新后的DOM

在vue里是数据驱动视图变化,由于JS执行是单线程的,在一个tick的过程中,它可能会多次修改数据,但Vue并不会傻到每修改一次数据就去驱动一次视图变化,它会把这个数据的修改全部push到一个队列里,然后内部调用一个nextTick去更新视图,所以数据到DOM视图的变化是需要在下一个tick才能完成。

接下来,我们来看一下Vue的nextTick的实现,在Vue.js 2.5+的版本,抽出来一个单独的next-tick.js 文件去实现它。

/* @flow */
/* globals MessageChannel */

import { noop } from 'shared/util'
import { handleError } from './error'
import { isIOS, isNative } from './env'

const callbacks = []
let pending = false

function flushCallbacks () {
  pending = false
  const copies = callbacks.slice(0)
  callbacks.length = 0
  for (let i = 0; i < copies.length; i++) {
    copies[i]()
  }
}

// Here we have async deferring wrappers using both microtasks and (macro) tasks.
// In < 2.4 we used microtasks everywhere, but there are some scenarios where
// microtasks have too high a priority and fire in between supposedly
// sequential events (e.g. #4521, #6690) or even between bubbling of the same
// event (#6566). However, using (macro) tasks everywhere also has subtle problems
// when state is changed right before repaint (e.g. #6813, out-in transitions).
// Here we use microtask by default, but expose a way to force (macro) task when
// needed (e.g. in event handlers attached by v-on).
let microTimerFunc
let macroTimerFunc
let useMacroTask = false

// Determine (macro) task defer implementation.
// Technically setImmediate should be the ideal choice, but it's only available
// in IE. The only polyfill that consistently queues the callback after all DOM
// events triggered in the same loop is by using MessageChannel.
/* istanbul ignore if */
if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) {
  macroTimerFunc = () => {
    setImmediate(flushCallbacks)
  }
} else if (typeof MessageChannel !== 'undefined' && (
  isNative(MessageChannel) ||
  // PhantomJS
  MessageChannel.toString() === '[object MessageChannelConstructor]'
)) {
  const channel = new MessageChannel()
  const port = channel.port2
  channel.port1.onmessage = flushCallbacks
  macroTimerFunc = () => {
    port.postMessage(1)
  }
} else {
  /* istanbul ignore next */
  macroTimerFunc = () => {
    setTimeout(flushCallbacks, 0)
  }
}

// Determine microtask defer implementation.
/* istanbul ignore next, $flow-disable-line */
if (typeof Promise !== 'undefined' && isNative(Promise)) {
  const p = Promise.resolve()
  microTimerFunc = () => {
    p.then(flushCallbacks)
    // in problematic UIWebViews, Promise.then doesn't completely break, but
    // it can get stuck in a weird state where callbacks are pushed into the
    // microtask queue but the queue isn't being flushed, until the browser
    // needs to do some other work, e.g. handle a timer. Therefore we can
    // "force" the microtask queue to be flushed by adding an empty timer.
    if (isIOS) setTimeout(noop)
  }
} else {
  // fallback to macro
  microTimerFunc = macroTimerFunc
}

/**
 * Wrap a function so that if any code inside triggers state change,
 * the changes are queued using a (macro) task instead of a microtask.
 */
export function withMacroTask (fn: Function): Function {
  return fn._withTask || (fn._withTask = function () {
    useMacroTask = true
    const res = fn.apply(null, arguments)
    useMacroTask = false
    return res
  })
}

export function nextTick (cb?: Function, ctx?: Object) {
  let _resolve
  callbacks.push(() => {
    if (cb) {
      try {
        cb.call(ctx)
      } catch (e) {
        handleError(e, ctx, 'nextTick')
      }
    } else if (_resolve) {
      _resolve(ctx)
    }
  })
  if (!pending) {
    pending = true
    if (useMacroTask) {
      macroTimerFunc()
    } else {
      microTimerFunc()
    }
  }
  // $flow-disable-line
  if (!cb && typeof Promise !== 'undefined') {
    return new Promise(resolve => {
      _resolve = resolve
    })
  }
}

在Vue 2.4之前的版本,nextTick几乎都是基于micro task 实现的,但由于micro task的执行优先级非常高,在某些场景下他甚至要比事件冒泡还要快,就会导致一些诡异的问题。如 issue #4521、#6690、#6566；但是如果全部都改成 macro task,对一些有重绘和动画的场景也会有性能影响,如 issue #6813。所以最终nextTick采取的策略是默认走micro task,对于一些DOM交互事件,如v-on绑定的事件回调的处理,会强制走macro task。

这个强制是怎么做的呢，原来在 Vue.js 在绑定 DOM 事件的时候，默认会给回调的 handler 函数调用 withMacroTask 方法做一层包装，它保证整个回调函数执行过程中，遇到数据状态的改变，这些改变都会被推到 macro task 中。

对于macro task的执行,Vue优先检测是否支持元素 setImmediate,这是一个高版本IE和Edge才支持的特征,不支持的话再去检测是否支持原生的 MessageChannel,如果也不支持的话就降级为 setTimeout。

nextTick对video&audio播放的影响

回到我们问题,移动端APP下和安卓&ios浏览器不能播放。先来看一下播放功能实现与方法。

我们的代码中会有一个播放器组件play.vue这个组件中会有一个HTML5的audio标签。由于可调用的地方有很多,比如歌曲组件、榜单组件、等等,因此我们用vuex对播放器的相关数据进行管理。我们把正在播放的列表playlist和当前播放索引currentIndex用state维护,当前播放的歌曲currentSong通过它们计算得到：

// state.js
const state = {
  playlist: [],
  currentIndex:0
}
// getters.js
export const currentSong = (state) => {
  return state.playlist[state.currentIndex] || {}
}

然后我们在 player.vue 组件里 watch currentSong 的变化去播放歌曲：

// player.vue
watch : {
   currentSong(newSong,oldSong) {
      if (!newSong.id || !newSong.url || newSong.id === oldSong.id) {
          return
       }
       this.$refs.audio.src = newSong.url
       this.$refs.audio.play()
   }
}

这样我们就可以在任何组件中提交对 playlist 和 currentIndex 的修改来达到播放不同歌曲的目的。那么这么写和 nextTick 有什么关系呢？

因为在 Vue.js 中，watcher 的回调函数执行默认是异步的，当我们提交对 playlist 或者 currenIndex 的修改，都会触发 currentSong 的变化，但是由于是异步，并不会立刻执行 watcher 的回调函数，而会在 nextTick 后执行。所以当我们点击歌曲列表中的歌曲后，在 click 的事件回调函数中会提交对 playlist 和 currentIndex 的修改，经过一系列同步的逻辑执行，最终是在 nextTick 后才会执行 wathcer 的回调，也就是调用 audio 的 play。

所以本质上，就是用户点击到 audio 的 play 并不是在一个 tick 中完成，并且前面提到 Vue.js 中对 v-on 绑定事件执行的 nextTick 过程会强制使用 macro task。那么到底是不是由于 nextTick 影响了 audio 在 iOS 微信浏览器中的播放呢。

我们就来把化繁为简，写一个简单 demo 来验证这个问题，用的 Vue.js 版本是 2.5+ 的。

<template>
 <div id="app">
  <audio ref="audio"></audio>
    <button @click="changeUrl">click me</button>
  </div>
</template>

<script>
  const musicList = [
  'http://dl.stream.qqmusic.qq.com/C4000041FwTv0Ai3Ku.m4a?vkey=EC7785A072C4BF592AF63FDD72CEDD8CD19AA3EA558A7AAD2D70A5CA8773D36F494F3F4D125AE3610BEE57152F2133E139F7886A00E78ABC&guid=7718257440&uin=282126990&fromtag=66',
  'http://dl.stream.qqmusic.qq.com/C4000035fuK83mjCoC.m4a?vkey=0CF2F6B3A108032BE192BB97935DB72B095BB1FD4B816527008A63E8074314608F3E692E0522352949BA789C2FCCE3D00CD59B72FB50A8EC&guid=7718257440&uin=282126990&fromtag=66',
  'http://dl.stream.qqmusic.qq.com/C400002XFAaU2gfRfV.m4a?vkey=4A79C0FF9883169C2C8B340E2EF6D35CFF471072E1A5D40F84E21D1BC16163B81F84A9C4EDF1960539EE255280C5BF4978E15240770E5C5D&guid=7718257440&uin=282126990&fromtag=66'
  ];

export default {
 data() {
   return {
     index: 0,
     url: ''
   };
 },
 methods: {
   changeUrl() {
     this.index = (this.index + 1) % musicList.length;
     this.url = musicList[this.index];
   }
 },
 watch: {
   url(newUrl) {
     this.$refs.audio.src = newUrl;
     this.$refs.audio.play();
   }
 }
};
</script>

这段代码的逻辑非常简单，我们会添加一个 watcher 监听 url 变化，当点击按钮的时候，会调用 changeUrl 方法，修改 url，然后 watcher 的回调函数执行，并调用 audio 的 play 方法。这段代码在 PC 浏览器是可以正常播放歌曲的，但是移动端APP下和安卓&ios浏览器不能播放,这就证实了我们之前的猜想——在用户点击事件的回调函数到 audio 的播放如果经历了 nextTick(v-on里面会自动执行nextTick) 在 iOS 微信浏览器下不能播放。

macro task 的锅？

经过上面我们可能会认为浏览器应该需要在同一个 tick 才能执行，果真需要这样吗？我们把上述代码做一个简单的修改：

changeUrl() {
  this.index = (this.index + 1) % musicList.length
  this.url = musicList[this.index]
  
  setTimeout(()=>{
    this.$refs.audio.src = this.url
    this.$refs.audio.play()
  }, 0)
}

我们现在不利用 Vue.js 的 nextTick 了，直接来模拟 nextTick 的过程，发现使用 setTimeout 0 是可以在 iOS 微信浏览器器、包括 iOS safari 下播放的，然而实际上我们只要在 1000ms 内的延时时间播放都是可以的，但是超过 1000ms，比如 setTimeout 1001 又不能播放了。

所以通过上述的实验，我们发现并不一定要在同一个 tick 执行播放，那么为啥 Vue.js 的 nextTick 是不可以的呢？回到 nextTick 的 macro task 的实现，它优先 setImmediate、然后 MessageChannel，最后才是 setTimeout 0。我们知道，除了高版本 IE 和 Edge，setImmediate 是没有原生支持的，除非一些工具对它进行了重新改写。而 MessageChannel 的浏览器支持程度还是非常高的，那么我把这段 demo 的异步过程改成用 MessageChannel 实现。

changeUrl() {
  this.index = (this.index + 1) % musicList.length
  this.url = musicList[this.index]
  
  let channel = new MessageChannel()
  let port = channel.port2
  channel.port1.onmessage = () => {
    this.$refs.audio.src = this.url
    this.$refs.audio.play()
  }
  port.postMessage(1)
}

这段代码在 PC 浏览器是可以播放的，而在移动端APP下和安卓&ios浏览器又不能播放，调试后发现 this.$refs.audio.play() 的逻辑也是可以执行到的，但是歌曲并不能播放，应该是浏览器对 audio 播放在使用 MessageChannel 做异步的一种限制。

前面提到实现 macro task 还有一种方法是利用 postMessage，它的浏览器支持程度也很好，我们来把 demo 改成利用它来实现。

postMessage(实际测试这种方式在iOS 13里已经不行了)

changeUrl() {
  this.index = (this.index + 1) % musicList.length
  this.url = musicList[this.index]

  addEventListener('message', () => {
    this.$refs.audio.src = this.url
    this.$refs.audio.play()
  }, false);
  postMessage(1, '*')
}

这段代码在 PC 浏览器和移动端APP下和安卓&ios浏览器都可以播放的，说明并不是 macro task 的锅，而是 MessageChannel 的锅。

如何解决？

现在我们定位到问题的本质是因为 Vue.js 的 nextTick 中优先使用了 MessageChannel,它会影响移动端APP下和安卓&ios浏览器的播放

Vue.js 的版本降级

如果是真实运行在生产环境中的项目，毫无疑问这肯定是优先解决问题的首选，因为确实也是因为 Vue.js 的升级才造成这个 bug 的。在我们的实际项目中，我们都是锁死某个 Vue.js 的版本的，除非我们想使用某个 Vue.js 新版的 feature 或者是当前版本遇到了一个严重 bug 而新版已经修复的情况，我们才会考虑升级 Vue.js，并且每次升级都需要经过完整的功能测试。

为何把 Vue.js 降级到 2.4+ 就没问题呢，因为 Vue.js 2.5 之前的 nextTick 都是优先使用 microtask 的，那么 audio 播放的时机实际上还是在当前 tick，所以当然不会有问题。

其它方式

其实还有很多方式都能“修复”这个问题，比如我们不通过 watcher，改成每次点击通过 event bus 去通知；比如仍然使用同步 watcher，但 currentSong 不通过计算，直接用 state 保留；比如每次点击事件不通过 v-on 绑定，我们直接在 mounted 的钩子函数里利用原生的 addEventListener 去绑定 click 事件。

但是最终我选择了event bus去通知改变数据的变动,因为event bus本身是同步的所以它避免了异步操作而产生的使tick改变。我觉得event bus 是一种比较折中的做法

// song-list.vue
// 发送选择歌曲的信息总线程
Bus.$emit('selectSong', this.getCurrentSong);

// play.vue
// 监听选择歌曲事件
Bus.$on('selectSong', (data) => {
    if (!this.getCurrentSong.id) {
        return;
    }
    if (data.id) {
        // 初始化一些操作
        this._initSome();
        // 设置播放器播放地址
        this._getSinglePlayingUrl(null, data.mid);
        // 请求歌词
        this.getLyric(data.mid);
    }
    else {
        savePlayUrl(data);
        this.playUrl = getPlayUrl();
        // 设置歌曲播放
        setTimeout(() => {
            this.$refs.audio.play();
        }, 500);
    }
});

详细可以参考我的项目的代码

启发

笔者实际遇到的情况是如果改变了影响视图的变量，再播放音频，就移动端就播放不出来。所以改成了先播放音频（在timeout里做延迟播放），再去修改影响视图的变量。

本文参考的的文章：
Vue.js 升级踩坑小记
 JavaScript 运行机制详解：再谈Event Loop

mpr0xy

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
关于Vue中nextTick异步调用video&audio的方法失效解决方案

原文地址：https://qq282126990.github.io/2018/02/10/nextTickJS的运行机制：JS执行是单线程的,它是基于事件循环的对于事件循环的理解大致分为以下几个步骤：所有同步任务都在主线程上执行,形成一个执行栈。主线程以外,还存在一个“任务队列”。只要异步任务有了运行结果,就在“任务队列”之中放置一个事件。一旦”执行栈”中的所有同步任务执行完毕...
复制链接

扫一扫