以我们的demo为例，关于业务频道demo的所有静态资源全部走线上，有效减少APP包大小，公共文件或者框架文件在APP中全部走本地，因为核心框架一般比较大，这里可以提升70%以上的载入速度。

有缓存策略就会有更新策略，事实上这里的更新策略涉及到在线发版等功能，这个工作是非常重的，如果说之前的工作前端与Native就能完成的话，那么这个工作会有server端的同事参加，还有可能形成一个功能庞大的发布平台。

最简单的模拟，就是每次Native大版本发布都会有一个版本映射表：

flight: 1.0.0, hotel: 1.0.0, libs: 1.0.0, static: 1.0.0 }

其中每个，如果某一天我们发现了机票频道一个BUG，发布了一个增量包，那么机票的版本就会增加：

//bug修复 flight: 1.0.1 //功能发布 flight: 1.1.0

对于这个版本，后台数据可可能会有这么一个映射：

channel ver md5

flight 1.0.0 1245355335

hotel 1.0.1 455ettdggd

每一个md5值对应着一个实际存在的增量包，在CDN服务器上，每次APP启动，就会检查server端的版本号是不是一致，如果不一致就需要重新拉取zip包，然后更新本地版本号：

这个是比较简单的场景，以一个频道为单位的更新，没有做到粒度更细，安全性方面一般情况我们也不必关心有人会篡改你的zip包（比如开发商），在你app流量不大的情况，没人有那么蛋疼，但是我们要考虑开发人员发布的zip包在某个环节出了问题的情况，一般来说，我们的打包程序会根据每个文件形成一个md5清单，比如这个样子的：

Native拿到后会去检查这个清单所有的文件是否完整，如果不完整就有问题，需要打日志预警放弃这次更新。

我们这里由于暂时没有Server端的参与，不能做发布系统，所以暂时是将版本信息放到了项目根目录做简单实现，这里还包含三个频道的zip包：

PS：真实场景更复杂更严谨

{ : , : , : }

我们现在把更新做到了这个页面：

这里的流程是：

1 点击检查更新首先检查Native里面有没有hybrid_ver.json这个文件，没有就去下载，完了拿到json串把对应文件全部下载下来解压：

{ "blade": "1.0.0", "static": "1.0.0", "demo": "1.0.0" }

对应规则是：

http://yexiaochai.github.io/Hybrid/webapp/blade.zip http://yexiaochai.github.io/Hybrid/webapp/static.zip http://yexiaochai.github.io/Hybrid/webapp/demo.zip

PS：这里真实情况下其实对应的是md5的压缩包，我们这里不去纠结。

如果第二次你点击，这个时候本地有hybrid_ver.json文件了，你再去远端获取这个文件，对比三个频道的版本号，这个时候是一样的，所以不会拉取。

如果我们改动了demo文件中的某个文件，比如加了一个alert什么的，这个时候就重新形成一个zip包，然后你把demo的版本号加大，比如这样：

{ "blade": "1.0.0", "static": "1.0.0", "demo": "1.0.1" }

他就该拉取demo的增量包，再次进入系统的时候便能看到更新了。

与上次文章对比，我们这次在一些Hybrid设计的细节点把握的更多，希望此文能对准备接触Hybrid技术的朋友提供一些帮助，关于Hybrid的系列还会有最后一篇实战类文章介绍，有兴趣的朋友持续关注吧，这里是一些效果图：

微博求粉

最后，我的微博粉丝极其少，如果您觉得这篇博客对您哪怕有一丝丝的帮助，微博求粉博客求赞！！！