[贝聊科技]一个页面阻塞问题的排查过程

本文做者：Mr.Luo ，贝聊前端经理，做者博客 mrluo.life 。

从今年（2017年）年初起，咱们团队开始引入「Vue.js」开发移动端的产品。在某个项目的测试过程当中，测试妹子跟咱们反馈了一个奇怪的bug：在一个播放音乐的页面中，有一个地方同步显示音乐的当前播放位置；音乐开始播放后，这个地方的内容会不断改变，可是滚动页面后，内容却再也不变化，看起来像是某个环节被阻塞了。

这个问题只在咱们iOS的客户端内出现，在微信和Safari内却毫无问题，这让咱们一度怀疑是受到客户端某些代码的影响。但仔细排查事后，发现问题并无这么简单。

iOS中的WebView

iOS中的WebView有两种：UIWebView和WKWebView。

WKWebView是从iOS 8开始提供的，除了带来了更好的性能与更少的内存占用外，它还改良了在UIWebView里面的一些很差的体验，好比scroll事件的触发。在UIWebView内，只会在滚动彻底中止后才会触发scroll事件；而在WKWebView内，则是在滚动过程当中不断触发。

然而，WKWebView并不是向下兼容UIWebView，更换成本不小，因此仍然有至关一部分的APP还在使用UIWebView，例如咱们贝聊的APP，以及新浪微博。

即使如此，咱们让iOS组的同事临时用一个WKWebView打开问题页来测试，倒是很简单的事情。实测结果是：在WKWebView内不会有阻塞问题发生。

Demo

为了更好地重现这个问题，咱们作了一个demo页，关键代码以下：

<template>
    <div>
        <audio ref="player" :src="audioURL" @timeupdate="updateTime" controls></audio>
        <div class="current-time">{{ time }}</div>
    </div>
</template>

<script> export default { data() { return { audioURL: require('./music.mp3'), time: '' }; }, methods: { updateTime() { this.time = this.$refs.player.currentTime; document.title = this.time; } } }; </script>
复制代码

页面功能很是简单，播放音乐的时候，经过timeupdate事件去更新数据字段「time」的值，从而把当前播放位置不断地更新到界面上。同时，也把「time」的值更新到页面标题，这样作的目的是检查「time」的赋值是否成功。

用新浪微博APP打开此页，运行效果以下：

能够看到，滚动页面结束后，页面内的数字再也不更新，可是标题还在继续变化。这说明了timeupdate事件是在不断触发的，「time」字段的值也是在不断更新，可是数据变化后更新到界面（刷新DOM）的过程被阻塞了。

被阻塞的实际上是...

恰巧，咱们在出现bug的产品页中发现了另外一个现象：出现阻塞问题后，页面中调用客户端的功能也被阻塞了。这又让咱们怀疑是客户端的锅，但后来发现并非。咱们把客户端的功能调用都封装成了Promise，在调试过程当中，咱们发现该Promise实例既没法进入then的流程，也没有进入catch的流程。

咱们开始怀疑被阻塞的是Promise，因而就在demo中增长两个按钮「Button1」和「Button2」：

<template>
    <div>
        <audio ref="player" :src="audioURL" @timeupdate="updateTime" controls></audio>
        <div class="current-time">{{ time }}</div>
        <input type="button" value="Button1" @click="click1" />
        <input type="button" value="Button2" @click="click2" />
    </div>
</template>

<script> export default { data() { return { audioURL: require('./music.mp3'), time: '' }; }, methods: { click1() { alert('click1'); }, click2() { Promise.resolve().then(() => { alert('click2'); }); }, updateTime() { this.time = this.$refs.player.currentTime; document.title = this.time; } } }; </script>
复制代码

就如料想的那样，点击播放音乐并滚动页面后，点击「Button1」弹出了「click 1」，可是点击「Button2」却没有任何响应。这证实了被阻塞的确实就是Promise了。

罪魁祸首居然是...

找到了问题，就去搜索引擎找答案，但居然搜到了「Vue.js」的源代码。在本地打开该文件，也确实有这片代码：

从这里的注释能够发现，「Vue.js」的开发团队也知道Promise在UIWebView下的阻塞问题，并进行了修复，但为何在demo页中仍然有问题呢？

排查bug很重要的一点就是尽可能减小重现问题所需的代码和依赖。因而，我用「Vue-CLI」初始化一个新项目，并把demo页放到此项目中。此时再用新浪微博打开页面进行一样的操做，并无出现阻塞的问题。

而后，把项目中用到的「SASS」、「postcss-px2rem」、「Vuex」和「babel-polyfill」依次安装，并在每次安装后都从新打开demo页进行操做。最后发现，装完「babel-polyfill」以后问题就重现了。

babel-polyfill

iOS 8以上的Safari和WebView都已经支持Promise，可是实测发现，「babel-polyfill」会用本身的Promise覆盖原生的Promise！查看「babel-polyfill」所依赖的「corejs」的代码能够发现，它对Promise的特性检查比较严格：

因为iOS下的Promise并无彻底支持这些特性，因此「corejs」用本身的Promise把原生的Promise覆盖了。并且，看起来「Vue.js」对阻塞问题的修复对「corejs」的Promise无效。

解决方案

解决方案有三个：

1. 不要安装「babel-polyfill」，但这样会形成旧版本浏览器下没法运行「Vuex」。
2. 把UIWebView更换为WKWebView，但这不是短时间内能够完成的事情。
3. 加载「babel-polyfill」后，把浏览器的Promise重置回原生的Promise。

考虑到那些额外的特性在实际开发中基本用不上，方案3反而是一种比较好的临时解决方案。

先调整「babel-polyfill」的引入方式，把它的代码文件经过其余方式传到服务器上。而后修改项目入口文件，也就是根目录下的「index.html」：

<script> var _Promise; // 检查是否iOS9+（iOS9+才支持Symbol） var useNativePromise = typeof Promise === 'function' && /^(iPhone|iPad|iPod)/.test(navigator.platform) && typeof Symbol === 'function'; if (useNativePromise) { _Promise = Promise; } </script>
<script src="//s2.imgbeiliao.com/assets/js/lib/babel-polyfill/6.23.0/polyfill.min.js"></script>
<script> if (_Promise) { Promise = _Promise; } </script>
复制代码

上面代码的流程就是：检查到是iOS>=9时，就把原生Promise保存下来，待「babel-polyfill」加载执行完以后，再把保存下来的Promise覆盖回去。那iOS<9的怎么办呢？测试妹子很不容易找到了一台iOS 8的iPhone来测试，结论是不会出现阻塞问题，因此iOS<9能够不用管了。

既然「babel-polyfill」已经过script标签引入，那就能够删除对它的依赖了：

npm uninstall babel-polyfill --save
复制代码

而后修改「/build/webpack.base.conf.js」，移除「babel-polyfill」的打包入口：

entry: {
    // app: ['babel-polyfill', './src/main.js']
    app: ['./src/main.js']
}
复制代码

这种临时的解决方案其实并不优雅，让客户端尽快更换为WKWebView才是正道。

后记

最近苹果发布了iOS 11。在iOS 11的WebView中，Promise已是彻底体，能够经过「corejs」的特性检查，因此不会再有这个阻塞的问题。