web+native客户端静态资源内置与动态更新

       现在移动互联网很火，各个公司貌似都比较重视这一快，因为这又是一个增长点，据我们的用户日志分析，发现我们公司的APP用户和PC用户交集不是太大，并且服务器的负载在晚间是最高的，8核CPU。top load average达到将近12，这也说明用户喜欢晚上躺在床上玩玩APP，闲话说的太多，如果有对这方面感兴趣的话，可以给我发站内信，我们可以讨论下，实际上用户行为分析确实挺有意思的，好吧，到此为止，进入正题。

       由于我们的客户端是web+native方式实现的，这种机制我个人觉得现在还不成熟，用户体验相对而言不是太好，但对于版本迭代比较方便。机制是基础，想改变也不是那么容易，竟然不能改变，那就从容接受，先一步一步的优化吧，尽量提高用户体验，大家都知道，手机上网用户大部分还是2g，所以下载速度是个很现实到问题，所以应该尽量让用户少下载或者和少和服务器交互，对于web开发的应该想到了浏览器缓存和静态资源压缩，这里我就不讲压缩优化了，主要谈谈本地缓存，我们可以把不经常变的资源内置到客户端，客户端通过webview加载页面的时候可以判断本地有没有，有的话那直接用本地的资源，没有那就从服务器上下载，这样可以减少很多的HTTP请求，比如一个用户少10个http请求，那100W用户就是1000W个请求，这也减轻了服务器的压力，对于哪里可以内置到资源，我们可以选择 图片 js css 还有一些静态页面以及api接口数据，服务器端一次性全提供给客户端，内置成功后打包然后发包，我们写了一个内置资源后台管理系统，前端工程师需要内置哪些资源，他直接在后台录入，然后提供一个资源列表给客户端，这样把内置的需求搞定来，算优化的第一步吧！下面的问题来了， PM的想法真的是天马行空，某一天，需求变更，前端工程师发现之前发出去的APP包的内置资源要更新，那现在怎么办？

        这种需求很多，我们确实要解决这个问题，对于web开发的工程师都知道，都会在html中js和css加上一个版本号，以便让浏览器不走本地缓存，对于服务器开发的RD应该想到乐观锁。

对于内置的资源，我们可以大体分为两类：

1.api接口数据：

如：请求的接口到url:http://******,结果如下

{
action: {
action: "加载页面",
title: "购物",
pagetype: "html",
url: "http://******?vers=2"
}
......
}

 

客户端会把第一次请求到的数据给缓存到本地，以供以后直接使用。对于这种情况，可以通过本地内置了的资源版本号ver和服务器上资源的版本号做对比，做出选择是否要更新，如上例：发现本地内置到接口数据中http://******?vers=1，现在获取到vers=2,那说明这个url对应到的内置页面需要更新。

2.对于html这样的web页面，

<link rel="stylesheet" href="http://***/static/css/test.css?vers=4" />

<script type="text/javascript" charset="utf-8" src="http://***/static/js/jq.mobi.min.js?vers=15"></script>

 

通过html里面引用资源的版本号vers和本地资源的vers做对比来确定是否需要更新。

第二个问题也可以解决了，但又出现了新问题，资源的下载有依赖怎么办？

       比如js1依赖js2，js2依赖js3，如果网络不稳定，用户只下载了js1，那客户端也一样不可用，特别对于html页面更新了，js和css没下载成功，那将是致命的问题，所以对于必须要更新的资源一定要做到原子性。

 

      整个更新的流程使我想到了数据库，想到了锁的粒度和原子性。