hybrid cache 方案总结

Hybrid Cache 方案

随着应用开发的发展对APP性能要求越来越高，越来越多的方案出现，比如React Native，Weex等优秀的方案，在性能上有有了巨大的提升，如果想要切换成React Native或者Weex往往需要很大的成本和风险。如果项目是从头开始做起可能会比较好，但是如果现有应用迁移的话，就要面临诸如稳定性和成本的问题。

当然迁移完成后对后续的成本会有大降低。在实际项目中往往嵌入Html页面或者打开一个web页面也是不能消除的，原因很简单，虽然使用React Native可以实现远程更新代码，但是面对一些更新非常频繁的页面也无济于事，在项目需求不清晰的情况下，就更难说了。所以在html页面不能完全消除的情况下。需要一个相对能接受的方式来让html页面更快的渲染。

基于此也有很多cache方案，大多数是基于http协议的，思路是跟进http header的etag 和 状态码来实现的，这种情况会有一个问题就是同一个页面在app和web都适用的情况下，就很难处理了，在web大多数情况下html页面一般是不会进行本地cache的，即使cache也是使用etag 配合 status来进行，总得来说还是要发一个http请求来检查页面是否需要重新下载的。这种方案一般情况下是没问题的，但是网络总是很难预料的即使一个空内容的请求也可能会偶尔慢一下。这种问题怎么解决的呢？

此问题有一个比较好的方案 VasSoinc 能有效的改善页面的加载性能，非常有效果，但是这种方案需要server端配合，整个项目改下来收益很明显，但是成本也很高。我们希望有一个成本更低，收益更明显一些的方案。

面临的问题

同一个页面app内部和Web上同时能够使用
成本更低，比如Server端最好不要改动
希望能够收获更好的效果，能够解决的偶尔快，偶尔慢的问题
App更新能够相对及时一些，不要造成页面不一致的情况
思路

当面对该问题的时候，第一个想到的时候manifest问题，考虑使用浏览器的offline cache的能力，这个方法面临最严重的问题有两个

如果使用manifest这种方式，该配置会对整个环境生效，不仅仅app内部的webview，各种浏览器也有效
manifest很多bug，浏览器支持情况也很不好，如果使用了很可能造成页面更新不了的情况
需要增加工作量和风险
这种方案放弃了。

另一种方案是基于 VasSonic 的基础上，VasSonic做了很多优化，但是使用APP的request而不是使用webview的request可以加速页面的加载， 另外使用预先DNS解析也剩下了一部分时间，等等很多。很多优化我们都可以直接拿来用。

我们的思路就变成了：

css、js、图片等静态资源使用webview的缓存来进行
当html页面加载完成后我们使用native的能力进行缓存，下次直接先从缓存中读取
当app启动或者进入活动状态的时候我们检查更新
每次先从缓存读取显示，然后后台更新html页面
这种方式基本上解决几个问题：

除了第一次页面基本上显示不受网络影响
即使server给的html页面是动态的，也能相对及时的更新
现有的server和现有的前端工作量基本上不变
离线也可以展示内容
但是这种思路引出了一些问题：

如果页面更新频繁，用户会有可能，多看一次更新前的页面，个人觉得影响不是很大，就行不刷新页面看不到新的更新内容一样
app需要消耗更多的资源，只是用户不可感知罢了
针对这些问题我们可以增加如下两种思路缓解：

增加页面更新通知，让APP主动更新已经cache的页面（如果页面数据都是ajax获取的话，只需在html发布新版的时候，给app发通知即可）另外app只需更新已经缓存的页面量并不是很大
增加雨缓存配置，在app第一次启动后，更新需要预cache的页面可能只是app内需要打开的某几个页面
这样极大的减少了app打开旧页面的概率，但是也增加了app预加载的数量，如果app使用周期比较长，这几个页面的流量只有html页面并不是很大。

总结

该方案只是理论上感觉很不错，但是需要实际验证，犹豫现在时间比较紧张，后续做成IOS和android的sdk，只需要配置就可以使用。如果谁的工作量不包含的话可以先开发一版试试看！