Webview秒开框架VasSonic源码分析(二)

转载请注明出处：

Webview秒开框架VasSonic源码分析(一)

Webview秒开框架VasSonic源码分析(二)

地址：http://www.jianshu.com/p/7a231aee6d6a

目录

image

今天VasSonic 2.0发版了，主要提供了模拟后台的功能。下面我们分析一下吧～

1 sonicServer对SonicSessionConnection进行代理，模拟后台

sonicServer是对SonicSessionConnection的代理。SonicSessionConnection就是常见的网络请求connection（1.0版本就有了）。能够获取responseData，responseCode。不过注意一下，在创建请求的connection时，添加了本地缓存对应的etag和templateTag的header值（不管需不需要后台参与，都需要这么做）。

1.1 SonicServer怎么模拟的后台？

sonicServer中在代理SonicSessionConnection时，做了一些模拟后台的事情：

• 调用sonicServer#connect时，先检查request中有没有etag和templateTag的header值。如果有一个没有，那么就说明是第一次加载，直接返回。** 所以说如果本地有缓存，那么不管有没有后台参与，都要在请求connection中添加etag和templateTag的header值，不然会被认为是第一次加载。检查后台返回的header中有没有返回etag。如果没有，那么阻塞加载服务端的html，一直等到加载完成，把拉下来的html放到sonicServer 成员变量serverRsp（String类型）。然后获取到html的etag值（sha1），把这个新的etag值放到response headers中，并且与request/缓存中的etag对比（ 说明即使不需要后台参与，request中也需要添加缓存对应的etag和templateTag header**），如果发现两者相等，那么说明什么都没变，直接返回。

• 然后再检查后台是不是返回了templateTag。如果没有返回，那么和上面一样，获取服务端的html（也可能上面已经获取好了），把html进行分割。分割后把新的templateTag值放到response headers中，并且与request中的templateTag对比，如果两者相同，说明服务端的html模板与缓存中的html模板相同，那么把template-change这个header值设为false，放到response headers中。如果两者不相同，说明服务端的html模板与缓存中的html模板不相同，那么把template-change这个header值设为true，放到response headers中。

这样以来，当我们调用sonicServer#getResponseHeaders时，是有etag，templateTag，template-change这些header值的。就好像是后台返回的一样。这就是2.0版本模拟后台的过程。

优势: 不需要后台的参与。

缺点: 如果本地有缓存，会进行模拟后台。需要一直加载到完全获取到服务端的html数据，才能知道response header中的etag，templateTag，template-change值是多少。效率上有些问题。当然，如果是第一次加载（request中没有etag和templateTag），有可能不会一直加载直到完全获取服务端html。这时候允许外界中断让webview“边加载边渲染”。

2 其他方法的逻辑异同

假定我们采用的就是无后台参与的方案，其实很多逻辑变得比以前简单了。因为很多时候服务端html数据已经加载完成。那么我们看一下handleFlow-DataUpdate（）和handleFlow-TemplateChange（）和handleFlow-FirstLoad（）。SonicSession加载数据大部分通过三个方法。

2.1 捋一下handleFlow-DataUpdate（）和handleFlow-TemplateChange（）

分析SonicSession时，注意handleFlow-DataUpdate 和 handleFlow-TemplateChange方法执行时，服务端的整个html已经加载完了。handleFlow-FirstLoad执行时，服务端的html还没下载。

如果我们假定我们采用的就是无后台参与的方案，即handleFlow-DataUpdate（）和handleFlow-TemplateChange（）执行时，服务端html数据已经加载完成。那么我们分析一下这两个方法：

首先sonicSession先加载缓存，通知webview加载缓存。之后如果不是第一次加载，那么会执行handleFlow-DataUpdate（）或handleFlow-TemplateChange（）。

执行handleFlow-DataUpdate（）会将缓存的html数据和网络拉取到的html数据对比得到diff，然后通过handler通知SonicDiffDataCallback进行更新。当然还得判断，如果这时候webview已经加载/正在加载缓存（wasLoadDataInvoked

为true），那么会才会通知SonicDiffDataCallback进行更新（不用等待缓存的html加载展示之后再刷新，update代码中没看到等待这个事件的逻辑）。如果这时候webview还没来得及加载缓存（wasLoadDataInvoked为false），那么就加载整个新的html。

因为handleFlow-DataUpdate（）和handleFlow-TemplateChange（）执行时，服务端html数据已经加载完成 ，所以这两部分执行方式类似。不过稍微不同的是，这里不管webview是否加载/正在加载缓存（wasLoadDataInvoked为true），都会调用webview#loadDataWithBaseUrlAndHeader来加载新的html。（这里也不用等待缓存的html加载展示之后再加载新的html，这里的代码中虽然有等待这个事件的逻辑，但是在这种场景下并没有用到）

2.2 首次加载handleFlow-FirstLoad（）

1.0版本connection#getResponse时，会传入一个breakCondition。如果外界有打断，会把已经加载到内存的outputSream流和节点流包成自定义的一个sonicInputstream流返回。sonicInputstream#read时先读取内存中的流，再读取节点流中的数据。

2.0版本中把这块逻辑放在sonicServer#getResponseStream中了。也会传入beakCondition等待外界打断。中断时，会把已经加载的数据放到内存的outputSream流和serverRsp 字符串中，然后把内存outputSream流和未加载的节点流包成SonicSessionStream返回：

public synchronized InputStream getResponseStream(AtomicBoolean breakConditions) {

        if (readServerResponse(breakConditions)) {

            BufferedInputStream netStream = !TextUtils.isEmpty(serverRsp) ? null : connectionImpl.getResponseStream();

            return new SonicSessionStream(this, outputStream, netStream);

        } else {

            return null;

        }

    }

一开始理解不到位，以为serverRsp不为null，导致最终的SonicSessionStream不包含节点流。前面讲了，首次加载时，sonicServer#connect不会从服务端加载html。这时候serverRsp为null，所以SonicSessionStream包含节点流。和1.0版本一样，等有资源拦截时，把SonicSessionStream给webview进行“边加载边渲染”。

3 总结

大部分逻辑分析完了，其实改动主要是进行了模拟后台逻辑。这样就不需要后台的参与了。模拟后台后，因为可变因素少了，源代码的逻辑其实更清晰了。代价就是效率上可能有点代价。毕竟 需要一直加载到完全获取到服务端的html数据，才能知道response header中的etag，templateTag，template-change值是多少。