HTML5 需要代言人才能发挥作用。有很多人都承担了这个角色，在 Mozilla，我们认为向大家介绍其中的一些人是一个好主意，因此我们准备了一系列的访谈和短视频。形式很简单——我们向专家们提出 10 个问题，然后进行一个简短的视频访谈，让他们自我介绍，并详细解答其中一些问题的答案。

今天我们介绍的是 Andrew Betts，Assanka 的主管。

我们是因为他在阿姆斯特丹 BlackBerry Devcon 上的演讲“We’ve Got a Website for That – The FT Web App and the Future of the Mobile Web”而注意到他的，他在演讲中非常出色地让我们得以一窥 金融时报网站应用 的内部运作。你可以在 Twitter 上关注 Andrew，他的账号是 @triblondon。

视频访谈

你可以 在这里查看支持 HTML5 的任何设备上的视频（由 vid.ly 提供）。

Andrew Betts 的 10 个问题

1) 你参与了金融时报的 HTML5 应用开发。是什么让你选择 HTML5 而不是原生开发？总共有多少人参与了开发？

FT 在展示内容时采取了兼容多种格式和技术的方案。选择要适合内容、读者和我们的商业模式。在我们推出 HTML5 应用之前，FT 已经在 iOS 上推出了原生应用，并且还获得了苹果设计奖，但 HTML5 提供了许多显著的优势，其中最重要的优势是让我们能够与读者保持直接的联系。次要优势包括更快的更新流程，对未来跨平台兼容性的投资（HTML5 尚未完全实现“编写一次，随处运行”的梦想），以及免受应用商店运营商施加的限制和规则（现在或将来）。

2) 你认为最简单的部分是什么？为了使应用正常工作，你花了最多时间解决什么问题？

交互是最难解决的部分。将行为与用户的期望相匹配极其复杂，尤其是在你意识到用户对滑动行为的本能期望实际上相当多样化且不一致时。这个复杂性的一个例子是，从某个页面底部水平滑动，会将你带到下一个页面的顶部。如果你再向后滑动，你会回到你之前的位置，还是回到顶部？因此，处理交互既在技术上很困难，又在架构上具有挑战性。

离线行为也很难。我们收到了很多“用户 x 无法离线使用应用”类型的支持请求，这些请求很难调试。我们记录了每份报告，但首要任务是弄清楚问题的规模。

最容易处理的可能是布局。我们向所有旧版浏览器发送 m.ft.com 的链接，因此我们只需要处理最新的主要版本，这意味着我们通常可以获得对 CSS 的良好标准支持。

3) 你是如何处理界面差异的？移动设备的空间比平板电脑小得多，而平板电脑的空间又比桌面设备小得多。你是否使用媒体查询来提供不同的体验？

我们根据媒体查询将设备分为四种尺寸，并根据报告的 DPI 对使用哪些资源进行细微调整，但我们大多数响应式布局逻辑是在 JavaScript 中完成的。我们现在做了一些假设，以简化开发，例如假设用户无法更改浏览器窗口的大小，除非旋转设备，因此我们只需要在方向更改时更改布局，而无需响应窗口的任意大小调整。我们目前还假设用户没有鼠标光标，因此没有悬停效果。

4) 输入是如何进入应用的？在 HTML5 中构建触控界面是否足够简单，还是你必须使用一些技巧？

不幸的是，其中涉及到很多技巧。浏览器必须在提供触控 API 给 Web 开发人员并让开发人员使用它方面，以及处理几乎所有网站仍然是针对键盘和鼠标而构建的，因此浏览器需要帮助用户处理这一问题之间，走一条细线。我们开发了一种名为 Fastclick 的 polyfill，它使点击事件像触控事件一样快速触发，这无疑有助于我们提供与使用原生应用一样快速的体验。

我们还以几种截然不同的方式处理滑动。在页面之间滑动是一个无休止的轮播，我们通过维护当前视图左右两侧的隐藏页面容器并应用 CSS 3D 变换，自己实现跟踪和滑动。但翻阅文章需要不同的滚动机制——它具有固定长度，我们必须一次性布局整篇文章才能知道有多少页。垂直滚动的页面又是一个不同的挑战，我们使用的是将滚动委托给浏览器原生处理，并在需要略微不同的行为时模拟它的组合方式。

你还会注意到，当你触达页面顶部和底部时，页面不会“反弹”，尽管这在 iOS 浏览器中是正常行为。我们竭尽全力确保用户体验反映应用，而不是感觉设备在“应对”一个没有针对触控输入设备设计的网站。

5) 你在 BlackBerry Devcon 的演讲中提到，你使用 localStorage 来缓存 JavaScript 库和部分图像。为什么不使用 WebSQL 或 IndexDB 来做这件事？ localStorage 的同步特性是否会降低速度？

实际上，localStorage 比 WebSQL 快得多（我们尚未使用 IndexedDB，因为它在部分目标平台上不受支持）。localStorage 中按键查找所需的时间比 WebSQL 表上的等效 SELECT 语句要少得多。确实，它是同步的，但如果影响感知性能的关键因素是获取数据所需的时间（通常是这种情况），那么 localStorage 就能提供更快的响应。与 WebSQL，尤其是 HTML5 应用缓存的行为相比，它通常更可靠且更稳定。

6) 你还提到 localStorage 使用 UTF-16 而不是 UTF-8。这意味着你可以将两个 ASCII 字符存储在一个 UTF-16 中，从而使存储容量翻倍，对吗？你能分享一些代码吗？这对所有人都非常有用。

在 webkit 浏览器中，localStorage 和 WebSQL 都使用 UTF-16，这是这些技术实现的众多不合理之处之一！我们正在尝试一些算法来压缩数据，以便更有效地利用存储空间，其中一项是将两个字符合并成一个 UTF-16。我们还没有在生产环境中使用它，但如果我们使用了，我们肯定会希望将其开源。

还有更简单的事情可以做。粗略检查 WebSQL 表表明，列名会与每个单元格中的值一起存储，因此一些提高效率的尝试就像使用单字符列名一样简单。显然，我们不应该被迫做这些事，但这是使用浏览器中前沿功能的代价。

7) 对于想要构建 HTML5 应用的人来说，你认为最好的起点是什么？哪些是首先要解决的问题？

提前决定你要实现的目标。我可能很迂腐地说，将你的网站变成 HTML5 其实只是更改 DOCTYPE 的问题，因此“HTML5 应用”实际上是你定义的任何东西，对它的清晰认识是一个好的开始。你是只针对触控构建它，还是也针对键盘和鼠标？它是否需要离线工作？它是否会被搜索蜘蛛抓取？它是否可以在禁用 JavaScript 的情况下工作？

有一些很棒的资源，比如 MDN，但我们经常会发现自己阅读 HTML5 规范，有时甚至阅读 webkit 源代码，以找出某些东西是如何实现的。

8) 原生应用和 Web 应用能是一回事吗？

从技术上讲，我想不是的——严格来说，原生应用是直接在平台上运行的编译代码，但混合模式似乎越来越流行，我经常看到实际上是隐藏的 Web 浏览器的应用。如果你从用户的角度来看，问问自己，Web 应用能否完全像原生应用一样，我认为是可以的。由于 Web 技术的用途多样化，以及使用它们的平台的多样性，挑战也更大。对于游戏等用途，原生代码始终可能运行更快，并且可以更深入地访问操作系统。

但对于像发布这样的应用，这毕竟是 Web 的最初目的，Web 技术确实为我们需要的用户体验概念提供了支持。

9) 测试方面呢？你是如何处理的？你是否有一系列硬件来玩？

简直是噩梦。我们找了个本地电工给我们建了个充电站，用来存放我们所有的设备，并确保它们一直保持充电状态。我们团队大约有 45 台设备（这大约是人数的 4 倍）。我们一直在寻找改进测试流程的方法，并且不断重新审视自动化设备测试，但我们还没有在构建周期中使用它。目前我们有一支非常敬业的测试团队，他们整天都在戳戳点点设备。

10) 作为一名经历过大型 HTML5 应用开发过程的人，你想从浏览器供应商那里得到什么来让你的生活更轻松？

一个轻率的答案是 "你还有多少时间"，但实际上我们必须接受我们正在使用新诞生的技术，可能会有磨合问题。我们清单上的主要内容是：更频繁、更积极的浏览器更新（尤其是在 Android 上，浏览器是移动网络世界的顽童），一个更好、更可靠的应用程序缓存，以及对 CSS 变换的硬件加速。