当第二次加载返回的数据就没有前面看到的整个HTML，只会返回大概37KB的数据，这个data实际上就是一个JSON，但它定义了前面对应例如sonicdiff-banner的DOM结构。为了节省H5中执行的代码，我们直接在JSON中把DOM节点代码拼好，这样页面只需要做id的匹配和刷新。

这里37KB的传输数据很难避免，我们观察到不同业务的刷新数据量还不一样。能否能再减少一些提交给页面去刷新的数据量呢，毕竟产品经理每次修改的数据也不会很多。

　　减少提交页面数据

我们在sonicCache这一层除了前面提到的我们会缓存完整的HTML、template，还会把数据提取出来做dataCache。

template是在首次访问的时候，根据sonicdiff里的id信息，把所有可变的数据剔除掉剩下的页面框架。用户二次打开时只要根据返回的数据，在客户端本地和template做merge拼接就可以得到完整的HTML。

我们把每次的dataCache缓存下来后，对数据也做了差量，比如这一次请求返回的是37KB的数据，上次cache的也是37KB的数据，我们会判断内部真正变化的到底有多少，然后只把差量的部分交给HTML刷新，这样在大部分场景下我们的页面只需要处理大概9KB的数据就能刷新整个页面。

有了cache后用户在本地打开的速度非常快，差量数据的传输也使得用户刷新等待的时间减少了，最后加上这种数据提交时的diff使页面刷新范围也得到大幅的减少。

整个sonic模式流程如下，看上去比较复杂，但基本原理就是通过Bridge桥接把请求回的HTML分模版和数据进行缓存。

这里可能有疑问，前面静态直出花力气做的offlineServer和离线预推策略，在这里还有没有用？事实上动态页面和之前提到的静态页面离线缓存机制我们仍在使用，因为我们业务页面还有大量公用JS，比如QQ提供的JS API封装，还有一些共用的CSS也是通过离线包策略做的预推，这也是大家每次登录的时候都会进行的下载。

　　数据以及效果

完成这种模式之后数据效果相对明显，首次加载和普通的HTTP加载性能是差不多的，但用户第二次打开页面时，通常只需要1秒的时间就能看到页面，这1秒钟还包括客户端launch进程和WebView的开销，同时我们加载速度不再受用户网络环境的影响，不管是2G还是4G加载速度都接近一样。

而且还带来一个好处，如果用户的网络比较差，比如经常抖动连接不上，因为我们本地有缓存，因此就算用户当前处于断网状态我们的页面也能打开。

这里没有提到模板更新的场景，模板更新是指我们抽取出来的template在我们server是有可能动态变化的，这个时候的加载流程和我们前面提到的就不太一样了，当template有变化时，还是按照原来走HTML reload页面的流程，这里的耗时相对偏高，但我们统计发现大部分用户还是落在数据刷新也就是二次打开的状态。

　　是否使用持久连接

在做H5的提速优化时，大家很容易想到我们是否要利用持久连接去避免访问服务器的connect、DNS、握手之类的耗时，像QQ这种客户端它跟后台server是有持久化的连接的。假如用这个连接来向后台服务器请求HTML文件并交给WebView，会不会比临时建立一个connect请求更快呢？我们只需要搭一个反向代理服务就可以从QQ消息后台访问我们Node.js服务器，这个流程是可以打通，但是我们评估认为这种模式未必适合所有的场景。

确实是有一些App利用持久连接这种通道去加载页面，但在手机QQ比较难行得通，因为手机QQ客户端与sever的持久连接通道是一个非常传统的CS架构，它发送的是socket package，每次需要发送一个请求包，收到应答之后才会继续下一个请求。

这种应答机制决定了它每次都需要一个等待的过程，而且socket package的约束造成了每次传输的数据包的大小受到限制，像我们30+KB的数据很有可能要拆成五六个数据包，虽然是利用了持久连接节省了connect耗时，但和server多次来回通讯反而把整个耗时加大了。

另外，从Node.js服务器返回的数据是HTTP流式的，WebView不需要等待整个HTML加载完成后才能进行渲染和显示，只要拿到传输中的first byte就可以开始进行document的解析以及DOM的构造。