PDF移动应用开发：Web 与原生应用
Web 应用的开发和部署成本比原生应用更低，但它们能否匹敌原生用户体验？
Andre Charland 和 Brian LeRoux，Nitobi
几年前，大多数移动设备，用一个更好的词来说，是“哑的”。当然，当时有一些早期的智能手机，但它们要么完全专注于电子邮件，要么缺乏复杂到可以不用手写笔就能使用的触摸屏。更少的设备配备了像样的移动浏览器，能够显示除简单文本、链接和可能一张图片之外的任何内容。这意味着如果你拥有其中一款设备，你要么是一个沉迷于电子邮件的商务人士，要么是一个希望今年将成为智能手机元年 的极客。然后苹果通过 iPhone 的发布改变了一切，我们对移动体验的期望被完全重置。
最初针对第三方 iPhone 应用的计划是使用开放的 Web 技术。苹果甚至在其 Dashcode 项目中为此发布了工具4。快进三年，原生应用风靡一时，并且——通常是出于性能原因——移动 Web 正被不利地比较。
这种思维方式存在两个问题。首先，为每个平台构建不同的应用（如果用每种原生语言编写）非常昂贵。一个独立游戏开发者或初创公司可能只能支持一个设备，很可能是 iPhone，但 IT 部门将不得不支持其用户拥有的设备，而这些设备可能并不总是最新最好的。其次，原生应用速度更快的性能论点可能适用于 3D 游戏或图像处理应用，但在一个使用 Web 技术构建良好的商业应用中，性能损失可以忽略不计或不明显。
谷歌方面，正押注 Web 技术来解决平台碎片化问题。谷歌工程副总裁 Vic Gundotra 声称，“即使是谷歌也无法富裕到支持所有不同的移动平台，从苹果的 App Store 到 BlackBerry、Windows Mobile、Android 以及诺基亚平台的多种变体，”6，而这还是在 HP webOS、MeeGo 和其他平台出现之前。
在本文中，我们将讨论 Web 和原生方法各自的一些优势和劣势，并特别关注 Web 技术及其原生对应物之间差距正在缩小的领域。
原生代码 vs. Web 代码
实现一个软件应用始于代码。在原生代码的情况下，如今最常见的是开发人员通常使用 C 方言编写，例如 iPhone 的情况。在我们在 Nitobi 和 PhoneGap 的工作中，我们从原生开发的角度积累了大量与各种移动平台打交道的经验。
当然，出于各种市场或组织原因，大多数开发人员或团队都必须支持多个智能平台上的应用。想要用原生代码编写一个应用并覆盖每一个移动操作系统？如果你的团队拥有表 1 中所示的技能组合，那就没问题
使事情变得更加复杂的是实际平台 SDK（软件开发工具包）之间的差异。每个平台都有不同的工具、构建系统、API 和具有不同功能的设备。事实上，这些操作系统唯一 的共同点是它们都附带一个可从原生代码以编程方式访问的移动浏览器。
每个平台都允许我们实例化一个浏览器实例（无边框），并从原生代码与其 JavaScript 接口进行交互。从该 Webview 中，我们可以从 JavaScript 调用原生代码。这就是后来被称为 PhoneGap 技术的 hack，由 Eric Oesterle、Rob Ellis 和 Brock Whitten 在 2008 年 iPhoneDevCamp 上为第一个 iPhone OS SDK 开创。这种方法后来被移植到 Android、BlackBerry，然后移植到 PhoneGap 支持的其余平台。PhoneGap 是一个开源框架，为开发人员提供了一个环境，他们可以在其中使用 HTML、CSS 和 JavaScript 创建应用，并且仍然可以通过通用的 JS API 调用原生设备功能和传感器。PhoneGap 框架包含与底层操作系统交互并将信息传递回在 Webview 容器中运行的 JavaScript 应用的原生代码部分。今天，它支持地理位置、加速度计等等。
原生代码到底是什么？通常它是编译过的，这比 JavaScript 等解释型语言更快。Webviews 和浏览器使用 HTML 和 CSS 创建用户界面，其功能和成功程度各不相同。使用原生代码，我们通过专有 API 和通用用户界面元素和控件的抽象，直接在屏幕上绘制像素。
简而言之，我们正在将 JavaScript 与编译型语言进行比较。如今，JavaScript 正占据一席之地。这并不令人惊讶——JavaScript 虚拟机技术是浏览器战争的新前线。微软、谷歌、苹果、Opera 和 Mozilla 都在疯狂迭代，以超越竞争对手的实现5。目前，根据 一些基准测试，Mozilla 的 SpiderMonkey 正在逼近谷歌的 V8 引擎。苹果的 JavaScriptCore，在大多数 WebKit 浏览器（大多数移动设备上都有）中发现，介于两者之间。底线是，所有主要参与者的巨额支出正在推动这场 JavaScript 军备竞赛。图 1 中 Ars Technica 的基准测试展示了这些公司如何进行自我营销的一个例子。
JavaScript 正在迅速变得更快——事实上，速度如此之快，以至于 HP Palm webOS 2.0 将其服务层从 Java 重写为极其流行的 node.js 平台，该平台构建在谷歌的 V8 引擎之上，以获得更好的性能和更低的 CPU 成本（从而延长电池续航时间）。我们看到的趋势是 Web 技术栈在底层运行，并且它今天已在数百万台设备上投入生产。
用户界面代码
当涉及到用户界面时，情况就不那么美好了。大多数原生平台都为常见的用户界面控件和体验提供了出色的抽象。没有两个平台具有相同或什至相似的用户界面范例，更不用说实例化和访问它们的 API 了。Web 平台在很大程度上是一致的，但内置或 SDK 包含的控件数量有限。你必须自己动手。有时浏览器之间的差异会引起痛苦，但——至少在现代智能手机世界中——大多数设备都配备了功能非常强大的 WebKit 渲染引擎，只有很小的差异仍然存在。
不幸的是，对于 Web 来说，这些小差异正变得至关重要。例如，在 iOS 上，CSS position 属性不能正确支持“fixed”值（此问题已在最新的 Android 2.2 代码中得到纠正）。早于 6.0 版本的 BlackBerry 操作系统配备了一个完全神秘的浏览器，Web 开发人员为此付出了巨大的痛苦和难以估量的代价。幸运的是，RIM 在 6.0 中解决了很多这个问题，总的来说，情况正在好转。
一些操作系统包含一种称为硬件加速的东西。iOS 堆栈以其在 CSS 转换中对这一概念的支持而闻名，这正是某些 Web 框架实现视图状态之间丝般顺滑过渡的方式。这是一种最初在 Dashcode 中发现的技术。它由 David Kaneda 费力地反向工程，在 jQTouch 中率先使用，并在后来的 Sencha Touch 中发布。两者都是令人难以置信的 Web 项目，也是开发人员突破界限的例证。
当我们第一次开始利用这些下一代移动浏览器时，没有一个框架可以在设备之间正常工作。今天有超过 20 个移动框架，并且对现有 DOM（文档对象模型）库的支持正在迅速增加——其中最重要的就是 John Resig 的 jQuery 和 jQuery Mobile；该代码正在改进，并且每天都在增加对更多设备的支持。借助这些工具，从单个面向 Web 的代码库支持多个目标变得越来越容易。
在将 Web 技术栈与原生代码进行对比时，快速执行和漂亮的用户界面并不是全部。Web 技术生活在一个沙箱中，这个沙箱也是一个牢笼，限制了对原生代码可以访问的较低级别 API 的访问——这些 API 可以访问设备存储、传感器和数据。但是，这个差距也在被弥合。例如，大多数移动浏览器今天都支持地理位置，并且 iOS 最近添加了加速度计和大量其他 HTML5 API。鉴于 W3C 拥有一个 设备 API 工作组，我们很可能会在不久的将来看到更多 API 进入浏览器。如果不久的将来还不够快，你可以使用 PhoneGap 今天就访问这些 API。
当然，Web 技术栈（HTML/CSS/JS）本身是用原生代码实现的。原生层和浏览器之间的距离只差一次编译。换句话说，如果你想向浏览器添加原生功能，那么你可以桥接它，也可以重新编译浏览器以实现该功能。如果浏览器不支持原生功能，那不是因为它不能或不会；这只是意味着它尚未完成。
用户体验：情境 vs. 实现
另一个对原生和 Web 移动应用开发都有很大影响的领域是用户体验，我们用这个术语来表示用户与软件应用的整体体验。用户体验甚至可以扩展到应用之外。例如，我们可以使用推送通知在某些条件下唤醒应用，例如位置更改，或者生成一个新的专用应用来处理不同的应用方面。显然，成功的用户体验对于成功应用采用至关重要。
一般来说，移动软件项目的用户体验可以分为两个主要类别
• 情境—必须理解但无法更改或控制的元素。这些包括硬件特性、平台功能和 UI 约定，以及你的应用所使用的环境。
• 实现—可以在应用中控制的元素，例如性能、设计以及与平台功能（如加速度计数据或通知）的集成。
情境
你的应用将要使用的情境会影响用户的期望。对于单个应用而言，即使在单个平台上，情境也可能因用户而异。我们实际上不是在谈论一个情境；我们实际上是在谈论多个情境。让我们看看定义成功移动应用必须适应的情境的因素。
硬件
Android 设备生态系统（图 2）是这种情境多样性的一个绝佳例子，设备在显示（物理尺寸、颜色深度、屏幕分辨率、像素密度、宽高比）；输入（轨迹球、触摸屏、物理键盘、麦克风、摄像头）；和功能（处理能力、存储、天线等）方面差异很大。
这些属性的组合极大地影响了你的应用的外观，以及用户可能选择与之交互的各种可能方式。如果今天不存在特定的组合，那么明天很可能会出现。一个成功的应用必须考虑到与所有这些硬件设备相关的习惯。
平台约定
每个平台都有自己的用户界面约定，通常在人机界面指南文档中描述，并在操作系统界面中得到体现。各种移动 Web 浏览器提供了一个关于这些约定可能有多么不同的典型例子
一个常见的用户期望是能够在浏览器中“返回”。iOS 通过一个虚拟按钮来满足这一点；Android 和 BlackBerry 设备依赖于物理硬件返回按钮；webOS 使用返回按钮和返回手势。无论采用何种方法，用户都期望他们能够在你的应用中“返回”。
用户还期望上下文菜单。在默认的 Android 和 BlackBerry 浏览器中，上下文菜单通过位于屏幕底部的物理按钮访问，靠近拇指的自然位置。在 iOS 和 webOS 上，上下文菜单通过位于屏幕底部拇指附近的持久虚拟选项卡栏访问。在 iOS 和 webOS 以外的设备上，屏幕底部的持久选项卡栏通常会产生糟糕的体验，因为用户很容易意外点击他们的上下文菜单或返回按钮，导致应用意外关闭。这些是原生和 Web 应用都必须应对的限制。
开发人员必须考虑对数据和用户都有意义的方法。HTML5 确实支持菜单元素的概念，因此这里可以实现通用的抽象，但这项工作尚未完成。
环境
环境是所有因素中最大的变数！是白天还是晚上？用户是站着还是坐着？静止不动还是在运动？一只手还是两只手空闲？在繁忙的地方吗？变量是无穷无尽的。
这把我们带向何方？源于情境的期望本质上不是跨平台的。原生和 Web 实现都必须提供支持这些期望的设计和代码。对于 Web 开发人员来说，好消息是他们可以退回到 Web 技术栈中熟悉的范例来满足用户期望。
实现
为了产生尽可能好的用户体验，实现必须交付支持用户特定情境设定的期望的设计和代码。
性能：软件开发的梦魇
毫无疑问，性能是出色用户体验的基石。与安全性一样，它是软件开发人员最容易误解和经常使用的替罪羊。听到开发人员用轻率的“我们不能这样做，它会负面影响性能”来拒绝想法是很常见的。性能很少被量化，但经常被引用，是软件开发的梦魇。我们如何量化性能？延迟是性能的一种形式。执行，即操作执行所需的时间，是另一种。我们将分别讨论这些。
延迟是移动世界中一个巨大的考虑因素。无论是原生应用还是 Web 应用，下载应用以及它通过网络消耗或发布的数据都会产生性能损失。显然，有效负载越小，应用速度越快。
使用 JSON（JavaScript 对象表示法）格式的数据是一个好主意，因为它往往会导致比等效 XML 有效负载更小的数据有效负载，这取决于 XML 的格式化方式。另一方面，当返回要插入到网页中的 HTML 片段而不是返回 JSON 格式的数据时，XML 数据可能更有意义，JSON 格式的数据虽然在线上传输时更小，但需要使用 JavaScript 转换为 HTML 片段。你的效果可能会有所不同。基准测试是唯一确定的方法。
另一个延迟问题可能是代码的初始化。一旦我们实际将代码加载到内存中，它仍然需要被解析。这个过程可能会有明显的性能损失。我们可以伪造它，并通过确定性或不确定性进度指示器来增强对性能的感知。
执行时间当然是性能的一个关键方面。当解释代码时（就像我们对 Web 使用 JavaScript 所做的那样），需要解释的内容越多，执行时间就越长。在这里，Web 技术栈还有一些追赶要做。JavaScript，尽管在性能方面取得了飞跃，但仍然比原生对应物慢。另一方面，程序员在多个移动设备上用原生编译型语言编写可比逻辑所花费的时间可能值得执行的时间损失；但是，这肯定比用 JavaScript 编写的一个代码库需要更多的维护，该代码库可以在多个设备上运行，可能每个平台都需要进行一些调整。更少的代码通常意味着更少和更易于维护。
也就是说，更少代码的好处对于期望响应式界面的最终用户来说并不重要。开发人员的权衡是更大的代码库——考虑到对多个原生平台的支持，通常会大得多。在原生代码的世界中，主要挑战是重新实现以适应多个目标。在 Web 的世界中，主要挑战是尽可能限制你的占用空间，以产生响应式的用户体验。这并不是说一个用户界面可以在所有环境中都足够，而是说应用程序逻辑的大部分都在一个代码库中，然后可以使用条件代码实现特定的设备特定 UI 习惯用法。因此，你可能希望实现略有不同的功能和用户体验，以适应特定设备用户的期望。例如，Android 和 BlackBerry 设备有物理返回和菜单按钮，而 iOS 设备没有。
另一个要记住的关键点是，即使移动行业正在迅速趋同于 WebKit 作为 HTML 渲染引擎的事实标准，但每个设备和操作系统都有略微不同的 WebKit 版本。这意味着你应该期望开发类似于今天的跨浏览器 Web 开发。值得庆幸的是，有许多库，例如 jQuery Mobile、Sencha Touch 和 SproutCore，旨在解决这个问题。
所有关于延迟和代码执行的讨论都意味着要认真审视你的应用程序开发计划的业务目标。偏爱数据而不是装饰是最务实的方法。渐变、阴影、斜面、浮雕、高光、圆角和柏林噪声不会使应用程序有用或可用——它们不满足业务需求——但它们确实会影响性能。特别是 CSS 渐变，是移动世界中真正的性能杀手。你需要决定你的目标是什么：看起来漂亮还是为数据发布和获取提供有用的界面。在某些平台上，你可以通过使用原生代码进行优化的（通常是硬件加速的）像素绘制来获得其中一些功能。并不是说这些效果不可能实现，但应该谨慎使用它们，并且仅在它们增强而不是分散用户体验的注意力时才使用。交付在市场上取得成功的出色用户体验是可能的；它只需要适当的移动 Web 开发技术和良好的用户体验技能，这些技能考虑了环境的限制。
可爱的反弹和精美的设计
当然，精美的设计很重要。从美学到诸如良好程序的结构之类的无形资产，软件设计师必须致力于出色的设计，并建立在已有的坚实实践之上。通过动能物理学实现的滚动、可爱的反弹、缓动等等，创造了感觉真实且使用起来令人愉悦的反应式界面。这是原生控件特别擅长的领域。
我们尚未通过 Web 技术令人满意地解决原生滚动问题1。已经有很多尝试：iScroll、TouchScroll、GloveBox、Sencha 和 jQuery Mobile。所有这些都解决了滚动问题，但都没有像原生设备那样好地解决它。甚至谷歌移动团队也在努力发布解决此问题的方案3。毫无疑问，这是 PhoneGap 团队听到的最常见的抱怨，但我们距离 WebKit 中的一个错误修复使其不再成为问题只有一步之遥。谷歌移动团队最近发布了其针对基于 WebKit 的浏览器和平台的解决方案和代码2。
这就是总结。Web 技术栈尚未达到我们可以通过原生代码达到的性能水平，但它正在接近。我们相信 Web 技术将变得与原生体验无法区分。与此同时，Web 开发人员必须专注于交付数据，同时努力改进装饰。
展望未来
尽管原生和 Web 在这场辩论中相互对立，但可能的结果是混合解决方案。也许我们会将计算视为本质上是联网的，并且（这是我真诚的希望）任何人都可以自由访问。我们已经看到了原生 Web 的迹象：WebGL 最近证明，浏览器内 3D 游戏是可能的，甚至可以运行 Quake III！
与此同时，软件制造商必须根据应用程序的主要目标、开发和业务现实以及 Web 在不久的将来将提供的机会，来权衡 Web 与原生的辩论。好消息是，在所有这些技术进入浏览器之前，诸如 PhoneGap 之类的 hack 可以帮助弥合差距。我鼓励开发人员不仅要识别软件开发趋势，还要实施它们！如果 Web 没有满足你的特定应用程序所需的功能，那么你就面临着一个令人兴奋的机会来做出贡献并在此过程中弥合 Web/原生的鸿沟。
问
参考文献
1. Ecker, C. 2010。Ars iPad 应用程序重制版：我们将要去哪里； http://arstechnica.com/apple/news/2010/11/ars-application-redux-where-were-going.ars。
2. Fioravanti, R. 2010。实现固定位置的 iOS Web 应用程序； http://code.google.com/mobile/articles/webapp_fixed_ui.html。
3. 谷歌邮件博客。2010。移动 Safari 中的 Gmail；现在更像原生应用了； http://googlemobile.blogspot.com/2010/10/gmail-in-mobile-safari-now-even-more.html。
4. Lee, W-M. 2009。使用 Dashcode 为 iPhone 构建 Web 应用程序； http://mobiforge.com/developing/story/build-web-apps-iphone-using-dashcode。
5. MSDN，IEBlog。2010。HTML5 和真实网站性能：第七个 IE9 平台预览版可供开发人员使用； http://blogs.msdn.com/b/ie/archive/2010/11/17/html5-and-real-world-site-performance-seventh-ie9-platform-preview-available-for-developers.aspx。
6. Nuttall, C. 2009。应用商店不是未来，谷歌说。FT Tech Hub； http://blogs.ft.com/fttechhub/2009/07/app-stores-are-not-the-future-says-google。
喜欢它，讨厌它？请告诉我们
Andre Charland 是 Nitobi Inc. 的联合创始人兼首席执行官。他近十年来一直处于 Web 2.0 软件开发的前沿，并且是下一代 Web 的专家。他提倡可用性和用户体验，并经常谈论如何让用户在网站或基于 Web 的应用程序上保持参与和活跃。最近，Charland 在整个欧洲的 Adobe AIR Tour 上进行了演讲。他还曾担任 Voices That Matter 网页设计会议、Adobe MAX、JavaOne 和 AjaxWorld 的演讲者。他是去年夏天由 Prentice Hall 出版的“Enterprise Ajax”的合著者，并且是 O'Reilly 的 InsideRIA.com 的首席博主。
Brian LeRoux 是 Nitobi Software 的首席架构师，拥有著名的头衔 SPACELORD。他还有一个可疑的头衔，即 wtfjs.com 和 crockfordfacts.com 的创建者。更糟糕的是，他实际上有一个不断行的空格纹身。他还负责领导广受欢迎的 PhoneGap 免费软件项目的方向，该项目有着雄心勃勃的目标，即为几乎所有智能手机操作系统提供一个完整的 Web 平台，其中包括设备 API。
© 2011 1542-7730/11/0300 $10.00
最初发表于 Queue vol. 9, no. 4—
在 数字图书馆 中评论这篇文章
更多相关文章
Stephen Johnson - 茶杯中的 Java
很少有技术领域像无线行业一样发展迅速。随着市场和设备的成熟，移动应用的需求（和潜力）也在增长。越来越多的移动设备安装了 Java 平台，这使得大量的 Java 程序员可以尝试嵌入式编程。不幸的是，并非所有 Java 移动设备都是相同的，这给新的 J2ME（Java 2 平台，微型版）程序员带来了许多挑战。本文使用一个示例游戏应用程序，说明了与 J2ME 和蓝牙编程相关的一些挑战。
- 流媒体和标准：交付移动视频
不相信我？请跟随… 手机无处不在。每个人都有一部。想想你上次乘坐飞机，航班在地面上延误的情景。在可怕的通知之后，你立刻听到每个人都伸手去拿手机并开始拨号。
Fred Kitson - 移动媒体：使其成为现实
许多未来的移动应用都建立在丰富、交互式媒体服务的存在之上。此类服务的承诺和挑战是在最恶劣的条件下以低成本向拥有高期望的用户社区提供应用程序。情境感知服务需要关于用户是谁、在哪里、何时以及在做什么的信息，并且必须及时且以最小的延迟交付。本文揭示了一些当前最先进的“魔力”和研究挑战。
Bruce Zenel - 企业级无线
我们已经在无线领域工作了 10 多年，并参与了其成熟过程的每个阶段。我们看到无线技术从互联网泡沫之前的玩具技术发展到泡沫期间真正有前景的技术，但在泡沫破裂后，当发现该技术尚未为黄金时期做好准备时，却令人失望。幸运的是，似乎我们终于达到了技术和企业的期望最终趋同的程度。
© 保留所有权利。