接上篇《VasSonic 2.0 iOS端分析（一）》，继续介绍VasSonic。
整体结构
以功能模块为单位看VasSonic，主要分为以下几个部分：
主要的类
VasSonic 2.0主要的类如下面类图所示：
在类图中可以很清楚地看出各类之间的关系，下面简单介绍一下各个类的主要作用。
- SonicSessionConfiguration：对会话的配置封装类。
- SonicCache：本地缓存类。
- SonicCacheItem：内存缓存模型类。
- SonicEngine：会话管理类。
- SonicURLProtocol：WebView请求拦截。
- SonicProtocol：Sonic协议定义。
- SonicSession：会话控制类。
- SonicUtil：工具类。
- SonicConnection：网络请求类。
- SonicConfiguration：Sonic的配置封装类。
- SonicDatabase：数据库操作类。
- SonicServer：本地服务中间层。
- SonicConstants：常量定义。
主要流程——首次加载
第一次加载时，本地没有缓存。SonicClient（2.0中已经改为SonicEngine）会首先发起一次请求，拿到需要加载网页的数据，并且将数据拆分为模板和数据两个部分，以及从相应头中获取到配置信息。将这三类信息作为三个文件缓存到本地数据库。当WebView加载url发起请求时，NSURLProtocol会进行拦截，直接拿到SonicClient已经请求到的数据，并刷新到网页上。
大概的时序图如下图所示：
主要流程——完全缓存
完全缓存是非首次加载的情况。SonicClient（2.0中已经改为SonicEngine）还是会首先发起一次请求，但是本次请求返回的响应码为304，也就是服务端的数据无变化。此时，SonicClient只会更新响应头中的配置信息，如请求时间等等。当WebView加载url发起请求时，NSURLProtocol也会进行拦截，直接加载本地缓存的数据。
大概的时序图如下图所示：
主要流程——数据刷新
数据刷新也是非首次加载的情况。SonicClient（2.0中已经改为SonicEngine）还是会首先发起一次请求，但是本次请求返回的响应码为200，也就是服务端的数据有变化。那么，数据有哪些变化呢？请求的响应头会用字段TemplateChange来告诉客户端（该部分在上一篇缓存策略中讲到过）。如果TemplateChange的值为false，那么说明模板没有变化，所以数据部分一定会有变化。此时，SonicClient不仅会更新响应头中的配置信息，也会更新本地的数据文件。当WebView加载url发起请求时，NSURLProtocol也会进行拦截，先加载本地缓存的数据，然后将更新的数据回调给页面进行刷新。
大概的时序图如下图所示：
主要流程——模板更新
模板更新也是非首次加载的情况。SonicClient（2.0中已经改为SonicEngine）还是会首先发起一次请求，但是本次请求返回的响应码为200，也就是服务端的数据有变化。请求的响应头中TemplateChange字段的值为true，说明模板发生了改变。此时，SonicClient不仅会更新响应头中的配置信息，也会更新本地的模板文件和数据文件。当WebView加载url发起请求时，NSURLProtocol也会进行拦截，先加载本地缓存的数据，然后触发WebView重新load url，从而更新页面上的模板和数据。
大概的时序图如下图所示：
优缺点及适用场景
优点
- 项目的源码开源。
- 如果使用恰当确实能增加页面加载速度。
- 能节省大量流量。
缺点
- 接入成本高，需要服务端、前端使用统一标准。
- Local Server虽然简化了服务端配置，但增加了客户端性能消耗。
- 网页里面嵌入的链接无法缓存。
- 源码中有不少没有用到的冗余代码。
适用场景
- 场景一：
项目刚开始，服务端、前端使用VasSonic统一标准，最适合使用VasSonic SDK。 - 场景二：
项目已经进行到中间，或者已经完成，不太适合使用VasSonic SDK，可以使用Local Server模式，但是效果不佳。 - 场景三：
在任何情况下，对VasSonic进行改造，使之适用项目。但是后面升级比较麻烦。
上篇《VasSonic 2.0 iOS端分析（一）》
见：https://www.jianshu.com/p/def800b91cb0
主要内容：
- 功能简介
- 并行加载
- 数据模板
- 缓存策略
- 2.0新特性—Local Server
- 2.0新特性—Cache-Control
