VasSonic：手Q开源Hybrid框架介绍

正文

本文根据作者在 2017GMTC全球移动技术大会的上分享 的ppt整理。

特别感谢卢景伦（腾讯SNG增值产品部高级工程师）将ppt精华汇总成文，方便大家阅读学习。

前言

2017年8月8日，SNG增值产品部Vas团队研发的轻量级高性能Hybrid框架VasSonic通过了公司最终审核，作为腾讯开源组件分享给大家。从当初立项优化页面加载速度，到不断摸索、优化，再到整理代码、文档，最终在Github上开源，并且在24小时内获取star数超过1600。我们非常高兴看到我们的成果收到这么多的关注，趁此机会，正好回顾一下VasSonic的成长历程，也希望能够让大家更了解VasSonic。

项目背景

Web相信大家再熟悉不过了，它具有快速迭代发布的天然优势，但也存在中一些让人诟病的问题，比如加载速度慢，体验差等。在此之前，手Q上很多页面首屏打开速度居高不下，甚至有些耗时达到3s以上，这意味着用户打开页面必须经过3秒之后才能进行交互操作，体验相当差，很多用户忍受不了这个漫长的时间直接流失掉了。

为了提升用户体验和业务用户留存率，我们很多业务一开始通过Web开发，等页面模型验证符合预期后，再将H5页面转化成原生界面。我们很快意识到这不是一种健康的可持续的开发模式，一方面存在重复人力浪费，另外一方面原生商城除了速度快一点，要运营活动改版都很难。

所以后来团队改了切入方向，安排人力专心研究如何加快页面打开速度，经过了一系列的摸爬滚打和优化探索，最终我们研发出了VasSonic框架，让H5页面首屏达到秒开，给用户一个更好的H5体验。下面就和大家分享VasSonic框架的发展历程。

业务形态

任何一个技术框架都是结合具体的业务形态来进行发展优化的，技术是为了更好地服务业务，业务也会驱动技术的发展。在此首先介绍一下业务形态，我们是来自手Q增值产品部门的VAS团队，负责手机QQ上很多深受年轻人喜欢的个性化增值服务，比如气泡、挂件、主题等等。手Q上大部分的业务还是基于H5开发的，大家对手Q的业务形态可能有简单的了解。比如下图的游戏分发中心、会员特权中心、个性化装扮商城等。这部分商城的特点比较明显，页面的很多数据都是动态的，是由我们的产品经理在后台配置的。

(点击放大图像)

这些都是很常见页面，我们通常将html/js/css等静态资源放到CDN上，然后页面加载后，再通过CGI去拉取最新的数据，进行拼接展示， 这样子可以利用到CDN的多地部署和就近接入等优势，同时提高了服务器的并发能力。这种传统模式的加载流程如下所示：

(点击放大图像)

1. 用户点击后，经过终端一系列初始化流程，比如进程启动、Runtime初始化、创建WebView等等。

2. 完成初始化后，WebView开始去CDN上面请求Html加载页面。

3. 页面发起CGI请求对应的数据或者通过localStorage获取数据，数据回来后再对DOM进行操作更新

可以看出上述流程存在着几个问题：

1. 从外网统计数据来看，用户的终端耗时在1s以上，这意味着在这1s多的时间里，网络完全是空闲在等待的，非常浪费；

2. 页面的资源和数据完全依赖于网络，特别是用户在弱网络场景下，页面会出现很长时间的白屏，体验非常差；

3. 因为页面的数据依赖于动态拉取，加载完页面后，往往是看到一些模块先转菊花，再展示，体验也是不好的。同时这里涉及到较多数据更新，经常要更新DOM，性能上也有不少开销。

所以针对以上几个问题，我们也对应做了很多优化和探索。

(点击放大图像)

VasSonic的前世

优化终端

针对终端耗时1s以上的情况，我们对手Q WebView框架进行了重构：

1. 启动流程彻底拆分，设计为一个状态机按序按需执行

2. View相关拆分模块化设计，尽可能懒加载，IO异步化

3. X5内核在手Q中的独立进程中提前预加载

4. 创建WebView对象复用池

关于第四点，我们想分享一些Android平台上的细节，由于Android系统的生态原因，导致用户的系统版本和系统Webkit内核处于极其分裂状态，所以我们公司在手Q和微信统一使用X5内核。相对系统WebView来说，首次启动X5内核时，创建WebView比较耗时，因此我们尽量想复用WebView，但是WebView却是与Activity Context绑定。销毁复用的时候，需要释放Activity的Context，否则会内存泄露。针对这种情况，有没有一种两全其美的办法呢？

计算机有一句经典的名言：

计算机领域任何一个问题都可以通过引入中间层来解决。

于是我们通过包装的方式，实现了一个Context的壳，真正的实现体包装在里面，逻辑调用真正调用到对应的实现体的函数。 经过实验发现，Android系统本身提供了这么一个MutableContextWrapper，作为Context的一个中间层。

我们会将Activity context包在MutableContextWrapper里面，destory的时候，会将WebView的Context设置为Application的Context，从而释放Activity Context。

类似如下：

__Wed Dec 27 2017 14:49:51 GMT+0800 (CST)____Wed Dec 27 2017 14:49:51 GMT+0800 (CST)__//precreate WebView
MutableContextWrapper contextWrapper = new MutableContextWrapper(BaseApplicationImpl.sApplication);
mPool[0] = new WebView(contextWrapper);

//reset WebView 
ct =(MutableContextWrapper)webview.getContext();
ct.setBaseContext(getApplication());

//reuse WebView
((MutableContextWrapper)webview.getContext()).setBaseContext(activityContext);__Wed Dec 27 2017 14:49:51 GMT+0800 (CST)____Wed Dec 27 2017 14:49:51 GMT+0800 (CST)__

静态直出

“直出”这个概念对前端同学来说，并不陌生。为了优化首屏体验，大部分主流的页面都会在服务器端拉取首屏数据后通过NodeJs进行渲染，然后生成一个包含了首屏数据的Html文件，这样子展示首屏的时候，就可以解决内容转菊花的问题了。

当然这种页面“直出”的方式也会带来一个问题，服务器需要拉取首屏数据，意味着服务端处理耗时增加。

不过因为现在Html都会发布到CDN上，WebView直接从CDN上面获取，这块耗时没有对用户造成影响。

手Q里面有一套自动化的构建系统Vnues，当产品经理修改数据发布后，可以一键启动构建任务，Vnues系统就会自动同步最新的代码和数据，然后生成新的含首屏Html，并发布到CDN上面去。

(点击放大图像)

离线预推

页面发布到CDN上面去后，那么WebView需要发起网络请求去拉取。当用户在弱网络或者网速比较差的环境下，这个加载时间会很长。于是我们通过离线预推的方式，把页面的资源提前拉取到本地，当用户加载资源的时候，相当于从本地加载，即使没有网络，也能展示首屏页面。这个也就是大家熟悉的离线包。

手Q使用7Z生成离线包, 同时离线包服务器将新的离线包跟业务对应的历史离线包进行BsDiff做二进制差分，生成增量包，进一步降低下载离线包时的带宽成本，下载所消耗的流量从一个完整的离线包（253KB）降低为一个增量包（3KB）。

(点击放大图像)

经过一系列优化后，在Android平台上，点击到页面首屏展示的耗时从平均3s多降低为1.8s，优化40% 以上。

(点击放大图像)

VasSonic的诞生

虽然通过静态直出和离线预推等方式优化后，速度已经达到1.8s，但还存在很大的优化空间，当我们准备持续深入优化时，我们的业务形态发生了新的变化。

之前我们页面内容的数据主要是由产品经理要配置的，用户看到的内容基本都是一样的。而现在页面为了更好地为用户推荐喜欢的内容，我们后台引入机器学习和随机算法来做智能个性化推荐。比如左边新用户推荐的是新货精选，而右边活跃用户展示的是潮品推荐。另外还有部分的内容是随机算法推荐的。这意味着不同用户看到的内容是不同的，同一个用户不同时间看到的内容也有可能不同。

(点击放大图像)

所以为了满足业务的需求，我们只能实时拉取用户数据并在服务端渲染后返回给客户端，也就是动态直出的方案。

但是动态直出方案存在几个比较明显的问题：

1. 服务端实时拉取数据渲染导致白屏时间长，因为服务器要先实时拉取个人数据，然后进行渲染直出，这个耗时不可控；

2. 首屏无法使用离线预推等缓存策略，因为每个用户看到的内容不一样，我们无法通过静态直出的方式那样把Html全部发布到CDN；

虽然动态直出方案下，页面首屏无法通过离线预推等方式进行加载优化，但前面优化积累的经验给我们提供了思路：要优化白屏问题，核心还是得从提升资源加载速度方向入手。所以我们重点在资源加载方面进行了深度优化。

并行加载

首先在加载流程方面，我们发现这里WebView访问依然是串行的， WebView要等终端初始化完成之后，才发起请求。虽然终端耗时优化了不少，但是从外网的统计数据来看，终端初始化还是存在几百毫秒的耗时，而这段时间内网络是在空等的。

(点击放大图像)

因此性能上不够极致，我们优化代码，这两个操作并行处理，流程改为：

(点击放大图像)

并行处理后速度有所改善，但我们发现在某些场景下，终端初始化比较快，但数据没有完成返回，这意味着内核在空等，而内核是支持边加载边渲染的，我们在并行的同时，能否也利用内核的这个特性呢？

请到「今天看啥」查看全文