虚拟研讨会：移动 Web 应用开发最新动态

为了掌握移动 Web 应用开发的最新动态，InfoQ 邀请一些该领域最流行的库、工具和框架的缔造者，组织了一场虚拟研讨会。

参与者及其框架分别是：

• Michael Mullany， Sencha Touch
• Brian LeRoux， PhoneGap
• Christopher Plieger， iWebKit
• Chris Apers， WebApp.Net
• Christoph Pojer， mootools-mobile

InfoQ：你能给大家描述一下使用你项目进行开发的过程吗？如何开发和测试 Web 应用？

Michael （Sencha Touch）：我们这个 JavaScript 框架针对的是触控式（Touch-based）移动 Web 应用，开发者在使用 Sencha Touch 时可以继续使用他们喜欢的 IDE 和选择的服务器端。这跟开发其他 Web 应用没任何区别，但是移动设备肯定会给测试方面带来些挑战，因为移动 Web 浏览器不具备插件功能，而该功能给桌面浏览器提供了丰富的调试功能。

Brian （PhoneGap）：开发者在开发 PhoneGap 应用时首先要做的一件事就是决定他们目标用户需要的平台。PhoneGap 支持 Apple iPhone、Google Android、RIM Blackberry、Palm webOS、Symbian、Meego 和 Windows Phone 7。一旦确定目标用户和平台，开发者就需要花点时间搞清楚输入方式和屏幕设备尺寸。比如，iPad UI 就不能工作在 Blackberry 上。Palm 设备有极好的手势（Gestural）支持，Androids 使用物理按键作为主要的交互手段，而 iPhones 则用虚拟按键完成除了电源和音量之外的任何操作。一种 UX（用户体验）模式不能简单的照搬到所有平台。 PhoneGap 项目有一个单独的 WWW 文件夹，开发者可以在其中放置他们的 HTML、CSS 和 JavaScript。PhoneGap 的唯一限制是该 WWW 文件夹必须包含一个 index.html 文件。Symbian 和 webOS 要求应用是单页的，我们认为这是个好的范式。（注，其他 PhoneGap 平台没有该限制，因此，若你不支持 Symbian 或 webOS，你 * 可以 * 创建多页应用……但是页面间迁移会很难看。）

我们让开发者去想办法解决每种平台的构建主要是因为我们无法再分发不同的移动 SDK。此外，要记住平台跟操作系统的对应关系（iOS 需要 Apple，Windows Mobile/Phone 7 要求 Windows）。在 Nitobi，我们一般可能使用下面三种技术之一，取决于要支持的平台。

- 把单独的 WWW 文件夹符号链接（symlink）进每个特定 PhoneGap 平台的代码库

- 同上，但使用 git 子模块或外部 svn

- 手动将 WWW 复制到每个项目的构建脚本

这些技术的任何一种都很适合工作于单个平台的小团队或分散在所有平台的大型团队。之后，就是普通的 Web 开发了，很多 PhoneGap 开发者都尽量在构建步骤节约时间，好让他们集中工作在 Chrome 或 Safari（有时是 Firefox）上。

Christopher （iWebKit）：对最终用户来讲，开发过程相当简单。 用户指南给他提供了所有可用的元素，其初始风格跟 iOS 界面看起来非常像。因此，他要做的全部事情就是把一部分代码复制到一个 HTML 文件中，改变它的内容，然后他就可以继续前进了！要想对其进行测试，只需使用任何 Webkit 浏览器即可，如 Chrome 或 Safari，但我推荐用 iPhone 或 iPod touch（哪个版本都行），因为 CSS 文件产生的布局也是基于检测到的屏幕大小。

Chris （WebApp.Net）： 使用 WebApp.Net，你只需要下载安装包，将其解压到开发文件夹中即可。这时，你可以阅读文档来开始使用。在一个静态 Web 站点上使用 WebApp.Net 相当简单，但要想在动态环境中使用它，可能需要很好地理解 Ajax 和基本的 XML 知识。WebApp.Net 使用 XML 来实现多个部分的异步展现和内容更新。例如，你可以创建完整的层级内容或是只更新某特殊标签内的文本。它还支持从异步响应中执行脚本。 写文档得花点时间，我也正全力以赴地做这件事，但总的来说它仍处于未完成状态。支持论坛是最好的文档，其中有些讨论非常有趣。示例的源代码也非常有帮助，因为它实现了一些非常有趣的框架特性。论坛还有一个板块专门用于发布哪些 Web 应用使用了 WebApp.Net，它们也都是理解该框架的不错起点。

开发者可以轻易地在使用 WebKit 引擎的桌面浏览器内测试自己的 Web 应用。Firefox 也同样得到了支持，另外还提供了一个特殊的 CSS，用来调整特定于厂商的属性。

Christoph （mootools-mobile）： 对于什么是 Web 应用，存在着很多不同的定义。在我看来，Web 应用不仅意味着“丰富的交互”，而且还涉及利用和转换用户数据或设备数据，同时还包括利用用户相关的信息。我相信每个人都有不同的定义和需求。这就是我为何要把东西都尽量以模块形式发布的原因。我发布在 GitHub 上的项目都是独立的，只需要某些 MooTools 的核心组件。MooTools，其本身作为一个模块库，是 Web 应用开发的理想之选，因为你可以对其进行定制，构建自己的版本。 mootools-mobile 旨在提供低层次的功能，如自定义 swipe 和 pinch 事件。它并没打算成为一个全面的移动 Web 应用框架，但它可以成为其基础。模块化是关键，只需在其上进行构建即可。模块化暗示着抽象。这样，开发过程就具备了非常好的可扩展性，因为其他开发者可以更灵活地选择适合（而且只适合）其项目的工具。

我坚信 JavaScript 应该独立于所有内容和形式。我的开发方式通常是不依赖任何 CSS 或 HTML——大多数时候，我也“只”是个 JavaScript 开发者。我甚至不碰任何其他东西。我专注于模块化——这样，每个浏览器和平台都有其自己的一套模块。这也让在旧浏览器或其他不支持移动设备上关闭某些特性变得非常简单。

测试移动应用最好的方式是为尽量多的代码写测试代码，尽可能最小化手工测试的需要。

InfoQ：很多移动设备都有数种输入方式，包括触摸屏，有时还需要多个手指进行操作。你的框架支持这些输入方式吗？你认为它提供了其他额外的好处吗？

Michael （Sencha Touch）：Sencha Touch 是针对触控设备的应用框架，因此我们给开发者提供了一整套触控管理器。我们将基础的 JavaScript 触控事件抽象成开发者用来编程的基础设施（如 doubletap、tap/hold、swipes、pinches 等）。我们认为触控界面提供了移动设备上最佳的交互模型，因为它们能让你解决大量烦人的 UI 问题。我们认为触控 / 手势接口将在所有移动平台得到支持。拥有虚拟控制可以让你在不需要它们的时候给内容提供更多的空间，支持更丰富的交互，更符合用户的预期。要是不支持手势，一些常做的简单事情（如放大内容，重定位，然后再缩小回原来大小），都会是件复杂的过程。这也是在我们有了手势支持之前，移动应用没有真正腾飞的原因之一。我们认为对于移动应用，按按钮，使用跟踪球（Trackball）等，正慢慢地在移动设备上消亡。毕竟，在桌面浏览器里，你从未见过浏览器应用会在用户按 Windows 的启动按钮时做某些特别的事情。

Brian （PhoneGap）：如果设备支持触控事件，那么针对该设备的 PhoneGap 也支持。触控体验绝对非常重要，我们才刚刚开始摸到手势交互设计的门道。Palm 的 webOS 在这方面是个非常先进的平台，我们也期望能把很多这方面的手势支持带到其他平台。 然而，触控并不总是有意义。虚拟键盘就相当难触击，常用按键应该能随时可访问，同时又不侵占有限的屏幕大小。Palm、Blackberry、Android 在这方面也都进行了相当好的探索。Blackberry 使用者常常期望类似上下文菜单的“Blackberry 按钮”。Android 的伙计们则想要菜单、搜索、回退和 Home 按钮。满足用户体验要比满足其他花里胡哨的兼容性重要得多。在对触摸屏的痴迷退热之后，Android 上的虚拟回退按钮只不过是个烦人的组件。

Christopher （iWebKit）：由于 iWebKit 复制了 iOS 界面的所有元素，因此它绝对是"可触控的"。它们能很好地适合你的手指，而不是让你必须去适应站点，这是使用这个框架的主要原因。其他多指手势并没有缺省内置，但开发者在读过 Apple 的在线指南后可以轻松地添加进来。在我看来，这些手势并不是真的不可或缺，因为目前的互联网只是分发诸如文本、图像或视频这类媒体的一种简单方式。简单的体验对用户来讲是最好的。 但是，随着 Chrome OS 和 Html 5 的到来，我认为我们很快就会看到新的、更像“应用”的网站，而且这类站点的一小部分会被触摸屏设备接纳。它们将和本地应用一样好，尽管技术上是可能的，但现在时机未到。市场还没有形成。

Chris （WebApp.Net）：很多时候，手势只是使用一个手指完成诸如 swipe-to-delete, pan up/down……多触控手势通常用于缩放和旋转特性，此外就没有了。在 iPad 相册应用（它可以让你收集大量的图片）中的发现效果使用了跟 pinch 手势相同的行为（缩放），但无法重新伸缩图像。 WebApp.Net 目前还没有手势事件，但在未来会有完全可配置的手势及相关事件。手势对用户体验非常有益，提供了一种简单自然操作 iPhone 用户界面的方法。只要手势得到了很好地设计，它们就会非常高效，并且提供非常好的生产力。

Christoph （mootools-mobile）： 尽管这是对的，但并不是很多移动浏览器都确实支持触控事件。目前只有移动 Safari 和 Android 浏览器支持触控事件，即便是后者也还不支持多触控（最近的模型终于开始支持它们了）。这意味着 mootools-mobile 主要针对这些设备，直到其他设备上的浏览器提供这样的特性。mootools-mobile 提供了像 swipe、pinch 和 touchhold 这样富交互的自定义事件，马上还会有更多！此外，还为所有点击事件提供了一种自动的替换机制，以克服 iOS 上的触控延时。这让移动 Web 应用响应更迅速——简单但高效！

InfoQ：在遇到 HTML 和 JavaScript 组件时，客户端的功能测试尤其困难，特别是还涉及多个目标平台的时候。开发者该如何应对这个问题？

Michael （Sencha Touch）：我认为现在还没有真正好的答案。传统的功能测试不足以应对移动平台：仅仅因为某些测试正确并不意味着它的速度就满足使用要求了。所有平台都有模拟器，但是同样存在着限制。iOS 模拟器只能工作在 Mac 上；Blackberry Torch 模拟器只能在 Windows 运行。iOS 模拟器可能在复制设备体验方面做得最好，但是你需要在每个设备上都进行测试，以确保你用到的所有东西都有合理的性能。在 Blackberry Torch 上有很多 Web 特性，如好看的 CheckBox，但一旦你要想做点复杂的事情就会有效率问题。Android 有时会具有挑战性，因为电话 OEM 厂商加入的某些特性可能会让你的应用出问题——相比起 Android Web 应用来讲，原生 Android 应用会更糟。每种设备都有一些特殊的东西，应用开发者必须依赖它才能进行测试。要想保证一个特别的用户体验，真的没有其他办法。

Brian （PhoneGap）：我们使用由 John Resig 开发的优秀的 qUnit 库对我们的 JavaScript 库尽可能进行单元测试。它工作在所有的 PhoneGap 平台上。不幸的是，对于手势界面无法进行可靠的自动化测试，像 CSS 动画 / 变形 / 过渡这类主观性更强的体验，自动化测试尤其困难。对应用有个好‘感觉’是它成功的关键，测试它的最佳途径就是把它构建到一个设备中去，然后不断把玩。幸运的是，由于设备的性能特征和实际可用屏幕的大小，大部分移动应用关注于很好地实现一个简单功能，完全不同于我们在桌面应用中已经习以为常的单块应用。因此，这种手工测试的方式实际上并不太难或耗费资源。

Christopher （iWebKit）：就 iWebKit 来讲，这实际不是太大的问题。它可以在任何 WebKit 的浏览器上做到开箱即用，这指的是：iOS、blackberry os6、google android，基本上是除了 Windows Mobile 之外的所有主要智能手机平台。一旦 Windows Phone 7（或 8）内置了 css3 和 html5 支持，对于像 iWebKit 这样的现有框架会需要做一些调整，但理论上它是可以工作的。现在唯一的限制是，对于 iWebKit 来讲，它使用的是 iPhone 布局，但给框架换个皮肤很容易，因此，你可以给它提供一个适合所有平台的自定义外观。

Chris （WebApp.Net）：在进行 iPhone、Android 或 webOS 开发时，开发者可以方便地依赖所提供的模拟器，但它们的调试选项相当有限。作为一种最后的手段，他们可以使用经典的基于 WebKit 的浏览器，除了最新的 WebKit Web 检查器，还可以其他搭配提供的强大工具。当然，桌面版通常提供了比其移动版更多的 API，后者并没有实现所有相同的特性。 大多数时候，这些特性是针对非常先进的用途的，这算不上是个问题，但我记得，在未实现 CSS 灰度的 webOS 上工作的时候，我不得不依赖画布来渲染灰度。我认为总有办法绕过兼容性问题。

如今，大多数浏览器都实现了强大的调试和性能监视工具。对于 Ajax 应用来讲，这些工具更有用，但是开发者必须尽量复现目标环境，以免在部署时被跨域问题搞得焦头烂额。实际上，跨域限制对于 file:// URL 模式来讲并不存在，我知道有时（经常）前端开发者将他们的代码弄成这样子，假如要做的事情仅仅是直接从 JavaScript 渲染 JSON 内容的话。当然，JSONP 对于绕开跨域限制很有帮助，尤其是在服务器端代理无法使用的情况下。

因此，这一问题的最短答案是：使用所提供的开发者工具:）

Christoph （mootools-mobile）：前面已经提到，应该尽量最小化手工测试的需要。Arian Stolwijk，MooTools 团队的成员之一，和我最近重写了 MooTools Spec 引擎，它是我们的单元测试库。它是独立的工具，基于 Jasmine，可用于任何项目。它可以在浏览器、node.js 中，以及通过 JSTestDriver（正在做）运行代码。你可以在 GitHub 上找到它： http://github.com/mootools/mootools-runner ——它甚至可以让你模拟鼠标和键盘事件，通过一个叫做 Syn.js 的优秀库。更多信息和亲手尝试，可以参见这个说明： http://github.com/mootools/mootools-core-specs 。 基本上，如果把 DOM 交互从业务逻辑中解耦出来，你就已经可以自动化测试应用的大部分代码了（可能甚至只是通过 node.js 运行它）。

InfoQ：自从早期的 WML 和只接受 XHTML 的移动浏览器出现，已经过了不少时间。这段时间以来，你认为哪些事情已经改变了？对于我们已经有了更强大的设备，但需要更多应用的今天，我们有没有学到点教训，可供我们参考？

Michael （Sencha Touch）：发生的最大事情就是摩尔定律继续地快速推进，携其余威继续丰富处理器的能力。当今的移动设备现在看起来就像是 2000 年左右的桌面，这意味着它第一次可以支持丰富的应用。发生的另一件事是 HTML5 处理给我们提供了基于标准的 Web 技术，这对一般开发人员来讲更实际、有用和容易理解。每个人都希望浏览器能变回 90 年底所有事情都偏离轨道之前的那个样子。 我们认为第一个教训是开发者需要评估他们是否应该支持无法提供良好应用体验的旧设备。想当初，WML/WAP 应用就很难使用，功能也很有限。只是创建一堆快捷、整洁和直观的用户界面还不够，你需要创造一种参与体验。我们内部有一份审视新手机用的最简手机规范。当今的 Android 2、iOS 和 RIM OS6 都达标了，我们期望 Nokia 手机也可以很快出线。我们从来没有指望过让一个 Sencha 应用运行在 Motoroal 的 Razr 手机上。

我们的另一个想法则是不要过多担心利用操作系统特定的功能。肯定有一撮移动开发者会有意地使用每个移动平台的原生部件或控件——即便他们开发的是 Web 应用。但我们认为，Web 自己本身就是一个平台。桌面应用的外观在 Mac、Windows 和 Linux 上没什么不同，那只要是它们都有相同的输入机制可以利用的话，移动应用为什么要在 Android 和 iPhone 上显得不一样呢？

Brian （PhoneGap）： 设备 API 是我们在现代 Web 中看到的最大、最有趣的变化。每个人都在谈论 HTML5，一旦 Web 成为访问设备传感器（如照相机）和设备数据（如相片）的首选平台，革新就会发生。今天，你可以使用 PhoneGap 书写提供设备 API 的 Web 应用。 不幸的是，桌面编程中已经学到的教训无法很好的转化到 Web 的小屏幕和语言（即 JavaScript）上。许多开发者把大型系统的设计哲学（这里为大家都钟爱的“四人帮”的设计模式做下广告）应用到非常简短、函数式和动态的 JavaScript 语言上。使 JS 成为一种 Java 或 C 的变体，在使代码内存（这对移动设备来讲是必须考虑的事情）膨胀的同时，损害了 JavaScript 最好的特性。革新的空间很大；那些敢于使用 * 现有 * 工具而不是使用 * 以前 * 工具的开发者正在创造未来的 Web。

Christopher （iWebKit）：严格的讲，“移动浏览器”根本就不存在。现在唯一的区别就是屏幕大小和使用触摸屏输入。引擎跟桌面浏览器完全一样。我们是否学到了什么教训？很难讲。当时的手机非常慢，用户体验也很糟糕。硬件不足以有效地运行大而重的网站，直到 Apple 决定重新设计“移动互联网”，给 iPhone 提供一个大屏幕，一种简单的导航方式，以及最重要的运行“桌面”浏览器的能力。 因此，我说我们没有学到任何东西是指，我们没有改进当时的移动互联网，而是抛弃了它，转而进入了一个全新的领域。当今可用的这些应用就是明证。它不是之前相同的“东西”。手机真正的概念已经消失了，现在我们拥有的是智能机。

Chris （WebApp.Net）：WAP 本身是一个非常有趣的标准，具有很好的脚本编程功能，将网络带入了移动世界。但问题在于大多数规范由于设备的限制没有在移动浏览器里实现，同时没有讨论仅限于几行文本的小屏幕。同时，WML 对 XML 的依赖非常强，单单一个错误就能让整个页面无法访问。假若不是所有浏览器都支持相同的特性，那么使用一个简单的都会导致错误。这迫使开发者为几乎每个不同的设备都创建一个版本。WAP 2.0 朝着用户更友好的移动 Web 又迈出了一步。这个新版本使用具有 CSS 能力的 XHTML 子集（移动概要，Mobile Profile），但实现又一次很不均衡，屏幕分辨率的巨大差异同样也没有减轻开发者的工作。 如今，大多数智能机都有不错的大屏幕，同时包含能够正确展示桌面网页的高级浏览器。制造商似乎明白了移动 Web 的挑战，在他们的移动浏览器上投入了大量时间。更好的例子是 iOS 4.x 上的移动 Safari。这个浏览器包含了大量难以克服的特性。你也可以发现某些只在每日构建的 WebKit 版本上可用的特性。至于 iOS 的新版本，它带来了几乎真正的多任务，可以使用 Web Worker，同时非常不错而且几乎完全实现了 HTML5 API。

应用开发的兴趣现在似乎集中在本地开发，但 Web 应用正越来越接近底层 API，如地理位置 API、触控 / 手势事件或非常有趣的文件 API，虽然仍处于草案阶段，但已经完全在移动 Safari 中实现了。更别说 webOS 本来就是只基于 Web 的。在我看来，Web 应用的开发更快，而且更容易发布和维护。当然，由于设备限制你很难用 JavaScript 和 Canvas 或 SVG 创建一个 3D 游戏，但大多数应用可以用 HTML/JS/CSS 完成，webOS 已经很好展示了这一点。此外，Google 将大部分它的桌面 Web 应用都发布了移动版，越来越多的编辑器也踏上了这条道路。

很多本机应用都使用 HTTP Feed 给应用提供内容，大部分时候只用到了少许操作系统特性。所有这些应用都可以轻易地使用 HTML/CSS 展示，因此本机和 Web 的差距并不是非常大。