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

阅读数:5027 2011 年 2 月 25 日 00:00

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

参与者及其框架分别是:

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

评论

发布