applicationCache

姜维花名：玄寂就职于一淘UX，长期奋斗在mobile端的前端工程师一枚首先大家可以到http://www.slideshare.net/pigcan/applicationcache查看本次分享的ppt。给大家描述一情形，当我们在无任何网络的情况下使用wifi版iPad用safari访问页面的时候会有如下提示“safari cannot open the page because it is not connected to the Internet”。safari提示你没有网络页面打不，那今天讲的主题就是如何解决这问题。所以今天分享的主题是applicationCache，离线缓存。这次分享将从个方面入手：第一个是applicationCache本身，第二个是我们H5项目上的一些实践。本次分享会偏向于更加实际一点实用一点，也更偏向于mobile方向，不蜻蜓点水只讲概念。首先回过头来思考一下我们一个网络应用通常情况下是有些部分组成的。我们可以试图归纳为如下组成点：HMTL文档，CSS文件，JS文件，媒体文件，本地数据和云端数据。那么applicationCache离线存储指带些文件？看如下ppt我们不难发现离线的存储指这些文件，也就是html文档，JS文件，CSS文件，ttf，以及媒体文件。不得不提的是在iOS5 始，safari mobile对媒体文件的离线缓存予以支持，并且存储过程被透明化，透明化指的是，一共需要下载多少文件，有几个文件还没有下载好，有几个文件已经下载完毕。离线存储把资源存储到本地，每次访问的时候直接从cache里面去取，这样我们的站点就完成了离线能访问的需求。 applicationCache实现的目标是：加快站点的访问速度；弥补用户当前网络的不给力——特是在mobile端大部分用户还处于“工业时代”，2G网络；快速地实现新资源的部署，如何

体现快速？之后会有讲到。首先来纵观下当前的应用情形，些应用有离线应用了？不难发现网络阅读浏览器杂志还有一些纯JS应用，比如说（计算器，游戏）等已经有成功案例，为何他们成为了试吃螃蟹的第一人？这些应用都有一个比较明显的特，他不会强烈涉及云端数据，侧重于本地。但是对于大部分站点而言，都有和云端数据有强烈的依赖系，比如我们在做的手机淘宝，它到底适合不适合把它做成离线的应用，这其实是有待于商榷的，用户所需信息全部需要实时来源于服务端，最后我会去分析applicationCache它到底适不适合我们。那如何把一个普通的页面变成一个可以支持离线存储的页面？方法非常非常简单，所有需要做的就只有把manifest当做html元素的一个属性写入文档同填写manifest真实路径即可。一切就这么简单，当然服务端需要对此支持（manifest的MIME）。例： CACHE MANIFEST #This is a comment js/demo.js images/demo.jpg NETWORK: images/demo2.jpg FALLBACK: images/1.png images/2.png CACHE: js/demo2.js 那Manifest文件到底是一个怎么样的文件？不难发现manifest是一个有需要特殊格式需求的资源清单文件。接下去我会更细致地来讲一下在使用中的一些需要注意的点和manifest所需的特殊格式。1.服务端需要指明manifest的MIME类型为text/cache-manifest；

2.manifest必须作为一个html的显示属性，并且其属性值必须声明manifest文件路径，该路径必须和承载它的html文档同源，同服务类型；3.applicationCache存储限制是5MB，根据域名来分配的，用户也给可以手动给其增加空间，一般在mobile端都有提供其系统级的设置选项;4.缓存的更新只建立在manifest文件本身发生更新；5.如果manifest文件中所列的任何一个文件下载失败，将导致缓存失败，导致缓存失败还可能因为DNS解析失败等。6. 于格式上需要注意点：在第一行必须写上CACHE MANIFEST，随后可以包含CACHE、FALLBACK，NETWORK等键字，当然还有注释，必须以“#”打头，注释必须为一行，不能是多行，如果存在多行，换行时请加上“#”。CACHE，它其实是一个隐式申明的字段，如果在一个清单文件里面没有一个键字段，那么这些文件都会被认识需要cache的文件，但是有一情况就是我们在书写的时候如果需要缓存的文件出现在的键字之后，就需要加上CACHE 键字（如例子所示）。NETWORK是一网络的白名单，它可以申明某一个文件必须需要通过网络访问，当然你也可以针对于某个文件夹，某个域名，甚至为一个“*”通配符，该符号的意思除了CACHE文件，另外所有文件都需要通过网络访问。FALLBACK更像是一策略，就是说某一个资源不能被下载完成的时候访问另外一个备选资源，但是这里必须指明的一点是，FALLBACK中所声明的任何内容必须与MANIFEST是同源的（同域同服务类型）。于服务端的配置。这里大概说一下，如何在MAC机里面给apache增加服务类型，。当然习惯了Windows的用户，一般习惯了显示来修改，可以用如下命令来显示隐藏文件1.“defaults write com.apple.finder AppleShowAllFiles -bool true” 2.“KillAll Finder”。 note：含有manifest属性的html文档无论有没有被显示的申明需要被CACHE或者NETWORK该HTML文档都会被CACHE，正由于此，项目将变的其繁琐，为什么这么说，因为比如手机淘宝而言，内容的更新完全出于用户卖家的更新，用户改了只是改了数据并没有改manifest文件，所以页面将不会更新，所以现有状态去做淘宝离线化，其不现

实，原因大家都懂得。如果给手机淘宝带来离线化存储这个问题就是最核心的问题。给一个页面应用上离线存储非常方便，那接下来说一下如何更新缓存，其实刚才也稍微提及了一点，主要有三方面： 1、用户手动清除了浏览器缓存。在mobile端，无论是iOS系统还是android系统内置浏览器都提供了清除的方法，但是一些定制机（安卓）在浏览器中进行清除，并不能真正清除缓存，需要到系统设置内清楚，这个在小米手机里面可以重现这个问题。 2、manifest文件发生更改。note：缓存更新一定是建立在Manifest文件它本身发生更改。 3、可以用程序的方式去进行缓存文件的更替。在程序方式中浏览器提供了一些自定义UI DOM事件： checking —— 客户端尝试更新，或者首次访问时试图下载manifest文件； noupate —— manifest文件未发生任何更改； downloading —— 客户端查询到更新并成功获取到，或者首次访问时资源文件下载ing； progress —— 客户端下载资源文件ing ； cached —— manifest所列文件全部被下载好，并被成功缓存； updateready —— manifest所列文件已经全部被重新下载好，同时脚本中可以使用方法swapCache()来更新缓存； obsolete —— manifest被发现已经更改为404或者410页面； error —— manifest是一个404或者410的页面，缓存过程被终止；manifest没有发生改变，但是引用它的页面并没有被正常下载；在获取manifest所列文件时发生致命错误；在更新过程中manifest文件又再次发生更改。另外还需要知道一点的是cache状态值，这个状态值反应了cache当前的状态。 checking —— 状态为2，更新始，逐字节比对manifest文件； noupate —— 状态为1，更新处理完成；

downloading —— 状态为3，表示始下载最新的资源； cached —— 状态为4，表示缓存更新已处理完成并已存储； updateready —— 状态为4，表示缓存更新已处理完成并已可用； obsolete —— 状态为5 ，application cache group obsolete； error —— 状态为0，表示有错误发生，manifest文件找不到或者资源找不到。另外还需要知道非常重要的一点是，这些自定义UI事件都发生在load事件执行完后。客户端首次访问含有manifest属性的站点的时候。首先进行的过程是如同没有manifest属性时候是一致的（文档与资源文件的下载），但是接下来会触发manifest清单所列文件的下载，这是个同步的过程，也满足HTTP CACHE的设计思想，也就是接下来manifest接下来下载资源文件的时候服务端讲返回304状态值。那那些自定义事件是如何执行的？浏览器检测到HTML里面有一个属性是Manifest，当页面load事件执行完后调用checking事件，情况一：我们之前从来没有访问过，首先会调用downloading事件，之后便始下载资源文件，然后调用Process这个事件，告诉有多少文件已经被下载好了，还也多少东西还有待与下载（这个有利于我们做下载进度条，ios5中始支持，安卓不支持）。如果下载都正常则最后调用cache事件，告知缓存已被成功缓存。情况二：我们之前访问过，它会把Manifest文件做一次逐字节对比，如果说没有更改，直接调用noupdate事件，就是说缓存已经不需要更新了。如果已经发生过改变了，它又会把上面的流程再走不遍，最后调用updateready事件，可以用如下方式进行缓存的更替(if(appCache ==appCache.UPDATEREADY{window.applicationCache.swapCache()})。这里要注意点是，1.在downloading下载资源过程中资源文件没有过期服务器还是会在下载过程中返回304状态值;2.使用程序方式更替缓存后，使用的还是老缓存，必须还需要刷新一次页面才会指向新的缓存堆。大家可能会有一些疑问，比如： web应用超过一张页面，那manifest属性只需要加在

home page上，还是全部需要加上？答案是每张页面都要加。再仔细来看看移动浏览器的支援情况。android2.1，iOS2.2，opera11。 tips - offline application for iOS <meta name="apple-mobile-web-app-capable" content="yes"> //全屏 <meta name="apple-mobile-web-app-status-bar-style" content="black"> //状态栏 <link rel="apple-touch-icon" href="/custom_icon.png"> // 面图标 <link rel="apple-touch-startup-image" href="/startup.png"> //启动画面接下来去说一下手机淘宝，当初定了方案，一是localstorage，另外一是applicationCache。首先我讲一下localStorage：网页上只加载一小段js，该js用来监测真实环境js状态（指明是否被成功存储）；如果没有被存储，那么js将被步请求，并存储；如果成功存储，则直接从localStorage中调用。（localStorage只能存储字符串，所以这边还需要做特殊处理）缺点可以很明显地发现，就是请求。如果我这个东西没有被下载好，就要发起请求。但是在mobile端http请求是最昂贵的东西。所以尽量要低请求数。然后针对于此想到了第二方案：情况一：没有与之相的cookie记录，判断为用户首次访问：则接下来资源文件形式则以变量 - 字符串形式输出到页面；情况二：存在含有版本信息的cookie记录，提交服务器与之对比之后发现无改变，则输出页面，前端自动调用存储在localStorage的资源文件；情况三：存在含有版本信息的cookie记录，提交服务器与之对比之后发现无改变，但是用户清除了缓存，也就是本地已经不存在相资源文件存储信息，但此时页面根据cookie记

录的信息也已经下来了没有相脚本的html页面。此时就需要步有序加载资源文件。为什么是有序，因为js完全可能存在依赖系；情况四：存在含有版本信息的cookie记录，提交服务器与之对比之后发现有改变，后端在页面输出的时候以变量字符串形式输出到页面，随后前端进行存储。情况五：在一切都顺利但是比较端的情况是，本地存储空间耗尽，此时需要单独发送请求，请求相资源文件，予以外链支持。其实这个方案是崩溃的，因为其杂，最终沛公之意还是解决applicationCache不能进行单点更新的问题，当然这不是不能做，而是在单位时间内去做一个庞大的事情成本过于庞大。note：另外于localStorage的测试结果为：主域与子域之间存储信息完全各自独立，不能相互访问！另外主域和各个子域均享有独立的存储空间，理论值为各自拥有5MB存储空间，实际会偏小一点。最后方案是applicationCache+localStorage：分离出数据层和基础资源文件层，数据层主要是ajax获得的数据，而我们利用的applicationCache缓存的是一个框架性的东西，基础HTML文档、JS文件、CSS文件、图片文件、字库文件ttf，以及可能需求的一些媒体文件，localStorage存一些系统信息，于字库文件，其实这里的字库是一个icon集合，我们把大量icon集合到一个字库文件，通过对应表来对应相应的icon，由于字体是矢量的这解决了为不同iPhone分辨率的适配问题。当然还少了http请求数。最最重要的是，字库把原有图片体积上足足可以小2分之一。当然这也存在一点点的维护性问题。这结合applicationCache，localStorage的OPOA的方案，看上去似乎高枕无忧，但是在多人协作问题上显现的特棘手，由于我们在项目中又引入了backbone（JS中的MVC框架）项目成员沟通成本增大很多。最后我们的方案是先有专人介入MVC，架设好最核心的应用体系，然后分配到page由不同人发。另外和pc端one page 还有点不一样的地方是我们移动端可能还需求页面与页面间切换的效果，所以大部分时候我们的view层可能需要被缓存，这个缓存言下之意就是显示与隐藏，所以在管理view上要做好特的管理，否则很可能会导致

内存的出。这个问题目前还没有很好的解决方案，但是之后会参考iOS native里面有一个navigator的对象，他会有一个动态管理的过程。另外棘手的问题还体现在：兼容性。部分android机器对于seaJS的支援度存在问题（体现在如果我把applicationCache封装成一个seajs可引用的模块化文件，在iOS平台上没有任何问题但是在部分android机器中就存在事件不执行的问题）；android还有一个问题就是，一般意义上manifest的更新只需要涉及注释的更新就可以了，在安卓平台下其实对于大部分机型是行不通的，在对资源文件需要有一个时间戳的概念，更新的文件需要更新其在manifest中与之对应的js文件的时间戳。当然问题点还有UC、QQ，最新的版本都有比较好的支持，我个人不鼓励大家在手机上安装UC，QQ 。接下来我们看看最最重要的一个问题——集群问题，因为我们的服务器是集群的。这涉及到静态资源文件的发布到静态服务器的问题和manifest文件在服务端的推送问题。举例来说，我们淘宝无线服务器，监测到静态资源服务器某一台服务器资源内容已经发生改变，然后马上生成新的manifest文件始推送，此时用户访问，用户拿到新的manifest文件，然后发生本地更新，但是静态服务器，并没有完全发布完，此时他到了一台并没有发布好的静态服务器去获取静态资源文件，那么这个用户就悲剧了，他的文件永远也更新不了了！！！manifest文件的推送失败，也就意味着我本地资源永远也不会得到更新，因为缓存的更新完全建立在manifest文件本身的更新。如何去解决这个问题？策略服务器，策略服务器需要做的事情是，监测我们静态资源的发布情况，只有当所有的静态服务器被认了更新成功才进入下一步，即manifest的更新，再下一步manifest的推送。当然问题点还有很多，都需要很耐心的去解决。

applicationCache

by pigcan on May 03, 2012

Accessibility

Upload Details

Usage Rights

Statistics

applicationCache Document Transcript