ACM通信

实践

移动应用程序开发:Web vs.本机

安德烈·查兰、布莱恩·勒鲁著
ACM通信，2011年5月，第54卷第5期，49-53页
10.1145/1941487.1941504
评论(2)

短短几年前，大多数移动设备都是“哑巴”(因为没有更好的词)。当然，也有一些早期的智能手机，但它们要么完全专注于电子邮件，要么缺乏无需触控笔即可使用的复杂触摸屏。甚至更少的手机浏览器能够显示除了简单的文本、链接，甚至可能是图像以外的任何东西。这意味着，如果你拥有其中一款设备，你要么是一个沉迷于电子邮件的商务人士，要么是一个希望今年成为智能手机之年的阿尔法极客。然后苹果发布了iPhone，改变了一切，我们对移动体验的期望也被彻底重置。

第三方iPhone应用的最初计划是使用开放的Web技术。苹果甚至在其Dashcode项目中发布了相关工具。⁴三年过去了，原生应用风靡一时，通常由于性能的原因，移动网络被认为是不受欢迎的。

这种思路有两个问题。首先，如果用每种母语编写，为每个平台开发不同的应用是非常昂贵的。独立游戏开发者或初创公司可能只支持一种设备，比如iPhone，但IT部门必须支持用户拥有的设备，而这些设备可能并不总是最新最好的。其次，关于原生应用更快的性能争论可能适用于3D游戏或图像处理应用，但在使用Web技术的构建良好的业务应用中，性能损失可以忽略或不明显。

就谷歌而言，它将赌注押在Web技术上，以解决平台碎片化的问题。谷歌的工程副总裁Vic Gundotra声称，“即使谷歌也不足以支持所有不同的移动平台，从苹果的App Store到黑莓、Windows mobile、Android，以及诺基亚平台的许多变体。”⁶这还是在惠普的webOS、MeeGo和其他平台出现之前。

在本文中，我们将讨论Web和本机方法的一些优点和缺点，并特别关注Web技术和本机技术之间的差距正在缩小的领域。

回到顶部

原生代码vs. Web代码

实现一个软件应用程序从代码开始。在本地代码的情况下，目前开发人员通常使用C方言编写代码，就像iPhone一样。在Nitobi (http://nitobi.com/)及PhoneGap (http://www.phonegap.com/)，从本地开发的角度来看，我们在各种手机平台上有丰富的经验。

当然，由于各种市场或组织原因，大多数开发者或团队必须支持多个智能平台上的应用程序。想要用原生代码编写应用程序，并在所有移动操作系统中运行?如果您的团队拥有随附表格中所示的技能集，则没有问题。

使事情更加复杂的是实际平台sdk(软件开发工具包)之间的差异。每个平台都有不同的工具、构建系统、api和具有不同功能的设备。事实上，这些操作系统唯一的共同点是，它们都附带一个移动浏览器，可以通过编程方式从本机代码访问该浏览器。

每个平台都允许我们实例化一个浏览器实例，无铬，并从本机代码与它的JavaScript接口交互。在Webview中，我们可以从JavaScript调用本机代码。这就是Eric Oesterle、Rob Ellis和Brock Whitten于2008年在iPhoneDevCamp上为第一个iPhone操作系统SDK所开创的PhoneGap技术。这一方法随后被移植到Android、黑莓和其他PhoneGap支持的平台上。PhoneGap是一个开源框架，它为开发人员提供了一个环境，在这个环境中，他们可以用HTML、CSS和JavaScript创建应用程序，还可以通过一个通用的JS API调用本地设备功能和传感器。PhoneGap框架包含与底层操作系统交互的本地代码片段，并将信息传回运行在Webview容器中的JavaScript应用程序。现在有了对地理定位、加速计等的支持。

什么是本机代码?它通常是编译的，这比解释语言(如JavaScript)更快。webview和浏览器使用HTML和CSS来创建功能和成功程度不同的用户界面。使用本机代码，我们可以通过通用用户界面元素和控件的专有api和抽象直接在屏幕上绘制像素。

简而言之，我们正在将JavaScript与编译语言进行较量。如今，JavaScript已经站稳了脚跟。javascript虚拟机技术成为浏览器战争的新前线并不奇怪。微软、谷歌、苹果、Opera和Mozilla都在积极迭代，以超越竞争对手的实现。⁵目前，根据一些基准(http://arewefastyet.com/)， Mozilla的蜘蛛猴正在接近谷歌的V8引擎。苹果的JavaScriptCore，在大多数WebKit浏览器(在大多数移动设备上)中都能找到，介于两者之间。最重要的是，所有主要参与者的巨额支出正在推动这场JavaScript军备竞赛。Ars Technica所示的基准图1是这些公司如何推销自己的一个例子。

JavaScript的速度越来越快，以至于惠普Palm webOS 2.0重写了它的服务层，从Java到非常流行的node.js平台(http://nodejs.org/)，它构建在谷歌的V8引擎上，以较低的CPU成本获得更好的性能(因此更长的电池寿命)。我们所看到的趋势是Web技术栈在较低的水平上运行，它现在在数百万的设备上生产。

回到顶部

用户界面代码

当涉及到用户界面时，情况就不那么美好了。大多数原生平台对常见的用户界面控件和体验都有很好的抽象。没有两个平台具有相同甚至相似的用户界面范式，更不用说实例化和访问它们的api了。在大多数情况下，Web平台是一致的，但是内置或包含sdk的控件的数量是有限的。你得自己卷。有时浏览器之间的差异会造成痛苦，但至少在现代智能手机世界中，大多数设备都使用非常强大的WebKit渲染引擎，只有很小的差异。

不幸的是，对于网络来说，这些微小的差异正变成一个大问题。例如，在iOS上，CSS position属性不正确地支持“fixed”值。(这在Android中是一个问题，但在最新的Android 2.2代码中得到了纠正。)在6.0版本之前的黑莓操作系统使用了一个完全神秘的浏览器，为此Web开发人员付出了难以估量的代价。幸运的是，RIM在6.0中解决了很多这方面的问题，总体来说，情况正在好转。

有些操作系统包括硬件加速。iOS栈在CSS转换中支持这个概念，这是一些Web框架实现视图状态之间平滑转换的方法。这一技术最早是在Dashcode中发现的。它是由David Kaneda精心逆向设计的，他在jQTouch (http://jqtouch.com/)，并在稍后的Sencha Touch中发布(http://www.sencha.com/)．这两个都是令人难以置信的Web项目，也是开发人员突破极限时可以做的事情的例子。

当我们第一次开始使用这些下一代移动浏览器时，没有一个框架能够在设备间正常工作。现在有超过20个移动框架，并且对现有的DOM(文档对象模型)库的支持正在迅速增加，不仅仅是John Resig的jQuery (http://jquery.com/)和jQuery Mobile (http://jquerymobile.com/）;该代码每天都在改进，并增加对更多设备的支持。有了这样的工具，从一个面向web的代码库支持多个目标变得越来越容易。

在对比Web技术栈和本地代码时，快速执行和漂亮的用户界面并不是全部。Web技术生活在沙箱中，这也是底层api的监狱，本地代码可以访问访问设备存储、传感器和数据的api。但这一差距也正在被弥合。例如，现在大多数移动浏览器都支持地理定位，iOS最近添加了Accelerometer和一系列其他HTML5 api。鉴于W3C有一个设备API工作组(http://www.w3.org/2009/dap/)，我们很可能会在不久的将来看到更多的api进入浏览器。如果不久的将来还不够快，你可以使用PhoneGap (http://docs.phonegap.com/)以访问这些api。

当然，Web技术栈(HTML/CSS/JS)本身是用本地代码实现的。本机层和浏览器之间的距离只有一次编译。换句话说，如果您想向浏览器添加本机功能，那么您可以桥接它或重新编译浏览器来实现该功能。如果浏览器不支持本机功能，并不是因为它不能或不愿支持;这只是说明还没有完成。

回到顶部

用户体验:环境vs.实现

对本地和Web移动应用程序开发都有很大影响的另一个领域是用户体验,我们使用这个术语来描述用户使用软件应用程序的整体体验。用户体验甚至可以扩展到应用程序之外。例如，我们可以使用推送通知在特定条件下唤醒应用程序，比如位置变化，或者生成一个新的专门构建的应用程序来处理不同的应用程序方面。显然，成功的用户体验对于成功的应用程序采用至关重要。

一般来说，一个移动软件项目的用户体验可以分为两大类:

• 的上下文必须了解但不能改变或控制的元素。这包括硬件支持、平台功能和UI约定，以及使用应用程序的环境。
• 的实现在应用程序中可以控制的元素，如性能、设计和与平台特性(如加速计数据或通知)的集成。

上下文应用程序的使用方式会影响用户的期望。单个应用程序的上下文在不同用户之间可能存在根本的差异，甚至在单个平台上也是如此。我们并不是在讨论上下文;我们实际上在谈论多个上下文。让我们看看定义成功的移动应用程序必须适应的上下文的东西。

硬件。Android设备生态系统(图2)是一个很好的例子，说明了各种各样的环境，设备在显示(物理尺寸、颜色深度、屏幕分辨率、像素密度、纵横比)方面的差异很大;输入(轨迹球、触摸屏、物理键盘、麦克风、摄像头);以及能力(处理能力、存储能力、天线等等)。

这些属性的组合将极大地影响您的应用程序的显示方式，以及用户可能选择的与它交互的可能方式的范围。如果一个特定的组合今天不存在，明天很可能存在。一个成功的应用程序必须考虑到与所有这些硬件设备相关的习惯。

平台的约定。每个平台都有自己的用户界面约定，通常在人工界面指南文档中进行描述，并在操作系统界面中得到证明。各种各样的移动Web浏览器提供了一个很好的例子，说明这些约定可以有多么不同:

一个常见的用户期望是能够在浏览器中“返回”。iOS通过虚拟按钮来满足这一要求;安卓(Android)和黑莓(BlackBerry)设备依赖于物理硬件的后退按钮;webOS使用了后退按钮和后退手势。无论使用什么方法，用户都希望他们能够在应用程序中“返回”。

用户还希望使用上下文菜单。在默认的安卓和黑莓浏览器中，上下文菜单是通过屏幕底部靠近拇指自然位置的一个物理按钮访问的。在iOS和webOS上，上下文菜单是通过位于屏幕底部靠近拇指的持久虚拟标签栏访问的。在iOS和webOs以外的设备上，屏幕底部持久的标签栏通常会产生糟糕的体验，因为用户很容易意外地点击他们的上下文菜单或后退按钮，导致应用程序意外关闭。这些都是本地应用程序和Web应用程序必须克服的限制。

开发人员必须考虑对数据和用户都有意义的方法。HTML5确实支持菜单元素的概念，因此在这里可以实现通用的抽象，但这方面的工作还有待完成。

环境是最大的不确定因素!是白天还是晚上?

用户是站着还是坐着?静止还是运动?一只手还是两只手空着?在一个繁忙的地方?变量无穷无尽。

那我们该怎么办呢?基于上下文的期望并不一定是跨平台的。本机和Web实现都必须提供支持这些期望的设计和代码。对Web开发人员来说，好消息是他们可以回到Web技术堆栈中熟悉的范式来满足用户的期望。

实现。为了产生最好的用户体验，实现必须交付支持用户特定上下文所设定的期望的设计和代码。

回到顶部

性能:软件开发的妖怪

毫无疑问，性能是优秀用户体验的基石。和安全性一样，它是软件开发人员最容易误解和经常使用的替罪羊。我们经常听到开发人员轻率地拒绝一些想法，“我们不能那样做，这会对性能产生负面影响。”性能是软件开发的妖怪，很少被量化，却经常被引用。我们如何量化绩效?延迟是性能的一种形式。执行，即执行一个操作所需的时间，是另一个问题。我们将分别讨论这些问题。

在移动世界中，延迟是一个巨大的考虑因素。无论是本机应用程序还是Web应用程序，下载应用程序及其通过网络消耗或发布的数据都有一定的性能损失。显然，有效载荷越小，应用程序就越快。

使用JavaScript对象符号(JSON)格式的数据是一个好主意，因为与等效的XML有效负载相比，它往往会导致更小的数据负载，这取决于XML的格式化方式。另一方面，XML数据在返回要插入到Web页面的HTML片段时是有意义的，而不是返回json格式的数据，后者虽然在网络上较小，但需要使用JavaScript将其转换为HTML片段。你的里程会有所不同。基准测试是唯一确定的方法。

另一个延迟问题可能是代码的初始化。一旦我们将代码放入内存中，它仍然需要被解析。在这个过程中可能会有明显的性能损失。我们可以伪造它，用确定或不确定的进度指标来增强对绩效的感知。

当然，执行时间是性能的一个关键方面。在解释代码时(就像我们用JavaScript在Web上做的那样)，需要解释的代码越多，执行时间就越长。在这方面，Web技术栈还需要迎头赶上。JavaScript虽然在性能上有飞跃，但仍然比原生版本慢。另一方面，程序员在多个移动设备上用原生编译语言编写类似的逻辑所花费的时间可能值得执行的时间损失;然而，这肯定需要更多的维护，而不是一个用JavaScript编写的可以在多个设备上运行的代码库，可能需要在每个平台上进行一些调整。更少的代码通常导致更少和更容易的维护。

也就是说，代码少的好处对期望响应界面的最终用户来说并不重要。考虑到对多个本地平台的支持，开发人员的权衡是一个更大的代码库，通常要大得多。在本机代码的世界中，主要的挑战是针对多个目标重新实现。在Web世界中，主要的挑战是尽可能地限制您的占用空间，以产生响应性的用户体验。这并不是说一个用户界面就可以满足所有环境，而是说大多数应用程序逻辑都在一个代码库中，然后可以用条件代码实现特定设备特定的UI习惯用法。因此，您可能希望实现稍微不同的功能和用户体验，以适应特定设备用户的期望。例如，Android和黑莓设备都有物理后退和菜单按钮，而iOS设备却没有。

另一个需要记住的关键点是，尽管移动行业正在迅速将WebKit作为HTML渲染引擎的实际标准，但每种设备和操作系统都有略微不同的WebKit风格。这意味着您应该期望开发类似于今天的跨浏览器Web开发。值得庆幸的是，有许多库，如jQuery Mobile、Sencha Touch和SproutCore都试图解决这个问题。

所有这些关于延迟和代码执行的讨论都意味着要严格审视应用程序开发活动的业务目标。偏好数据而非装饰是最实用的方法。渐变、阴影、斜角、压纹、高光、圆角和柏林噪声不会使应用程序有用或可用——它们不满足业务需求，但它们确实会影响性能。特别是CSS渐变，在移动世界中是真正的性能魔鬼。您需要确定您的目标是什么:看起来整洁还是为数据发布和获取提供有用的接口。通过使用本地代码进行优化(通常是硬件加速)的像素绘制，您可以在某些平台上获得其中的一些功能。并不是说这些效果是不可能实现的，而是它们应该被明智地使用，只有当它们增强而不分散用户体验时才应该使用。在市场上获得成功的优秀用户体验是可能的;它只需要适当的移动Web开发技术和良好的用户体验技能来考虑环境的限制。

回到顶部

可爱的弹跳和美丽的设计

当然，漂亮的设计很重要。从美学到无形的东西，比如一个好的程序的结构，软件设计者必须致力于伟大的设计，并建立在已经到位的坚实实践之上。通过动态物理的滚动，可爱的反弹，缓和，等等创造反应界面，感觉真实，使用起来很愉快。这是本机控件特别出色的地方。

我们还没有很好地用Web技术解决本机滚动的问题。¹有很多尝试:http://cubiq.org/iscroll), TouchScroll (http://uxebu.com/blog/2010/04/27/touchscroll-a-scrolling-layer-for-webkit-mobile/),手套箱(https://github.com/purple-cabbage/GloveBox), Sencha (http://www.sencha.com/)和jQuery Mobile (http://jquerymobile.com/)．所有这些都解决了滚动问题，但没有解决本机设备的问题。甚至谷歌移动团队也在致力于发布针对该问题的解决方案。^3.毫无疑问，这是PhoneGap团队最常听到的抱怨，但我们在WebKit中修复了一个bug，它就不会成为问题。谷歌Mobile团队最近发布了针对基于web - kit的浏览器和平台的解决方案和代码。²

这里的纲要。Web技术栈还没有达到本地代码所能达到的性能水平，但已经接近了。我们相信Web技术将变得与原生体验无异。与此同时，Web开发人员必须专注于交付数据，同时努力改进装饰。

回到顶部

展望未来

尽管本机和Web在这场争论中彼此对立，但可能的结果是一个混合解决方案。也许我们会认为计算机本身就是联网的，而且(这是我真诚的希望)任何人都可以免费访问。我们已经看到了原生网页的迹象:WebGL最近证明了浏览器内3D游戏是可能的，甚至运行《雷神之锤3》(http://media.tojicode.com/q3bsp/）！

与此同时，软件制造商必须平衡web和。-基于应用程序的主要目标、开发和业务现实以及Web在不远的将来将提供的机会的原生辩论。好消息是，在所有这些技术都进入浏览器之前，像PhoneGap这样的黑客可以帮助弥合分歧。我鼓励开发人员不要简单地识别软件开发趋势，而是要实现它们!如果Web不能满足您的特定应用程序所需的功能，那么您将有一个令人兴奋的机会来贡献并弥合过程中的Web/本机鸿沟。

相关文章
在queue.acm.org

案例研究:用户体验设计和敏捷:天衣无缝?
http://queue.acm.org/detail.cfm?id=1891739

企业级无线
布鲁斯·泽内尔和安德鲁·托伊
http://queue.acm.org/detail.cfm?id=1066065

手持设备的能源管理
马克·A·维雷达兹，劳伦斯·s·布拉克莫，威廉·r·汉堡根
http://queue.acm.org/detail.cfm?id=957768

回到顶部

回到顶部

回到顶部

回到顶部

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2011 ACM, Inc.

---

评论

---

显示所有2评论