最后，要真正了解我们的应用程序的图形硬件性能，让我们来看看内存是如何被消耗的。这里我们可以看到，我们正在把绘图指令产生的1.38MB数据推进到Mac OS上的CoreAnimation缓冲区。核心动画缓冲区是被OpenGL ES和GPU共享的，来创建你最终在屏幕上看到的像素。

当我们简单地调整一下浏览器窗口尺寸或把窗口最大化，我们会看到立即膨胀了。

这给你一个想法，内存是如何被消耗在移动设备上，只有当你调整浏览器的正确尺寸。如果你在调试或测试iPhone环境，请从320像素调整到480像素。我们现在明白了硬件加速究竟如何工作的，以及怎样来调试。这是一种用阅读数字来了解的方式，但也是真正看到GPU内存缓冲区可视化工作的方式，确实让事情变得透明了。

场景背后：提取和缓存

现在是时候把我们的页面和资源缓存提升到一个新水平了。就像jQuery Mobile及其类似框架所使用的方法，我们要用并发AJAX调用来预取和缓存我们的网页。

让我们来指出一些移动网络的核心问题和我们为什么需要这么做的原因：

从滑动，翻转，和旋转演示 构建代码，我们开始先加上一些二级页面并链接到它们。然后我们将解析链接并飞速创建转换。

这里查看获取和缓存演示

如你所见，这里我们利用了语义标记。仅仅是到另一个页面的链接。子页面像它的父页面一样遵循相同的节点/类结构。我们可以更进一步的给"page"节点使用data-*属性，等等……这里是位于一个单独的html文件中(/demo2/home-detail.html)的详细页（子页面），它将被加载，缓存并在app加载时为页面转换预先建立。

<div> <h1>Home Page</h1> <a href="demo2/home-detail.html">Find out more about the home page!</a> </div>现在让我们来看看JS。为简单起见，我没对代码添加助手或进行优化。我们在这里做的是遍历一个指定的DOM节点的数组，挖出要提取和缓存的链接。注意，对于本演示，fetchAndCache()方法在页面加载时被调用。我们在下一节中检测网络连接时会再次使用它，并决定它何时该被调用。 var fetchAndCache = function() { // iterate through all nodes in this DOM to find all mobile pages we care about var pages = document.getElementsByClassName('page'); for (var i = 0; i < pages.length; i++) { // find all links var pageLinks = pages[i].getElementsByTagName('a'); for (var j = 0; j < pageLinks.length; j++) { var link = pageLinks[j]; if (link.hasAttribute('href') && //'#' in the href tells us that this page is already loaded in the DOM - and // that it links to a mobile transition/page !(/[\#]/g).test(link.href) && //check for an explicit class name setting to fetch this link (link.className.indexOf('fetch') >= 0)) { //fetch each url concurrently var ai = new ajax(link,function(text,url){ //insert the new mobile page into the DOM insertPages(text,url); }); ai.doGet(); } } } };

我们确保通过使用“ AJAX ”对象进行了适当的异步发送处理。在 Working Off the Grid with HTML5 Offline中调用的一个AJAX里有对使用localStorage的一个更高级的解释。在这个例子中，你会看到一个基本用法，用来缓存每个请求，并当服务器未返回成功的（200）响应时提供之前所缓存的对象。

function processRequest () { if (req.readyState == 4) { if (req.status == 200) { if (supports_local_storage()) { localStorage[url] = req.responseText; } if (callback) callback(req.responseText,url); } else { // There is an error of some kind, use our cached copy (if available). if (!!localStorage[url]) { // We have some data cached, return that to the callback. callback(localStorage[url],url); return; } } } }

不幸的是，由于本地存储使用UTF-16字符编码，每个字节被当作2个字节存储，将我们的存储限制从5MB降到 。 在应用程序缓存范围之外提取和缓存这些页面/标记的整个原因在下一节中透露。

通过最近在HTML5中iframe元素的进展，我们现在有了一个简单而有效的方式来解析AJAX调用返回给我们的响应文本。有很多3000行脚本解析器和去除脚本标签的正则表达式之类的东西。但为何不让浏览器代为做它最擅长的？在这个例子中，我们要把响应文本写到一个暂时隐藏的iframe中。我们使用HTML5的“沙箱”属性，它禁用脚本并提供了许多安全特征…

从规范上来讲: 当设置了 sandbox 属性后, 在Iframe的内容上开启了一组额外的限制。 它的值应该是一组无序的、空格分隔的  token， 并且是大小写敏感的。 可以设置的值分别是 allow-forms, allow-same-origin, allow-scripts, 和 allow-top-navigation. 当属性设置了以后,  内容处理后，将被当作同源，forms 和 scripts 将被禁止，指向其他浏览上下文的 link 将被禁止，插件也被禁用。 为了防止危险的 HTML 内容造成破坏， 它应使用一个  MIME 类型.

var insertPages = function(text, originalLink) { var frame = getFrame(); //write the ajax response text to the frame and let //the browser do the work frame.write(text); //now we have a DOM to work with var incomingPages = frame.getElementsByClassName('page'); var pageCount = incomingPages.length; for (var i = 0; i < pageCount; i++) { //the new page will always be at index 0 because //the last one just got popped off the stack with appendChild (below) var newPage = incomingPages[0]; //stage the new pages to the left by default newPage.className = 'page stage-left'; //find out where to insert var location = newPage.parentNode.id == 'back' ? 'back' : 'front'; try { // mobile safari will not allow nodes to be transferred from one DOM to another so // we must use adoptNode() document.getElementById(location).appendChild(document.adoptNode(newPage)); } catch(e) { // todo graceful degradation? } } };

Safari 正确的阻止了 Node 从一个 doc 到另一个的隐式移动。如果一个新的子节点在不同的 doc 上创建，将抛出一个错误。 那么这里我们使用adopt Node，一切都很好。