什么是Web缓存

Web缓存是指一个Web资源（如html页面，图片，js，数据等）存在于Web服务器和客户端（浏览器）之间的副本。缓存会根据进来的请求保存输出内容的副本；当下一个请求来到的时候，如果是相同的URL，缓存会根据缓存机制决定是直接使用副本响应访问请求，还是向源服务器再次发送请求。比较常见的就是浏览器会缓存访问过网站的网页，当再次访问这个URL地址的时候，如果网页没有更新，就不会再次下载网页，而是直接使用本地缓存的网页。只有当网站明确标识资源已经更新，浏览器才会再次下载网页。至于浏览器和网站服务器是如何标识网站页面是否更新的机制，将在后面介绍。

Web缓存的作用

使用Web缓存的作用其实是非常显而易见的：

减少网络带宽消耗

无论对于网站运营者或者用户，带宽都代表着金钱，过多的带宽消耗，只会便宜了网络运营商。当Web缓存副本被使用时，只会产生极小的网络流量，可以有效的降低运营成本。

降低服务器压力

给网络资源设定有效期之后，用户可以重复使用本地的缓存，减少对源服务器的请求，间接降低服务器的压力。同时，搜索引擎的爬虫机器人也能根据过期机制降低爬取的频率，也能有效降低服务器的压力。

减少网络延迟，加快页面打开速度

带宽对于个人网站运营者来说是十分重要，而对于大型的互联网公司来说，可能有时因为钱多而真的不在乎。那Web缓存还有作用吗？答案是肯定的，对于最终用户，缓存的使用能够明显加快页面打开速度，达到更好的体验。

Web缓存的类型

在Web应用领域，Web缓存大致可以分为以下几种类型：

数据库数据缓存

Web应用，特别是SNS类型的应用，往往关系比较复杂，数据库表繁多，如果频繁进行数据库查询，很容易导致数据库不堪重荷。为了提供查询的性能，会将查询后的数据放到内存中进行缓存，下次查询时，直接从内存缓存直接返回，提供响应效率。比如常用的缓存方案有memcached等。

服务器端缓存

代理服务器缓存

代理服务器是浏览器和源服务器之间的中间服务器，浏览器先向这个中间服务器发起Web请求，经过处理后（比如权限验证，缓存匹配等），再将请求转发到源服务器。代理服务器缓存的运作原理跟浏览器的运作原理差不多，只是规模更大。可以把它理解为一个共享缓存，不只为一个用户服务，一般为大量用户提供服务，因此在减少相应时间和带宽使用方面很有效，同一个副本会被重用多次。常见代理服务器缓存解决方案有Squid等，这里不再详述。

CDN缓存

CDN（Content delivery networks）缓存，也叫网关缓存、反向代理缓存。CDN缓存一般是由网站管理员自己部署，为了让他们的网站更容易扩展并获得更好的性能。浏览器先向CDN网关发起Web请求，网关服务器后面对应着一台或多台负载均衡源服务器，会根据它们的负载请求，动态将请求转发到合适的源服务器上。虽然这种架构负载均衡源服务器之间的缓存没法共享，但却拥有更好的处扩展性。从浏览器角度来看，整个CDN就是一个源服务器，从这个层面来说，本文讨论浏览器和服务器之间的缓存机制，在这种架构下同样适用。

浏览器端缓存

浏览器缓存根据一套与服务器约定的规则进行工作，在同一个会话过程中会检查一次并确定缓存的副本足够新。如果你浏览过程中，比如前进或后退，访问到同一个图片，这些图片可以从浏览器缓存中调出而即时显现。

Web应用层缓存

应用层缓存指的是从代码层面上，通过代码逻辑和缓存策略，实现对数据，页面，图片等资源的缓存，可以根据实际情况选择将数据存在文件系统或者内存中，减少数据库查询或者读写瓶颈，提高响应效率。

Web浏览器的缓存机制

Web缓存的工作原理

所有的缓存都是基于一套规则来帮助他们决定什么时候使用缓存中的副本提供服务（假设有副本可用的情况下，未被销毁回收或者未被删除修改）。这些规则有的在协议中有定义（如HTTP协议1.0和1.1），有的则是由缓存的管理员设置（如DBA、浏览器的用户、代理服务器管理员或者应用开发者）。

浏览器端的缓存规则

对于浏览器端的缓存来讲，这些规则是在HTTP协议头和HTML页面的Meta标签中定义的。他们分别从新鲜度和校验值两个维度来规定浏览器是否可以直接使用缓存中的副本，还是需要去源服务器获取更新的版本。

新鲜度（过期机制）：也就是缓存副本有效期。一个缓存副本必须满足以下条件，浏览器会认为它是有效的，足够新的：

含有完整的过期时间控制头信息（HTTP协议报头），并且仍在有效期内；
浏览器已经使用过这个缓存副本，并且在一个会话中已经检查过新鲜度；

满足以上两个情况的一种，浏览器会直接从缓存中获取副本并渲染。

校验值（验证机制）：服务器返回资源的时候有时在控制头信息带上这个资源的实体标签Etag（Entity Tag），它可以用来作为浏览器再次请求过程的校验标识。如过发现校验标识不匹配，说明资源已经被修改或过期，浏览器需求重新获取资源内容。

浏览器缓存的控制

使用HTML Meta 标签

Web开发者可以在HTML页面的<head>节点中加入<meta>标签，代码如下：

1	<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

上述代码的作用是告诉浏览器当前页面不被缓存，每次访问都需要去服务器拉取。使用上很简单，但只有部分浏览器可以支持，而且所有缓存代理服务器都不支持，因为代理不解析HTML内容本身。

可以通过这个页面测试你的浏览器是否支持：Pragma No-Cache Test 。

使用缓存有关的HTTP消息报头

一个URI的完整HTTP协议交互过程是由HTTP请求和HTTP响应组成的。有关HTTP详细内容可参考《Hypertext Transfer Protocol — HTTP/1.1》、《HTTP协议详解》等。

在HTTP请求和响应的消息报头中，常见的与缓存有关的消息报头有：

Cache-Control与Expires

Cache-Control与Expires的作用一致，都是指明当前资源的有效期，控制浏览器是否直接从浏览器缓存取数据还是重新发请求到服务器取数据。只不过Cache-Control的选择更多，设置更细致，如果同时设置的话，其优先级高于Expires。

Last-Modified/ETag与Cache-Control/Expires

配置Last-Modified/ETag的情况下，浏览器再次访问统一URI的资源，还是会发送请求到服务器询问文件是否已经修改，如果没有，服务器会只发送一个304回给浏览器，告诉浏览器直接从自己本地的缓存取数据；如果修改过那就整个数据重新发给浏览器；

Cache-Control/Expires则不同，如果检测到本地的缓存还是有效的时间范围内，浏览器直接使用本地副本，不会发送任何请求。两者一起使用时，Cache-Control/Expires的优先级要高于Last-Modified/ETag。即当本地副本根据Cache-Control/Expires发现还在有效期内时，则不会再次发送请求去服务器询问修改时间（Last-Modified）或实体标识（Etag）了。

一般情况下，使用Cache-Control/Expires会配合Last-Modified/ETag一起使用，因为即使服务器设置缓存时间, 当用户点击“刷新”按钮时，浏览器会忽略缓存继续向服务器发送请求，这时Last-Modified/ETag将能够很好利用304，从而减少响应开销。

Last-Modified与ETag

你可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag（实体标识）呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：

Last-Modified标注的最后修改只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的新鲜度
如果某些文件会被定期生成，当有时内容并没有任何变化，但Last-Modified却改变了，导致文件没法使用缓存
有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形

Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符，能够更加准确的控制缓存。Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304。Etag的服务器生成规则和强弱Etag的相关内容可以参考，《互动百科-Etag》和《HTTP Header definition》，这里不再深入。

用户操作行为与缓存

用户在使用浏览器的时候，会有各种操作，比如输入地址后回车，按F5刷新等，这些行为会对缓存有什么影响呢？

通过上表我们可以看到，当用户在按F5进行刷新的时候，会忽略Expires/Cache-Control的设置，会再次发送请求去服务器请求，而Last-Modified/Etag还是有效的，服务器会根据情况判断返回304还是200；而当用户使用Ctrl+F5进行强制刷新的时候，只是所有的缓存机制都将失效，重新从服务器拉去资源。

哪些请求不能被缓存？

无法被浏览器缓存的请求：

HTTP信息头中包含Cache-Control:no-cache，pragma:no-cache，或Cache-Control:max-age=0等告诉浏览器不用缓存的请求
需要根据Cookie，认证信息等决定输入内容的动态请求是不能被缓存的
经过HTTPS安全加密的请求（有人也经过测试发现，ie其实在头部加入Cache-Control：max-age信息，firefox在头部加入Cache-Control:Public之后，能够对HTTPS的资源进行缓存，参考《HTTPS的七个误解》）
POST请求无法被缓存
HTTP响应头中不包含Last-Modified/Etag，也不包含Cache-Control/Expires的请求无法被缓存

如何构建可缓存站点

前面了解了Web缓存的运行机制极其重要性之后，我们可以从以下这些方面去努力改善我们的站点，保证缓存被最有效的利用，达到最佳的性能。

同一个资源保证URL的稳定性

URL是浏览器缓存机制的基础，所以如果一个资源需要在多个地方被引用，尽量保证URL是固定的。同时，比较推荐使用公共类库，比如Google Ajax Library等，有利于最大限度使用缓存

给Css、js、图片等资源增加HTTP缓存头，并强制入口Html不被缓存

对于不经常修改的静态资源，比如Css，js，图片等，可以设置一个较长的过期的时间，或者至少加上Last-Modified/Etag，而对于html页面这种入口文件，不建议设置缓存。这样既能保证在静态资源不变了情况下，可以不重发请求或直接通过304避免重复下载，又能保证在资源有更新的，只要通过给资源增加时间戳或者更换路径，就能让用户访问最新的资源

减少对Cookie的依赖

过多的使用Cookie会大大增加HTTP请求的负担，每次GET或POST请求，都会把Cookie都带上，增加网络传输流量，导致增长交互时间；同时Cache是很难被缓存的，应该尽量少使用，或者这在动态页面上使用。

减少对HTTPS加密协议的使用

通过HTTPS请求的资源，默认是不会被缓存的，必须通过特殊的配置，才能让资源得到缓存。建议只对涉及敏感信息的请求使用HTTPS传输，其他类似Css，Js，图片这些静态资源，尽量避免使用。

多用Get方式请求动态Cgi

虽然POST的请求方式比Get更安全，可以避免类似密码这种敏感信息在网络传输，被代理或其他人截获，但是Get请求方式更快，效率更高，而且能被缓存，建议对于那些不涉及敏感信息提交的请求尽量使用Get方式请求

动态CGI也是可以被缓存

如果动态脚本或CGI输入的内容在一定的时间范围内是固定的，或者根据GET参数相同，输入的内容相同，我们也认为请求是可以被缓存的，有以下几种方式，可以达到这个效果：

让动态脚本定期将内容改变时导出成静态文件，Web直接访问带有Last-Modified/Etag的静态文件
开发者可以通过代码给动态脚本的响应头中添加Cache-Control: max-age，告诉浏览器在过期前可以直接使用副本
通过代码给动态脚本的响应头添加Last-Modified/Etag信息，浏览器再次请求的时候，可以通过解析If-Modified-Since/If-None-Match得知浏览器是否存在缓存，由代码逻辑控制是否返回304

如何给站点增加缓存机制

HTTP请求/响应头中缓存报头对有效利用站点缓存，作为一个Web前端开发者，我要做什么呢？答案是：啥都不用做。不过要去推动Web运营人员、Web后端开发人员分别给服务器和动态脚本CGI增加合适的缓存报头。

服务器配置

Apache相关配置参考：mod_headers、mod_headers

编写可缓存的动态脚本

服务器配置的方法比较简单通用，但是如果遇到没有权限修改服务器配置或者需要添加更细致的Expires/Cache-Control/Etag等信息时，不妨可以试试从代码层面去添加这些信息。不同语言写法实现略有不同，但思路都是一致的。可以在单独开辟一个独立模块，调用语言库提供的添加报头的接口，根据需要设置报头信息。当某个请求的动态脚本需要被缓存时，可以采用类似include，require等模块引用方式调用公共模块，实现缓存机制。

Php实现代码实例如下：

Cache.php

<?php
Header(“Cache-Control: must-revalidate”);

$offset = 60 * 60 * 24 * 3;
$ExpStr = “Expires: ” . gmdate(“D, d M Y H:i:s”, time() + $offset) . ” GMT”;
Header($ExpStr);
?>

<?php

Require(Cache.php)

// business code here

// todo

HTML5时代的Web缓存机制

随着现代浏览器的推动，Flash放弃对移动端的支持，HTML5无疑成为当前Web前端炙手可热的话题。各大游戏开发商、App开发商纷纷投入人力进行研究和技术储备。相信不久的将来，HTML5会迎来一个快速发展和普及的春天。那么，HTML5这个新一代的标准，又给我们带来哪些缓存机制呢？

HTML5 之离线应用Manifest

我们知道，使用传统的技术，就算是对站点的资源都实施了比较好的缓存策略，但是在断网的情况下，是无法访问的，因为入口的HTML页面我们一般运维的考虑，不会对其进行缓存。HTML5的Cache Manifest离线应用特性就能够帮助我们构建离线也能使用的站点，所有的资源都使用浏览器本地缓存，当然前提是要求在联网的情形下使用过一次站点。

如何实现离线访问特性

实现的步骤非常简单，主要3个步骤：

1）在服务器上添加MIME TYPE支，让服务器能够识别manifest后缀的文件

AddType text/cache-manifest manifest

2）创建一个后缀名为.manifest的文件，把需要缓存的文件按格式写在里面，并用注释行标注版本

CACHE MANIFEST

# 直接缓存的文件

CACHE:

Path/to/cache.js

# version：2012-03-20

3）给 <html> 标签加 manifest 属性，并引用manifest文件

具体可以参考：HTML5 缓存: cache manifest

离线应用访问及更新流程

第一次访问离线应用的入口页HTML（引用了manifest文件），正常发送请求，获取manifest文件并在本地缓存，陆续拉取manifest中的需要缓存的文件
再次访问时，无法在线离线与否，都会直接从缓存中获取入口页HTML和其他缓存的文件进行展示。如果此时在线，浏览器会发送请求到服务器请求manifest文件，并与第一次访问的副本进行比对，如果发现版本不一致，会陆续发送请求重新拉取入口文件HTML和需要缓存的文件并更新本地缓存副本
之后的访问重复第2步的行为

离线机制的缓存用途

从Manifest的机制来看，即使我们不是为了创建离线应用，也同样可以使用这种机制用于缓存文件，可以说是给Web缓存提供多一种可以选择的途径。

存在的问题：缓存文件更新控制不灵活

就目前HTML5提供的manifest机制来讲，一个页面只能引用一个manifest页面，而且一旦发现这个manifest改变了，就会把里面所有定义的缓存文件全部重新拉取一遍，不管实际上有没有更新，控制比较不灵活。针对这个问题，也有的同学提出了一些建议，比如把需要缓存的文件分模块切分到不同manifest中，并分开用HTML引用，再使用强大的iframe嵌入到入口页面，这样就当某一个模式需要有更新，不会导致其他模块的文件也重新拉取一遍。

HTML5 之本地存储localstorage

HTML5给我们提供本地存储localstorage特性，严格来讲，其实已经不算传统Web缓存的范畴。因为它存储的地方是跟Web缓存分开的，是浏览器重新开辟的一个地方。

localstorage的作用

本地存储localstorage的作用主要使Web页面能够通过浏览器提供的set/get接口，存储一些自定义的信息到本地硬盘，并且在单次访问或以后的访问过程中随时获取或修改。

Localstorage的使用

Localstorage提供了几个非常易用的Api，setItem/getItem/removeItem/clear，具体的可以参考：Html5 Step by Step(二) 本地存储

Localstorage的缓存用途

Localstorage设计的本意可能是用来存储一些用户操作的个性化设置的文本类型的信息和数据，当我们其实也可能拿来当Web缓存区使用，比如我们可以将Base64格式编码的图片信息，存在localstorage中，再次访问时，直接本地获取后，使用Css3的Data:image的方式直接展现出来。

存在的问题：大小限制

按照目前标准，目前浏览器只给每个独立的域名提供5m的存储空间，当存储超过5m，浏览器就会弹出警告框。

可以说，HTML5的Manifest和localstorage是给我们在考虑Web缓存的时候提供了多一种思路，当你开发的应用只面对现代浏览器的时候，不妨可以考虑一下。

Web App时代的缓存机制新思路

Web App的概念逐渐被业界认可，各大互联网公司也纷纷推出Web App开发大赛，积极引入到他们的开放平台，比较著名类似facebook农场，qzone偷菜之类的。Web开发逐渐从Web Page的进入到Web App的时代，想详细了解的话，可以看下超叔在D2上分享的分享《开放时代：从Web Page到Web APP》视频、Slide。

Web App常见架构

以WebQQ例，WebQQ这个站点的所有内容都是一个页面里面呈现的，我们看到的类似windows操作系统的框架，是它的顶级容器和框架，由AlloyOS的内核负责统筹和管理，然后其他模块，比如壁纸设置，消息中心，App Store都是以模块的形式，并用iframe的方式嵌入到顶级容器中。具观察，现在越来越多的Web应用都倾向于使用这个的架构，这样做好处是很明显的，比如顶级框架可以维持一个不变的javascript上下文便于管理；关闭模块的iframe后，内存可以更好的释放；利用iframe的安全机制最大限度的保证内核的安全和稳定等等。

这种Web的架构，其实也给我们Web前端提供了从代码逻辑层面上给Web应用实现缓存提供了可能。

缓存Ajax请求

由于顶级框架页面是不会由于调整刷新而导致javascript上下文丢失，所以底层或各个模块所需要的Ajax请求，都是可以通过顶级框架统一请求后，并以信息服务的形式对外提供Api调用。对于一些实时性要求不是很强的请求来说，可以由顶级框架做统一缓存，定期更新。这种做法可以不影响用户体验的前提下，明显减少请求数，降低网络流量，并间接减轻了服务器的压力。

通过Javascript实现内存缓存

跟缓存Ajax请求的结果类似，程序运行过程中的其他数据，其实也可以采用类似的方式在顶级容器的Javascript上下文中缓存。

Web App发展新方向：Web-Client模式

随着Web App的进一步发展，貌似浏览器已经无法阻挡Web应用探索更前端，更本地化Native App的用户体验。比如目前的Qplus、豆瓣荚等应用，都采用Client、Web相结合的开发模式。这样做即可以利用Web开发迭代更新快、UI开发成本低等特点，有可以利用客户端的能力为Web实现很多无法实现的功能。以Qplus为例，Qplus不但内嵌了Webkit内核，还未Webkit上定制了很多便利的接口，比如跨Web-Client的拖曳、多线程下载等。在这种发展新模式下，Web缓存又能有什么考虑的发张方向呢？

客户端提供缓存读写能力

我们知道，HTML5的localstorage仅仅只能支持5m的存储。我们可以按localstorage的设计思路，让客户端为Web定制更大，更灵活的本地存储功能。到时，Web缓存能做的事情就会更多。

以上就当前Web App的发展趋势，讨论了对于Web缓存领域，有哪些可以做，可以考虑的方向。当然，这些做法，合不合理，合不合适都还是值得讨论和商榷的，如果你有想法，都可以随时联系并一起讨论。

全文总结

本文尝试概述目前Web缓存方向的现状，以及HTML5和Web App时代下，Web缓存可以考虑的新方向。由于时间仓促和表达概括能力有限，有可能有表达不妥的地方，欢迎指正讨论。

进击的Hybrid App，量身定做缓存机制

前言

前面的文章分别简述了Web缓存、相关机制、以及 html5 和 Web App 时代我们可以选择的缓存思路。转眼过了很长时间，这期间移动互联网成为大家讨论和学习的焦点，部门也有很多同学陆续接触 Mobile Native App 和 Mobile Web App 的开发。同时，还有部分同学专注 QQ 内嵌 Webkit + Client 这种Hybrid App模式的开发，继续推动 QQ 客户端 Web 化的进程。

引用张图，简单粗俗的解释下 Native App、Web App 和 Hybrid App

Navtie App： 使用平台系统提供的原生语言来编写的 App，如果Android用java，ios用objective-c，windows c++等

Web App：主要使用 Web 技术js/html/css进行编写，运行在各平台系统浏览器或浏览器组件中

Hybrid App：混合使用前面两种技术，部分代码以 Web 技术编写，部分代码由某些 Native Container 承担（如 Phongap 插件，PC/手机 QQ客户端等）

现有的缓存机制及问题

移动互联网网速慢、QQ 客户端对 Web 模块可用性要求高，使得我们不管做 Mobile Web App 开发、还是 PC Web App 开发，都必须对 Web 缓存有更深入的理解和利用。PC QQ 和手机 QQ 都有基本 Webkit 的 Webview，除了传统常规提到的缓存外，参阅《Web浏览器的缓存机制》，我们最先想到的优化方案就是前面文章提到的 Html5 App Cache，Web Storage，详细请参阅《HTML5时代的Web缓存机制》和《Web App时代的缓存机制新思路》。

但，使用的过程中，我们发现了一些关于 html5 app cache 的问题：

1、第一次必须联网，在移动网络下首次打开效果非常不理想

2、http 头设置会导致 manifest 无法正常更新，见 http://www.alloyteam.com/2012/01/html5-offline-app-update-problem/

3、Manifest 中缓存文件一旦下载出错，后续的文件将不再下载，抛出错误事件，见：http://stackoverflow.com/questions/6666513/html5-manifest-caching-error

4、Android 系统版本众多，较低版本的浏览器对 manifest 支持不完善

5、引用 manifest 的 html 页面本身也会被缓存

6、《慎用manifest》一文提到的如：页面的参数传递、manifest 的发布、回滚、下线等问题

从上面可以看出，html5 虽然提供基于 manifest 这种离线缓存的机制，但在实际运用过程中还是会遇到非常多的问题，于是，我们开始思考，既然是 hybrid app，与其花大量时间踩坑，有资源有条件，不如更激进一点，尝试利用客户端能力来量身定做一套自己适用的缓存机制。于是 Alloykit 诞生了。

关于 Alloykit

Alloykit 是 PC/手机 QQ 上基于 Webview 开发的一个方便易用的开发组件，能够使基于 Webkit 开发的模块，快速拥有 Web 资源本地化、Common Api、自动种入登录态和续期、诊断上报、DNS管理、开发者工具支持、关键性能数据上报等特性。

Alloykit 各模块及主要功能：

本地化模块：把静态资源下载到本地，然后通过访问本地资源代替去服务器请求

Common Api模块：对常用共性的 Client 接口进行封装，Web可以内嵌 Commonapi.js 进行方便调用

登录态管理模块：web 登录态自动续期，登录态拉取失败走 Pt 跳转

诊断上报模块：诊断修复用户问题（清缓存，DNS，重新加载页面），截屏并收集用户本机网络信息，上报到后台进行分析。

DNS管理模块：域名预加载，域名 ip 验证等

开发模式：开发模式开关，开发者调试工具支持

数据上报：通用控件在不同业务中的关键上报点

下面主要介绍一下本地化缓存模块的设计思路，后面有机会再单独介绍其它的模块。

本地化模块

用一张图大致示意如下：

由上图可以看出，本地化模块主要由下面两个子模块组成：

1、拦截器：采用的一种类似 Fiddler AutoResponse 的本地替换思路，通过拦截所有 web 请求，进行本地化资源匹配，命中则用本地资源直接替换，否则，正常发起请求。

2、更新器：根据更新策略进行新版本资源检测，负责下载和维护本地缓存目录中的资源，并将更新过程关键点通过事件通知到 Web 页面备用。

原理很简单，使用也很简单，主要分为以下几个步骤：

1、客户端开发阶段：新建窗口的时候，只需要通过配置文件，将窗口类型声明为 AlloykitWindow

2、前端开发阶段：开发过程透明，不需要任何特殊处理

3、前端发布阶段：打包静态资源 zip 包

把业务涉及到并且希望离线的域名和资源打包，假设你的页面用到了web.qq.com、cdn.qq.com、test.statics.qq.com等域名，如下图所示，为每个域名建一个目录（若只有一个域名，则只建立一个目录），然后按照资源的url建立各级子目录并把资源放到相应的子目录下。

比如你有这样一个html页面：http://web.qq.com/module1/helloworld.html

把需要离线的页面文件和图片资源放到目录web.qq.com/module1下即可，如图：

使用 zip 压缩软件，将所有资源打包为一个 zip 包。

4、运维发布阶段：

正常发布线上资源
登录资源包管理平台，提交对应 zip 包
需要打包到客户端安装包的资源，单独提交给客户端开发负责打包

Alloykit 本地化和 H5 manifest 对比

1、Alloykit 可以选择将关键页面直接打包到客户端或App安装包，首次打开不需要依赖网络条件

2、对于没有打包到安装包的页面，也可以通过配置，让客户端启动后提前加载资源包

3、Alloykit 开发过程体验更简单，基本透明

4、Alloykit 把所有资源打包为一个 zip 包进行下载，更高效

5、Alloykit 通过客户端提供的基于 tcp 的下载通道进行下载，并有重试机制，更加稳定可靠

6、Alloykit 可以通过自身封装，支持多平台，避免开发者兼容多平台带来的麻烦

7、Alloykit 可以通过协议的设计，轻松实现刷新缓存、封版、下线离线特性等功能

这个本地化机制目前已有模块开始试用，在享受量身定制的缓存机制带来的性能提升和开发便利的同时，我们开始遇到并思考本地化之后的一些问题。

本地化之后

1、本地化文件的安全问题

缓存目录中本地文件，第三方是有办法找到并进行强制修改，可能存在不安全的因素。有同学可能会说这个担心其实多此一举，比如 Chrome Cache 文件写入磁盘的算法是开源的，如果第三方（类似 ChromeCacheView）软件实现了这个算法，就能对缓存文件进行修改，也存在类似安全问题。话虽如此，可是还是要做最坏的打算，说不定哪天数字搞你一下。要设计一种机制做保障。这种提供两种思路：

1）设计一种类似 Chrome Cache 闭源算法，把获取的资源包以这种算法读写入本地磁盘上。

2）使用非对称加密算法

客户端开发的时候，内嵌私钥

资源包 zip 中加入一个包含所有文件 md5 信息的json文件，并使用对应的公钥进行加密

客户端获取 zip 包后，使用私钥对 json 文件解密，获取 md5 信息，逐个进行校验

2、Web 项目运营思路转变

Web 项目一旦使用了本地化特性，不管是 H5 的 manifest 还是 Alloykit ，都会存在滞后一次更新，所以始终都会存在旧版本的长尾问题。所以这类型的项目给运营提出了更高的要求：

1）后台 CGI 接口，尽量考虑向前兼容，保证协议结构不变，如果确实需要改动，建议启用新路径

2）前端资源文件，建议采用增量的形式发布，比如 main.js ，发布的时候建议编译成 main-****.js（一般使用时间戳或md5后8位）

这样做的好处很明显，可以最大限度避免发布引起的波动，同时也可以支持 web 项目多版本并存，避免多版本相互影响。使用 grunt 或 modjs 可以轻松完成这个自动化构建编译工作。

3）Web 版本的铺量速度有所下降，所以对版本质量的要求更高，不建议太频繁、未经严格测试的版本发布

可见是否使用本地化，也需要做慎重的考虑，在性能和各个方面做权衡。

3、本地化之后的可用性问题

Alloykit 本地化之后，理论上在断网的情况下，页面也是打开的。但是要保证页面可用，其实还有很长的路要走。

针对那种单机的 h5 游戏或者简单页面，其实无需任何处理就能保证离线的访问效果。但，目前完全单机的 Web App 基本是不存在，大量的动态的数据和社会化的交互。如果本地化之后不做任何处理，那么在离线的情况下，基本也是只有页面框架，大量的页面空白和 ajax 请求超时，基本也相当于不可用。那么，花了这么大力气定制的本地化机制就仅仅保证打开的时候可看不可用吗？有什么办法可以改善吗？

答案是有的，这时 Web Storage 和 Web Database 就可以派上用场了，详细使用可以 Google 或者参考索引中的第4、5篇文章。

一些典型的离线场景及处理方案：

1）离线写操作：将 Ajax 请求以及相关参数保存到 localStorage 队列中，网络上线后，触发执行队列中的操作

2）离线读操作：页面上有需要通过 Ajax 获取动态的数据或远程图片进行渲染的块，可以通过前端 hardcode 一些默认数据，并且将最近一次 ajax 结果存储到 localStorage 中，图片可以转为 base64 字符串才用同样的方式处理

localStorage 有同源限制，大小也有限制，并且只能存储字符串，需要存储图片需要进行转化，比较繁琐耗性能。可否跟激进一些，由客户端提供模拟 localStorage，自行开辟存储空间，提供接口进行存取和校验？完全是可行的，并且现在在一些 Mobile 的项目中进行了相关尝试，接口整合到 CommonApi 模块中。

总结

独立于标准之外重复制造轮子，本身不是太推荐的做法。在目前标准和平台支持未完善，以及在特定场景下有欠缺的情形下，资源允许，我们选择了尝试新方法，针对Hybrid App 这种特殊的运用场景定制了一种本地化缓存和存储的实现方案。时间仓促，方案本身仍处于测试阶段，某些方面考虑难免会有欠考虑，非常欢迎同学们留言指出、改进。

缓存方案