功能简介

以下功能简介的几段文字引用自github上VasSonic官方wiki。地址为：https://github.com/Tencent/VasSonic/wiki

快速：

通过中间层启动子线程并发拉取页面主资源和流式拦截的方式，支持内核边加载边渲染，弱化终端初始化过程耗时的影响，同时对页面进行动态缓存和增量更新，减少页面对网络数据传输的依赖，极速提升H5页面的加载速度。

省流量：

支持动态缓存页面内容，通过客户端和服务端遵守一定的格式规范，每次请求仅需要返回变动的数据块数据，大大减少响应数据传输。

良好的用户体验:

通过预推送以及动态缓存页面，先加载本地缓存页面，用户可以快速看到内容，即使在无网络场景下，依然能看到首屏内容，让H5页面的体验更加接近原生。

易用：

框架来自腾讯VAS团队超过一年的优化提速总结，它是一整套解决方案，可以快速在Android和iOS平台上接入使用，无须繁琐配置流程。

并行加载

VasSonic在加载web之前，先根据url创建一个会话。独立起一个线程去请求url定位的资源并缓存。当UIWebView加载url时，通过NSURLProtocol拦截请求，并根据不同的策略进行加载和刷新。因此这是两个并行的线程，如果手动执行Sonic线程，就是预加载。

并行加载示意图

数据模板

为了方便数据的缓存和刷新，提高效率，Sonic将一个完整的html页面做了数据和模板的拆分。打开一个页面之后，可以看到沙盒里面多了下面四个文件，如下图所示。分别是以.html、.data、.rsp、.temp为后缀，分别表示完整的网页、动态数据、配置、和模板数据。

Sonic网页缓存文件

那么这几个文件里面的数据到底是怎样的呢？文件之间的关系是什么？

缓存文件的由来

通过源码的分析，可以看到，几个文件之间的关系如上图所示。其中.html文件是完全的网页文件，然后把.html文件进行拆分，就得到了.temp和.data文件。而.rsp文件是直接把请求返回头中的一些配置取出来缓存在文件中。
打开这些文件看里面的内容，也可以看出这种关系。如下图所示，为完整的.html文件内容。

.html文件内容

特意圈了一下，里面绿色的注释。这个< !--sonicdiff-data1--> < !--sonicdiff-data1-end-->就是数据和模板区分的边界。再看.temp文件，其实也是一个html文件，如下图所示：

.temp文件内容

从图中可以看出，和.html文件相比，没有了< !--sonicdiff-data1-->< !--sonicdiff-data1-end-->内部的内容，被替换成了{data1}。然后再看下.data文件，如下图所示：

.data文件内容

可以看出，.data文件其实是一个.plist文件，其中用Key {data1}储存了< !--sonicdiff-data1-->< !--sonicdiff-data1-end-->内部的内容。这样就很明了了，.temp和.data数据拼起来就是.html文件内容。再来看最后一个文件，.rsp文件，如下图所示：

.rsp文件内容

.rsp文件其实也是一个.plist文件，里面存储的都是各种配置、策略的键值对。

缓存策略

Sonic很重要的一个功能点就是缓存，那么它的缓存策略有哪些？
从请求的返回头里，可以看到一个Key——SonicHeaderKeyCacheOffline，这个Key里面存的就是关于如何缓存、刷新的几个值。这几个值表示的意思分别是，SonicHeaderValueCacheOfflineStore表示仅仅缓存，不刷新页面；SonicHeaderValueCacheOfflineStoreRefresh表示既缓存又刷新页面；SonicHeaderValueCacheOfflineRefresh表示不缓存，仅仅刷新页面；SonicHeaderValueCacheOfflineDisable表示使本地缓存失效。如下所示：

首次加载缓存策略

当首次加载页面的时候，如果返回的是状态码200，则返回头中取出对应的缓存策略并缓存。如果返回的不是200，则是请求异常，做异常处理。如果不是首次加载页面，情况又有些不同，如下所示：

非首次加载缓存策略

当非首次加载时，首先会看返回的状态码。如果状态码是304，说明服务端没有更新，所以客户端只更新一下配置文件里面的请求时间戳，不刷新缓存，也不刷新页面。如果状态码是200，说明服务端内容有变化，本地缓存需要刷新。但是具体是那部分发生了变化，需要根据返回头里面的Key——SonicHeaderKeyTemplateChange来判断。如果SonicHeaderKeyTemplateChange为true，则表示模板有更新，需要删除所有缓存，重新走模板数据拆分逻辑。如果缓存策略中有刷新，则向Webview发起重新加载。如果SonicHeaderKeyTemplateChange为false，则表示模板不变数据有更新，仅仅需要更新数据文件。但是如果缓存策略中有刷新，要将新的数据发给js刷新Web界面。

2.0新特性—Local Server

Local Server是VasSonic 2.0中的新特性。Local Server的目的是简化VasSonic的接入，在客户端模拟服务端的配置，省去服务端的配置。那么Local Server做了哪些处理呢？
其实Local Server可以算作是客户端和服务端的一个中间层。如果开启了Local Server模式，即使从服务端请求到的只有数据，没有返回头中的一些特定Key的配置，也没关系。因为Local Server层会通过计算把这些特定Key的配置补充到返回的头中。

Local Server模式返回头中的Key

在Local Server模式下，SonicHeaderKeyCacheOffline这个Key是被写死了，一定是SonicHeaderValueCacheOfflineStoreRefresh，也就是既缓存又刷新。
然后又增加了两个Key，eTag和template-tag。其中，eTag是对完整网页文件（.html文件）取SHA1码得到的，template-tag是对模板文件（.temp文件）取SHA1码得到的。
在Local Server模式下，Local Server处理逻辑如下图所示：

Local Server处理逻辑

当服务端返回的状态码为304时，说明服务端无更新，将跳过Local Server层的处理；如果服务端返回的状态码为200，会做执行以下逻辑。首先会分别计算本地缓存的完整网页文件（.html文件）的eTag和请求到的数据的完整网页文件（.html文件）的eTag，如果两个eTag相等，说明数据无更新，将返回头的状态码置为304；如果两个eTag不相等，说明数据确实有更新，但不确定是模板更新了还是数据更新了，所以要分别计算本地缓存和本次请求数据的模板文件（.temp文件）的template-tag。如果两个template-tag不相等，说明模板有更新，将返回头中的template-change Key置为true；如果两个template-tag相等，说明模板不变，数据有更新，就将返回头中的template-change Key置为false。
经过Local Server层的处理后，Sonic内核就能按照返回头中的指令继续执行下一步操作了。

2.0新特性—Cache-Control

“Sonic 2.0支持在Http响应头部添加Cache-Control字段来控制缓存生命周期，目前支持
max-age、private、public三个可选值。”
                                                           ——VasSonic 2.0

上面引用的是官方wiki上的原话。但是从iOS端的源码来看，并没有找到引用的内容，这段话可能是针对Android端的。这个Cache-Control功能目前在iOS端的主要表现为以下几个点：

iOS中没有找到Cache-Control使用max-age、private、public三个值。猜想这三个值应用在Android里面。
iOS的Cache-Control使用的是no-cache、 no-store、 must-revalidate三个值，这三个值都是不要缓存的意思。
iOS生命周期用的是cache-expire-time和max-age。cache-expire-time是到期的时间戳。max-age是缓存的有效期。

下篇《VasSonic 2.0 iOS端分析（二）》
见：https://www.jianshu.com/p/5d35ced5d6b4
主要内容：

整体结构
主要的类
主要流程——首次加载
主要流程——完全缓存
主要流程——数据刷新
主要流程——模板更新
优缺点及适用场景

VasSonic 2.0 iOS端分析（一）