`
t225com
  • 浏览: 659527 次
文章分类
社区版块
存档分类
最新评论

再议HTML5离线浏览

 
阅读更多

作者简介:Malcolm Sherida是Microsoft在ASP.NET方面的awarded MVP,精通ASP和Telerik,经常在澳大利亚和新西兰的会议以及用户组中做报告。作为一个长期使用ASP.NET的人,他关注Web技术超过10年了。他喜欢使用ASP.NET MVC工作,并喜欢使用jQuery和Javascript。他也为SitePoint和其他一些网站写一些关于ASP.NET的技术文章。

最近,我发布了一篇博文,内容是关于HTML5的一个新特性,博文名字是“通过应用程序缓存实现离线浏览(译文)”。这篇文章获得了很好的反响,有人请我再多谈一些内容,包括:

  • 如何决定什么文章应该被缓存
  • 缓存文件带来的影响
  • 调试应用程序缓存

所以这篇文章是接着上篇文章写的。如果你还没有看过上篇文章,也许你应该先去看看。

下面我们将来看看你应该或者不应该添加到应用程序缓存中的资源。

你应该缓存什么?

从技术上讲,从应用程序缓存添加或者移除某些资源是不难的。你在CACHE:节中指定了你需要缓存的资源,就是这样。

难的是决定什么资源应该被缓存,什么资源不应该。

对于我来说,明显需要被缓存的资源包括以下这些:

  • CSS文件
  • Javascript文件
  • 图像
  • 视频

这些都是离线缓存所需要保留的内容。没有什么比你离线浏览却看不到图片更令人沮丧了。更糟糕的还有没有保留CSS文件使得页面内容显示不正确。

既然面对的是远程文件,那么该如何处理这些文件?有两种情况需要考虑。

如果网站不是在SSL协议下运行的,远程资源就能被缓存。在下面的情形中,本地资源以及远程jQuery库都被加到了应用程序缓存中。

CACHE MANIFEST

# Created on 20 October 2011

CACHE:

clock.css

clock.js

# Caching the remote file

http://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js

然而,一旦网站是在SSL下运行,列在应用程序缓存清单中的内容就必须是本地资源了。需要注意Google Chrome是不受这个限制的——Chrome仍然会保留远程资源,尽管它们是在SSL下运行的。

很奇怪吧?我希望所有的浏览器都能在同样的规则下运行。

现在,让我们回到决定哪些资源应该被缓存的问题上去。

制定一个计划来决定哪些特性要为用户离线浏览保留是很重要的。比如说,如果你的站点和一个数据库有交互——现在的网站大多数都会和数据库有连接了——和数据库交互的页面被保留显然不是一个好主意,因为一旦用户离线浏览,这些页面就会连接数据库失败。

这就是为什么需要一个计划的原因了。如果你确实保留了和数据库交互的页面,当用户离线浏览时,你需要将用户数据保留在某个地方。这个地方可以是cookie,或者你可以保留在本地存储中。这是HTML5的另外一个令人激动的特性。一旦你决定你需要缓存什么页面了,你需要保存这个页面运行时所需要的所有资源。所以任何相关CSS、Javascript、图像、视频或者Flash都要被保留。

你不应该缓存什么?

你显然不应该缓存的是:

  • 和数据库交互的页面
  • 和Web服务交互的页面
  • 需要认证的页面

尽管应用程序缓存很好,但现实中你仍然需要和外界交互才能继续工作。在企业中尤其如此。一个离线网站是非常好的,但是一旦什么不能工作,它就不能让你赚到钱了。

调试缓存清单

现在你已经在缓存中保留资源了,如果你需要调试,你该如何发现缓存中发生了什么?

令人高兴的是,Google Chrome提供了一个地址让你定位到缓存以便查看缓存。在Chrome的地址栏中输入chrome://appcache-internals就能打开AppCache Internals页面了。

像你看到的那样,这个页面列出了缓存清单的当前大小,当它被创建、更新时的大小,这个页面还列出了缓存中的资源。当你需要看你在缓存中保留了什么时这一点是非常有帮助的。

我发现当你清空你的临时网络文件时,缓存中的资源也被删除,但这和你访问的网站也有关系。一个确定性删除缓存的方法是点击Chrome中的Remove。这确保所有的资源都会被删除。

应用程序缓存中不讨我喜欢的部分

尽管应用程序缓存很好,它仍然有些地方不讨我喜欢。

第一不讨我喜欢的是它需要为清单设定一个特定的媒体资源类型(a special MIME type)。如果你能访问你的Web服务器,这当然没什么问题。但是在共享服务器上,有时候这却是做不到的。如果你不创建这样一个媒体资源类型,你就什么都做不了。

使用应用程序缓存的另外一个不好的地方是使用了它们会带来一些不便。举个例子,如果有一个页面叫做default.html,如果这个页面被缓存了,当用户在线时,使用的仍然是这个缓存文件。那么你该如何通知浏览器去更新缓存?你需要通知用户,页面需要刷新。我们生活在一个Ajax帮我们解决了这些问题的世界里,所以一定还有更好的方式。

缓存CSS文件也是好的,但是如果你保留了任何来自于CSS文件定义的图片,它们并不会被自动缓存,你需要在缓存清单中显示指定要保留它们。

应用程序缓存大小限制也是变化的。尽管在规范中并没有对应用程序缓存大小的限制,但不同浏览器和不同设备对其大小都有着不同限制。目前的一些限制如下:

  • Safari桌面浏览器(Mac以及 Windows)没有限制
  • Mobile Safari 限制为 10MB
  • Chrome 限制为 5MB
  • Android 浏览器对应用程序缓存大小没有限制
  • Firefox 桌面版有无限的应用程序缓存大小
  • Opera’的应用程序缓存大小可以由用户管理,但有一个默认大小50MB

缓存清单的有效性

缓存清单很容易创建,但它更容易出错。

不正确的定位文件很让人头疼。幸运的是有缓存清单验证器Cache Manifest Validator来帮助你减轻调试缓存清单文件错误时的痛苦。这是一个很好的工具,要标记下来经常使用。

总结

最后说一点。我的很多工作都是着眼于大型企业用户。一旦一个应用是离线使用了,就会发出警告。这确实是一个问题。

HTML5通过应用程序缓存实现的离线能力显然具有很大潜力,但它还不能覆盖所有应用。任何考虑构建离线浏览的人需要考虑用户拥有的一些根深蒂固的习惯。

原文链接:Diving Deeper into HTML5 Offline Browsing

上篇文章:初探:通过Application Cache实现HTML5离线浏览



译文来源:http://www.webapptrend.com/
WebAppTrend是一个独立的技术博客,关注WebApp前瞻和实践,以及智能浏览器发展

请大家在关注CSDN的同时,关注我们的新浪微博 @WebAppTrend,欢迎加入我们的:193775364


分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics