用 HTML5 实现 iPad 应用无限平滑滚动前言：LinkedIn 5 月 2 日发布了新的 iPad 版本，它基于 HTML5 制作，在体验和界面上非常出色，在使用中可以发现它和原生应用基本没有任何差别。关于这个版本，有两篇文章非常有价值，深入的介绍了 Mobile Web App 和HTML5 移动开发的原理和方法。第一篇你绝对想不到的 LinkedIn 如何构建 iPad 新应用主要包括三个方面的内容： LinkedIn and themobile web LinkedIn 开始越来越多的采用 HTML5 来开发移动 Web 应用。 Now, with more Node.js大量使用了 node.js。 “Responsive design” just doesnt work他们认为响应式网页设计对简单的、一次性的网站很有用，但是对应用或者社交网络来说，它没有那么好。- - - - 华丽的分隔线而下面一篇文章讲述了 LinkedIn 是如何使用 HTML5 在 iOS 中实现平滑无限滚动以及内存和性能优化的。LinkedIn iPad 版：用 HTML5 的 5 项技术实现无限平滑滚动作者：TrunalBhanse译者：蒋宇捷这是在一系列博客文章中的第二篇，我们将聊聊 LinkedIn 新的 iPad 应用。在第一篇文章中，我们谈到了如何使用 HTML5 本地存储建立敏捷的移动体验，而这篇文章我要讲讲当实现一个无限翻页的列表时所面临的挑战。什么是“流”？当 iPad 项目开始时，我们考虑过如何才能为用户创造一个引人入胜的内容消费体验。我们决定以“流”的方式来展示文章、网络更新，以及其他类似的内容：一个可以无限翻页的界面。这里是页面流的第一页：移动设备上无限列表的挑战和台式机相比，移动设备具有更少的内存和更低的 CPU 主频。如果 在 HTML 页面中渲染很长的列表，你会面临运行设备崩溃的危险。这使得在移动设备上构建大型的 HTML5 互动应用成为一个挑战。Native 技术提供了 UITableViewController 来建立长的，无限滚动的列表。UITableView 包含可复用的 UITableViewCells 来优化内 存，性能以及响应。而针对 HTML5 我们没有任何现成解决方案。因此，我们将自己实现一个！技巧 1：移除图像UIWebView 或者移动 Safari 浏览器对图像有严格限 制。我们的页面流里铺满了大尺寸图像，所以很快就会达到上限。一种选择是使用 HTML5Canvas 绘制图像，不会带来内存问题。然而我们发现在画布上绘 制非常大的图像相当缓慢，所以我们不得不采取另一种方法：当一副图像完全“流”出屏幕时，用另一副非常小的图像替换 img 标签的“SRC”属性。这能确保 渲染大型图像所使用的内存被定期释放。此外，我们保证并没有引入图像空 src 属性的错误。技巧 2：隐藏页面释放图像并没有回收足够的内存来防止崩溃。因此，我们开始通过将 CSS 的visibility 属性设置为 hidden 来隐藏流的独立页面（图 2 表示“隐藏”的页面）。经过这种调整，我们不仅看到了更多的内存被回收（这样应用程序就不会崩溃），而且渲染速度也更快，因为浏览器不会为界面上“隐藏”的页面进行绘制。技巧 3：删除页面采用隐藏的页面可以覆盖 80的情况。但是余下的 20仍然会导 致应用程序崩溃！我们更进一步，开始删除不需要的页面。作为副作用，如果我们删除当前页面左侧的页面，页面流会左移，而用户将失去所在位置。为了保持滚动 位置，我们不得不在移除页面时（即 DOM 节点）用同样高度和宽度的空白页面来取代（图 2 中示意的“占位符”）。例如，如果用户正在浏览第 5 页，我们删除第 0 页，并用占位符取而代之。采用了上述的 3 种技术，我们的流开始类似于下面图里的样子。 正如你可以在图 1 中看到的一样，如果用户正在查看第 3 页，前一页和后一页将完全加载。而当用户决定向前或者向后翻页时，他可以看到完全呈现的页面。当用户 试图滚动时，我们开始加载图像并渲染页面。它可以在 iPad 模拟器上完美运行，但在实际设备上，你可以看到滚动性能的下降。图 1图 2正如图 2 所示，当用户翻动到第 5 页，第 0 和第 1 页将会被删除，第 2 页将会隐藏，而第 3 页移除了所有图像。此时，用户可以继续向前翻页，其它页面将根据它们和可见页面之间的距离来决定是移除图像、隐藏还是删除自身。我们不得不为不同版本的 iPad 使用一个可变大小的“窗口”。例如，iPad1 内存最少，所以我们不得不给它一个非常小的窗口：getConfig : function() /默认设置var config = size : 3,maxVisibleOnOneSide : 1,;/根据设备更新设置if($isDesktop | $native.isNative() & $os.ipad) /检测是 ipad1 还是 ipad2if($isDesktop | $native.getDeviceVersion() 1) config.size = 7;config.maxVisibleOnOneSide = 2;return config;技巧 4：避免缩放和盒阴影按照之前的经验，我们使用两个 HTML / CSS 的优化技巧来改善性能： 通过 HTML IMG 标签中指定宽度和高度属性来避免客户端缩放图像 避免 CSS 盒阴影：它在 WebKit 下很慢技术 5：减少 DOM 节点经过上述优化，你是否预期应用再也不会崩溃？错了！在测试过程中，上述技巧让应用程序运行的时间更长，但一段时间后它仍然会崩溃。根据之前 iPhone 应用的经验，我们知道保持 DOM 节点最少是平滑滚动和保证足够内存的关键点。 记住这一点后，我们将所有占位所用的节点合并为一个虚拟的，相同大小的节点。结果是：不管我们滑动到多少页，页面流不会在任何设备上崩溃！最终机制如图 3 所示：图 3技术实现的视频这里有一个当用户滑动翻页时，DOM 所表现出来行为的视频。左边我们在Chrome 窗口中加载页面流。而在右边，我们通过 Chrome 的开发者工具来展示如何添加或删除节点和通过虚拟页面的宽度来填补被删除的网页。 请注意 DOM节点是如何保持在一个恒定的数量的，以及 UL 的第一个 li 节点（“虚拟”节点）大小是如何增长的（你可能需要全屏播放视频来看）。失败的尝试我们并没有在第一时间得到正确的结果，所以必须要列出我们一些曾经失败的尝试。我们最开始使用多个 UIWebViews 来各自渲染一个页面并用UISwipeGestureRecognizer 来翻页。 然而我们很快就意识到，在本地应用程序使用多个 Web 视图在内存和性能方面是一种糟糕的方式。随后我们尝试了和 3-DIV 类似的方法。它可以工作，但是我们对滑动翻页的性能并不满意。 有时如果用户在翻页，我们同时在渲染一个页面，单线程的UIWebView 将无法添加到页面流里面。访问 www.uml.org.cn，查看更多精彩文章！