虚拟研讨会：移动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的依赖非常强，单单一个错误就能让整个页面无法访问。假若不是所有浏览器都支持相同的特性，那么使用一个简单的<b>都会导致错误。这迫使开发者为几乎每个不同的设备都创建一个版本。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的差距并不是非常大。

Christoph （mootools-mobile）： 老实讲，直到最近，我还没有做过任何移动应用的开发。我想，对大多数人来说有件事情很明显，那就是世界已经跟早些时候不同了。人们最终发现了移动Web应用的潜力。只开发一个Web应用而不是多个本机应用会节省大量的资源。鉴于此时桌面上的革新正在浏览器中发生，而不是在平台本身，我认为移动设备没有理由会与众不同。Web是一种通用平台。

我们目前最大的问题是，移动Web开发就像是在一块小区域内玩有99个地雷的挖雷游戏，而不像是桌面浏览器中在一个大区域内玩同样规模的游戏。我认为这是非常恰当的类比。我们几乎没有移动浏览器调试工具，也几乎没有浏览器特性的文档，不同平台导致的问题和差异程度会让开发者发疯。我们才开始，还需要些时间。

InfoQ：你认为当前Web应用开发实践在多大程度上可以为移动Web应用所用？

Michael （Sencha Touch）：主要差异在于大多数移动应用都很小，因此今天的移动开发所需的组织规模远小于桌面开发。对于消费类的iPhone应用来讲，用户会话平均时间是4到5分钟。我们会猜测如果你排斥Email，你会想在协同移动应用上得到类似结果。在对我们的开发者群进行的一次调查中显示，屏幕个数为10-20的设计大致占80%。手机屏幕真是太小了，无法完成重量级的工作。

我认为，随着我们向平板计算前进，这会发生巨大变化，你将拥有更复杂的应用，而且用户会话的时间也更长，开发过程和团队将更像传统的桌面开发。

Brian （PhoneGap）： 所有专业的编程实践都可以很好的发生作用。把代码放进版本控制系统。架设自动化构建。书写单元测试。没有采用这三项实践的项目不见得会失败，但它们肯定不会有可以预测的发布时间或稳定的质量改进。

大多数Web应用实践都围绕着好的语义标签，清晰的css和优雅的解决跨浏览器问题的DOM库。在移动世界，我们有设备要求我们挑战这些实践。好的标签，尽管是个好主意，但增加了大量标记，导致延迟。深度嵌套的元素增加了渲染复杂度，让CSS查找变慢。基本上，要是你以性能的名义少做点事，你可能是对的。你可能没得选。我们都喜欢在我们的PhoneGap项目里使用jQuery，但由于这个库实在是太大了，导致初始化时间非常长。我们最终完成了针对移动设备的自己的库，叫做XUI，来解决这个问题。我们已经在所有Nitobi的PhoneGap项目中使用它有两年了。作为支撑PhoneGap平台的微DOM库，它工作得非常好，但它显然没有提供插件框架。

如果你只是面向最新的iPhone，而且你想画出GUI，那jqTouch是一个不错的选择。如果你要构建iPad应用，想要iPad风格的GUI那么Sencha Touch绝对是你的最佳之选。这些选择方案中的任何一种结合PhoneGap都将让你不必亲自动手去做本地应用，说的白一点，就是5分钟。没有一种本地平台给予了开发者这种生产力，放手让他们能够在多个平台间移植。但这个故事的真正意思是要理解你的用户，然后构建他们期望的体验。

每个移动项目都应从受众研究开始。许多接触PhoneGap的人仅仅是出于对iPhone感兴趣，但一旦我们去深入了解他们的受众，我们几乎总是发现他们大多数的用户都有Blackberry。交互设计师比以往更重要，并且他们的职责是确保他们的研究不仅仅是从Smashing杂志上下载iPhone模板。他们需要知道所有移动设备的维度和象素密度。他们需要知道每种平台的常见UI范式。他们需要理解手机不仅仅意味着电话，而且也不只是意味着触控界面。没有一种平台要比另一种更“正确”。成功的移动应用将适应每种平台，不错，这意味着开发者要进行条件构建/编码。让其用户感到愉悦的超级成功的应用和平台间特性公共差异最小的平庸应用之间的区别可能就是一种伟大的平台体验。你打算构建哪一种？

移动设备上的富客户端正展现出一种与桌面完全不同的新的令人着迷的问题空间。例如，数据复制和同步就是一个大问题。CouchDB的伙计们正在这上面工作，我们也投入到了其中。这是一个超级难的问题。要是你的数据库有上T的数据，客户端只能保存20M，会怎样？某种分页的分片？要是客户端现在是离线的呢？这其中充满了陷阱。安全性和隐私则开启了另一个满是蠕虫的盒子。

Christopher （iWebKit）：当前只有寥寥几个非常特殊的工具，如iWebKit或其他框架可以使用，但几个月之后，情况会发生变化。例如，你会看到大量更加重量级的JavaScript库内置触控手势。我怀疑明年移动和常规开发工具将会合并。唯一的区别就是屏幕尺寸，但这不是问题。

Chris （WebApp.Net）： 移动Web应用需要针对用户输入有效快速地装入和反应。在移动情形下，网络质量是决定性的。这就是为何你必须关心你手头在做的事情的原因。Ajax是减少不必要流量的关键，因为你只需要加载请求的内容，而不用重新加载整个页面。某些框架密集地使用Ajax，这是其优点，但是这往往造就非常巨大的操作多种特性（而且大部分根本就从未被用过）的JS代码，使得加载应用的时间变得很长，至少头次加载如此，让使用者感到沮丧。这些大文件可以利用离线Web应用特性或本地存储API轻易地被缓存起来，支持HTTP压缩虽然可能会有所帮助，但是解决之道应该依赖插件，以便开发者可以选择使用和抽取哪些文件，打包进一个文件以改善加载时间。例如，jQuery非常有趣，但是重新了发明轮子，很多流行的移动操作系统给浏览器提供了令人印象深刻的对于W3C和WHATWG标准的支持，这使得大多数jQuery特性没有什么用。同样Apple的iAd框架令人震惊的巨大（超过100k）。这似乎是因为框架里使用了MVC模式，这迫使代码非常结构化。

Christoph （mootools-mobile）： 我认为Web应用和移动Web应用二者非常相似。只是它们要实现的目标不同罢了。普通桌面Web应用可能把焦点放在传统功能上，而移动应用可能使用设备提供的关于当前它所处环境的任何信息。关于跟当前用户所处位置相关的任何环境。地理定位就是个绝佳的例子。移动设备变得对它们的环境越来越敏感，同时我们也会有API来访问硬件必须提供的任何东西。

我个人只要看到新事物就会想去找一种它的使用案例。最近我对本地存储、地理位置和history.pushState的兴趣渐增（参见 http://github.com/cpojer/mootools-history）。

InfoQ：你的项目在利用HTML 5 API吗？你认为HTML 5的哪个特性对于移动设备最有价值？你能给我们举一些例子吗？

Michael （Sencha Touch）：我们启动了所有跟HTML5有关的有趣技术。地理位置绝对是移动HTML5 API的头名。地理感知对移动设备的意义重大，原因在于它可以让你持续简化应用。例如， http://www.geocongress.us是个告诉你国会代表团最近完成了哪些事情的Sencha应用——引进的法案和进行的投票。我们不需要向使用者询问他们想跟踪哪些国会代表和参议员，我们只要查看位置AD就能立刻显示跟这个使用者有关的代表团。它简化了界面，立刻提供了相关信息。

排在地理位置后面的是离线应用功能，包括缓存manifest和本地存储，因为移动应用在网络不可用时也需要工作。Touchsolitaire.mobi/是一个可以将你的游戏状态保存到本地存储的Sencha应用，这样你就可以离线使用了。

除此之外，我们还在主题中大量使用了CSS3的功能，包括过渡、动画和造型。我们认为CSS3动画广告对移动领域的广告业有重大影响，因为有如此多的手机无法用Flash。我们甚至完成了一个它们的演示，地址在： http://dev.sencha.com/deploy/css3-ads/。

Brian （PhoneGap）： PhoneGap扩展了给定平台上可用的本地浏览器的所有功能，在很大程度上，这意味着我们是基于WebKit的，它绝对是HTML5的典范。PhoneGap工程可以利用在WebKit上实现的*全部*HTML5 api，但是，一如既往，这同样伴随着一些警告。比如，CSS过渡/变形/动画和画布元素仅在iPhone和webOS上有硬件加速。未来，我相信画布将对创建丰富和高性能的界面至关重要，但我们现在离那儿还有相当的距离。

另一个重要特性主要是围绕离线存储的。我个人非常高兴WebKit选择了SQLite，可并不是所有的移动设备都支持它，因此我们写了一个叫Lawnchair的库来隐藏内部的存储。对于简单地保存客户端的JSON文档，它工作真的非常好。PhoneGap目前的另一个目标是尽快完成一个一致的FileReader/FileWriter实现。

Web Worker是移动的另一个让人激动的领域，因为它可以极大改进应用的性能。最后，我们*真的*对可能将Web Socket用于实时应用感到激动（我们已经给iPhone和Android提供了XMPP支持）。想想：地理位置、实时消息传输、联系人API、照相存储……有多少很酷的应用会因此孕育而生！

Christopher （iWebKit）：iWebKit完全是基于css3的，它是HTML5引入的最重要的新特性。这样做的主要目的是为了让包尽可能的轻量级。只需使用非常少的图片，其余的由iPhone自己产生。利用css3，我还可以创建圆角边、阴影、自动伸缩的背景图以及自定义的表单元素。它还有一些超炫的特性，如根据元素在页面上的位置来检测某个元素（例如奇偶元素）以及根据屏幕宽度自定义风格。

Chris （WebApp.Net）： WebApp.Net目前还没有使用任何HTML5 API。不管怎样，这些API已经是API了，没有必要去封装，并且可能更像被作为插件而不是框架的一部分去使用，如视频播放器。一些HTML5 API非常特殊，如Selection API就跟文本编辑有关。至于跨域的限制，跨文档进行消息传输的API非常有趣的允许跨源（cross-origin）通信，但是开发者需要非常小心的使用它，在任何时候确保安全性。它已经在iOS 3.x中实现了，在基本的表单中只允许基于字符串的通信，在iOS 4.x中将会改进，实现全部的API规范。但是最有趣的API应该是画布API，它可以实现非常高级的用途（利用WebKit特有的-webkit-canvas（） CSS功能）。实际上，混合画布和视频在移动Safari上还不支持，会导致安全错误，希望它能早一点被修复。对于那些不属于HTML5规范的部分，地理位置API和所有的存储API允许更大的灵活性，并且可以涉足那些原来仅限于本地应用的领域。

InfoQ：使用HTML/JavaScript技术栈对于移动设备有重大意义，你认为像Flash这样基于插件的富互联网应用技术的前景如何？它们是互补还是会最终被淘汰？

Michael （Sencha Touch）：我认为说它们过时还言之过早，但是就跨设备覆盖来说，Flash和Silverlight简单说都存在问题。Flash可能在Android上找到归宿，尤其是由于Android依旧缺乏对SVG（Web矢量图形标准）的支持。要是Silverlight出现在iPhone或Android上我会很惊讶。我们期望HTML5以及基于HTML5的框架能尽快开发出真正与Flash和Silverlight目前提供功能相当的能力，如设备访问和内容保护。

Brian （PhoneGap）： Flash跟PhoneGap会一起工作得很好，实际上，你可以随时随地地使用它。现在就已经有一个桥接Flash/PhoneGap的示例存在了。我认为开发者可能会把焦点过多的放在“哪些已死”和其他趋势上。Flash是一个工具，由此，只要合适，我们就应该使用它。记住*所有技术*都会过时是有好处的。

Christopher （iWebKit）：出于SEO的原因，我反对像flash这样的技术，假如用它来交付内容的话。在iOS中不包含flash的决定是apple的选择，但这并不能说它就是个差劲的技术。对于特殊的用途，如站点的动态图形部分，flash或silverlight是目前实现很酷外观的最简单方式。HTML5也能够做到，但未必就更强或是更易用。同样，对于视频来讲，flash是保护你媒体的唯一方法。就目前来说，flash不会消亡，但是几年后它的市场可能会萎缩。最终它会像其他任何技术一样消失，可能到时会使用html6？

Chris （WebApp.Net）：Flash是个好东西，但是我们必须承认它让很多网站和计算机变得很慢，主要是因为如今的很多广告都在使用这项技术，而且还因为一些开发者并没有真正掌握Action Script和某些Flash特性的影响，导致几乎全部的CPU使用率都在执行他们的代码！不管怎样，Web似乎越来越朝着无插件浏览器的方向发展。最佳的例子就是HTML5视频和音频API的演变，以及主要视频网站如YouTube或Vimeo对这一特性的采纳。尽管画布和SVG很强大，但它们都需要手工编写几乎所有的代码，而这方面Flash则已经有一个功能齐全的创作工具。因此，暂时来讲，我认为它们是互补的，而且由于Flash被广泛的使用，它仍然会保留一段时间。但是软件厂商正在开发简化画布使用的解决方案或是渲染成Flash，例如，或是作为画布和SVG的混合体。这主要是因为Flash不被iPhone和iPad支持，而且还因为插件已经被证明了具有某些不稳定性，而使用浏览器内置的功能则要热门得多。

Christoph （mootools-mobile）：开放性决定了Web。它需要不惜一切代价保持开放，这里没有专有软件的容身之地。这就是我想说的全部内容。

InfoQ:对于目前准备开发移动Web应用的团队，你有何建议？哪些应该是他们的主要关注点，有哪些常见的陷阱是他们需要小心的？

Michael （Sencha Touch）：对于用户体验要非常小心——商业应用更应如此。不要试图给应用包装太多功能。保持界面的简单以及屏幕个数可管理。及早进行非正式的性能测试。就富体验来讲，对于真的“必须支持的”移动设备的数量要现实点，但是对于不支持富体验的设备要能退回到使用普通的HTML。

不要试图去摆弄自己的UI组件和低层次抽象，尤其是在已经有像Sencha和jQTouch这样的工具来帮助你完成这些工作的时侯，你这种做法就是重新发明轮子。

此外，专注于移动Web应用开发，并不意味着你就不能利用本地应用的分发渠道。Phonegap在允许你把Web应用打包成本地应用进入Android市场或Apple App Store方面做了很好的工作。

Brian （PhoneGap）：我们认为你能做得最好的就是去准备移动Web。从一个移动Web开始，只把PhoneGap视为一个积极的增强技术，用于应用商店的分发和早期介入设备API。浏览器正迎来这种东西。（而且随便说一句，还没有其他跨平台的移动解决方案适合这类风格的开发）。想想你的用户是谁，不要让你的个人设备喜好影响你。

想想临界速度和大致的连通性。不是每个人都钟爱iPhone 4，事实上，你的很大一部分潜在用户可能是在一个很差网络上的Blackberry 4.6。

Christopher （iWebKit）：除了用来构建Web站点的常用建议，还需要记住3件事。首先是绝大多数目前的智能手机用起来都很直观，而且提供了非常棒的用户体验。这也必须是你应用中的一部分，通过采用你自己的屏幕大小和设备的触控控制去体验。第二件事就是不要把用户局限于站点的最小版本。如今的用户需要在他们的手机上完全体验你的站点。最后一个就是要记住手机是移动的。它不会跟计算机一样快，而且网络速度也有限制。让你的Web应用变得轻快，在3G和临界情况下加载都不是太耗处理器的资源。

Chris （WebApp.Net）： 我的建议是深刻了解HTML5提供的新能力以及新的W3C规范，但也要留意ECMAScript规范，好很好的理解JavaScript。大多数API已经在移动浏览器中实现了，将会在他们的移动应用开发过程中发挥很大作用。开发者必须了解他使用的平台以及常见的用户使用习惯和行为。例如，使用操作系统定义的导航区域，使用用户为了得到所需动作而期望的手势。不要重新发明轮子，但要有创意和革新。你不需要模拟操作系统的界面，这主要是因为你的Web应用可以在不同的平台上浏览。

看看现有的框架，即使你不打算使用它们，了解它们如何实现跟你项目有关的特殊特性。使用Ajax时要考虑搜索引擎和用户书签。取决于你的Web站点，用户可能想要用书签保存链接——假设文章是通过Ajax加载的——而后可能会失望的看到无法访问你的内容。讨论搜索引擎会更兼容和高效的使用HTML5提供的新媒体特性。

但是最重要的一点在于：总是考虑用户。在设计Web应用时，用户体验必须是你考虑的核心。不要试图把所有的东西都塞到同一个页面，关注一个想法，分拆你的内容。记住，你不是在开发一个网站，而是在使用Web技术开发一个应用。行为和期望是不同的。Web应用更简单，它就会越成功。

Christoph （mootools-mobile）：首先，要尽可能让你的手碰到真正的设备。模拟器并不能代替它。了解不同移动浏览器的区别。考虑使用大屏幕设备，因为这样测试要更容易。选一个目标平台，试着为老的移动浏览器提供一个单独的视图。对于高级移动浏览器，你可以（也应该）增加模拟本地应用的富交互。简单而强大的技巧：使用css transitions和translate3d来得到硬件加速。

InfoQ：你的项目未来计划是什么？

Michael （Sencha Touch）：HTML5和CSS3已经提供大把的技术来让我们可以开始完全利用移动设备。存在着大量我们关注的运行时革新和工具支持领域。这里的挑战是选哪一个先开始解决！更多扩展的预定义UI组件、更好的图形化支持和富数据管理可能是Sencha Touch下一版的3个主题。

Brian （PhoneGap）：我们目前主要的重点是让人们可以更容易的上手。我们的文档非常丰富，你可以在这里浏览： http://docs.phonegap.com，而且围绕测试和构建PhoneGap项目有更好的工具支持。我们一直在增加新的平台，而且测试套件也变得越来越全面。这是个大项目，没有人能够完成所有的事情，因此我们需要*你的*帮助来构建未来的PhoneGap。加入PhoneGap邮件列表、IRC频道或即便只是查看一下Twitter上的@phonegap，如果想帮忙的话。可以从很多简单的Bug开始入手。

Christopher （iWebKit）：我已经开始进行iWebKit的下一版更新。它的结构将会改变，而且会使用最新的HTML5元素好让用户编辑更简单，结构更容易理解，一眼就能看明白。此外，我打算植入一个全新的主题系统，通过隔离CSS文件，让改变主题变得更简单。最后的一点是它将缺省就兼容iPad和iphone 4。你的站点完成后，它就能在任何Apple的设备上工作。

Chris （WebApp.Net）：我正忙于写本关于在iPhone和iPad上开发Web应用的书。它应该在未来几月出版。因此，我真的没有时间去做WebApp.Net和它的路线图。但是我正在写的书让我创建一些有趣的特性来阐述某些章节，当然它会成为WebApp.Net的一部分。最重要的工作是翻新当前WebApp.Net的某些功能，好让它们更符合标准。接下来，我将把重心放在对iPad的支持上，但是这将要求对框架的核心做一些改动。

Christoph （mootools-mobile）：我将对移动Web应用提供更有用的补充，我会在我的GitHub上发布更通用的插件（参见 http://cpojer.net）。一旦MooTools团队发布MooTools Core 1.3（很快，我保证！【译注：已经发布了。】）我将开始写点文章介绍如何使用我的代码。我做的所有事情都是针对MooTools Core 1.3的，所以耐心点，除非你想活在刀锋上。

你可以在InfoQ上找到更多关于移动开发的内容！

查看英文原文：Virtual Panel: The State of the Art in Mobile Web Application Development