图片视频瀑布流长列表性能优化实践

先说需求

需求定义很简单,本来有一个这样的瀑布流页面,滚动加载更多卡片,在此基础上,增加视频支持,也就是说可能是图片也可能是短视频。视频要求在Wi-Fi时内联静音自动循环播放,不需要其他交互。

是不是非常简单的一句需求,要求也不高。

图片视频瀑布流长列表性能优化实践_第1张图片
瀑布流

调研了视频内联播放的兼容性,问题不大。

静音播放也就一个muted属性的事情。

自动播放只需要mounted之后play一下,或者用autoplay属性。

循环播放就是loop属性啦。

判断Wi-Fi环境可以通过桥与客户端通信,这个涉及到具体业务,就不细说了,总之,调个API完事。

看起来已经实现了。

开始踩坑。

遇到性能问题

按照需求,后端会控制视频出现的频率,至少5个卡片才允许出一个视频,不然满屏幕视频,效果不好。但这是一个瀑布流,理论上可以滚动加载成百上千个卡片,假设每5个卡片放一个视频,效果会如何呢?

图片视频瀑布流长列表性能优化实践_第2张图片
CPU占用情况

大概也就是这样吧,CPU温度可以上90,占用率300%+(四核八线程),用上那什么iphone-inline-video插件兼容iOS 9的话,可以上600%+。

表现在移动端就是滚都滚不动,即使是iPhone X,滑动起来也是非常无比卡顿。

尝试优化

现实世界中,用户一个屏幕最多看到几个卡片,基本不可能超过10个,但可能已经加载了上百张卡片,里面的视频都还在自动播放,CPU根本吃不消。

所以优化思路是,停止掉不需要的视频。但我的做法靴微激进了点,参考点评APP首页的效果,滚到下面再滚回去图片都是重新加载的,至少看起来是的,也许图片、视频资源都被GC了,而不仅仅是暂停视频。

我的实践是,不在可视区域的图片和视频直接替换成空div,用户滚回来的时候再替换回来。至于图片会不会被GC,交给容器去做。

那么,怎么实现这个效果呢?

一开始我在钻牛角尖的纠结,如何在父组件list中监听滚动,判断屏幕显示了哪些子组件card,并通知某些子组件你被优化了

好像不是很好做,那要不在每个子组件里自己监听一下滚动,判断自己的位置在不在可视区域?感觉性能会很差,毕竟滚动事件本身就会触发很多很多次,还要搞这么多监听器。

后来,我参考了lazysizes的实现,它是通过在全局window挂了一个lazyElements列表,在初始化的时候直接querySelectorAll('.custom-class-name')…… 大致思路就是:首先把所有元素加了个特殊的类名,初始化时取出来存在window对象下,然后监听滚动,forEach直接遍历所有元素,根据该元素的位置(是否在可视区域内)来判断是否需要加载。

考虑到我们频繁使用的lazysizes也不过就这样处理的,那我也可以这么做吧。主要实现的代码如下:

export default {
  mounted() {
    this.addOptimizeScrollListener();
  },
  beforeDestroy() {
    document.removeEventListener('scroll', this._optimizeListener, false);
  },
  methods: {
    addOptimizeScrollListener() {
      const windowHeight = window.innerHeight;
      const TOLERANCE_HEIGHT = 300;

      this._optimizeListener = throttleByRAF(() => {
        if (this.$refs.cards) {
          this.$refs.cards.forEach(card => {
            const rect = card.$el.getBoundingClientRect();

            if (rect.top > windowHeight + TOLERANCE_HEIGHT || rect.bottom < 0 - TOLERANCE_HEIGHT) {
              card.isOptimized = true;
            } else {
              card.isOptimized = false;
            }
          });
        }
      });
      document.addEventListener('scroll', this._optimizeListener, false);
    },
  }
};

简单解释一下:在mounted的时候添加滚动监听器。监听器做的事情就是通过$refs拿到cards组件列表,然后类似lazysizes的操作,直接forEach判断是否在视窗内,然后给该card组件实例的isOptimized赋值。这里有一些优化,比如throttleByRAF用来限流执行,TOLERANCE_HEIGHT用来容错,不要这么严格的按照视窗边界来优化,减少用户轻微滚动导致的重复加载。

主要的实现就是这里了,card组件内部只需要根据isOptimized的值来决定渲染图片视频还是空白就可以了。

值得注意的是,必须要获取到原有的图片视频的高度,否则就会有抖动,甚至瀑布流布局错乱。这里比较特殊的一点是,后端的接口里提供了宽高,可以提前预知高度,所以只需要按照给的高度填充空白即可。

图片视频瀑布流长列表性能优化实践_第3张图片

其实也可以把整个card替换成空白占位(当然我这里说的空白不是纯白色,是五颜六色的占位,如果有想法,还可以设计一些占位图,提高视觉效果)。那怎么拿到高度呢?

答案就是window.getComputedStyle! 在mounted的时候获取一下存起来,被优化的时候用这个高度即可。

性能对比

首先,来个直观的体验对比,那就是CPU占用没这么夸张了,移动端滚起来也很快乐了,用起来和之前仅有图片时没有太多差别。

在Performance面板能观察到Nodes数量大幅减少,未优化时大约16000+,优化后3000~6000个。

由于之前被误导可能是内存占用过大导致的,所以我详细的对比了一下不同策略的内存使用情况。

图片视频瀑布流长列表性能优化实践_第4张图片
内存快照对比

果然……没什么区别。。。可以看到优化掉整个卡片还是能省一点内存的。粗略看了一下细节,未优化的情况下,其中VueComponents的数量为632,占用8.9MB,优化后数量仅343个,占用5.1MB。两者的数量差值为289,可以说明当前只渲染11个卡片,符合预期。

然而这点差别相对来说还OK,因为我直接用了线上的图片300张,每张只有20KB左右。主要还是解决了CPU占用过高的问题,而回收DOM带来的内存优化算是赠送的吧。

其他问题

判断Wi-Fi导致卡顿

在较为古老的OPPO手机上测试该页面,发现还是有些卡顿,尝试把getNetworkType调用干掉,就继续丝滑了。

原因是每加载一个有视频的卡片时,我都会去判断一下网络类型,以应对用户切换Wi-Fi到4G之类的操作。因为APP的桥没有提供相应的监听函数,只好这样操作。但显然,不是很值得。

于是找到了一个在线和离线事件,可以监听浏览器上线和下线。如果用户从Wi-Fi切换到4G时会经历下线和上线,那真是完美了。当然,没有这么完美,切换网络过程中并没有触发这两个事件……

最终的解决方案是,每10秒调用一次getNetworkType,用轮询折衷一下。

静音播放Bug

静音播放视频似乎没有问题,但是当我点进一个详情页,打开新的webview,再返回到当前页面时,诡异的播出了声音…… 并且,还没有找到原因。

结果不做了

然后发现点评APP首页用的是WebP格式的动图,而不是视频。。。

改方案。。。

改接口。。。

优化基本是白写了,或者说,可以优化,但没必要。。。

(还是学到了点东西的)

最后的结局

平台对WebP支持的稀烂,动图直接没处理,暂时无法支持动图……

所以还是要使用视频。

好消息是这个优化没白做,坏消息是我必须要解决静音变成非静音的bug。

直接提了工单给平台,得知是对方手滑实现的“特性”,目前可以通过监听webview appear事件手动再设置一下muted即可。

这…算是happy ending吧。

你可能感兴趣的:(图片视频瀑布流长列表性能优化实践)