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

4,417 阅读4分钟

本文作者:Mr.Luo ,贝聊前端经理,作者博客 mrluo.life

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

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

iOS中的WebView

iOS中的WebView有两种:UIWebViewWKWebView

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对阻塞问题的修复

从这里的注释可以发现,「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的特性检查比较严格:

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」的特性检查,所以不会再有这个阻塞的问题。