英语原文共 5 页，剩余内容已隐藏，支付完成后下载完整资料
移动应用程序开发 ︰ Web 与Native
这意味着如果你有不只是简单的文本、 链接和图像的这些设备之一，你将沉迷于电子邮件或阿尔法极客，希望这会成为智能手机大力发展的一年。然后，苹果改变了一切发行版的 iPhone，和我们对移动体验的期望完全更新了。
第三方 iPhone 应用程序的原计划是使用开放的 Web 技术。苹果公司甚至发布工具，这在其 Dashcode 项目。Native应用程序快速发展的前三年是风靡一时，并且，通常出于性能的原因，运营商正在不配合地比较。
这条思路上有两个问题。首先，如果每个Native语言编写的建立一个不同的应用程序为每个平台是非常昂贵。独立游戏开发者可能能够支持只是一种装置，可能新的 iPhone，但 IT 部门将不得不考虑其用户有的未必一定是用的最新最好的设备。第二，Native应用程序更快的性能参数可能适用于 3D 游戏或图像处理应用程序，但有使用 Web 技术精心打造的业务应用程序的性能损失是不明显甚至可以忽略不计的。
就谷歌本身而言，它押注于 Web 技术来解决平台碎片。谷歌工程副总裁维克称：“即使 Google 并没有足够的钱来支持所有不同的移动平台，从苹果的 App Store 到黑莓，Windows Mobile Android 以及诺基亚平台，变数实在太多了”这是在惠普 webOS，MeeGo，和其他平台出现之前。
在这篇文章中我们讨论一些Web 和Native方法的长处和弱点的，特别注意缩小 Web技术和Native的同行之间的差别。
1、Native代码与Web代码的比较
执行一个软件应用程序是从执行代码开始。对于Native代码，这几天最经常开发人员通常在写 C 语言，iPhone 是一例。在我们的工作在 Nitobi (http://nitobi.com/) 和 PhoneGap (http://www.phonegap.com/)，我们有丰富的经验与各种移动平台从Native开发角度进行对比适配。
当然，各种市场或组织上的原因导致大多数开发人员或团队必须支持应用程序在多个智能平台上发布。想要在Native代码中编写的应用程序可以每个单一的移动操作系统吗使用？没问题，如果你的团队有附件表格所示的技能配置。
什么使实际平台 Sdk （软件开发工具包） 之间的差异更复杂。有不同的工具、 构建系统、 Api 以及为每个平台具有不同功能的设备。事实上，这些操作系统的系统唯一的共同点是他们所有登录的移动浏览器可以以编程方式从Native代码访问。
每个平台可以让我们来实例化一个浏览器实例，无边框，并与从Native代码及其 JavaScript 界面交互。从在该 web 视图内我们可以调用Native代码从 JavaScript。这是后来被称为 PhoneGap 技术，为第一代 iPhone OS SDK 在 iPhoneDevCamp 2008 年被Eric Oesterle, Rob Ellis和Brock Whitten 所首倡。这种做法后来被移植到安卓，黑莓，然后到其余的平台 PhoneGap 支持。PhoneGap 是为开发人员提供的环境，在那里他们可以在 HTML、 CSS 和 JavaScript 中创建应用程序，并且仍然可以通过常见的 JS API 的开放源码框架调用Native设备功能和传感器。PhoneGap 框架包含Native代码块与底层操作系统进行交互并将信息传递回 web 视图容器中运行的 JavaScript 应用程序。现在已经支持地理定位、 加速度传感器，以及更多。
Native代码到底是什么？通常它被编译，这比编译语言，如 JavaScript 更快。Webviews 和浏览器使用 HTML 和 CSS 来创建用户界面有不同程度的方法和能力。而Native代码，我们绘制像素直接通过专有 Api 和抽象为常见用户界面元素和控件的屏幕上。
总之，我们要对抗编译语言的 JavaScript。这些天，JavaScript 在维护着自己的地位，这并不奇怪 。 JavaScript 虚拟机技术是浏览器最热门的技术。微软、 谷歌、 苹果、欧朋，Mozilla 所有迭代奋力超越竞争实现它。现在，通过一些基准 (http:// arewefastyet.com/)，Mozilla 的蜘蛛猴在谷歌的 V8 引擎关闭。苹果公司的JavaScript编码，发现在大多数 WebKit 浏览器 （这是大多数移动设备），是可用的。所有主要的参与者助长它的底线是JavaScript 军备竞赛的沉重开支。由图 1 所示的 Ars 技术基准是这些公司如何营销自己的一个例子。
JavaScript 迅速越来越快一如此之快，事实上，HP Palm webOS 2.0 改写了其服务层从 Java 到极受欢迎的 node.js 平台 (http://nodejs.org/)，这建在谷歌的 V8 引擎，以在较低的 CPU 成本下获得更好的性能 （和因此延长电池寿命）。我们看到的趋势是以较低的级别运行的 Web 技术堆栈和它是在今天数以百万计的设备生产。
2、用户界面代码
在用户界面方面，情况就不那么客观了。大多数本地平台可以精彩抽象为常见用户界面控件的经验。没有两个平台有相同，或甚至类似，用户界面模式，让孤独的 Api 来实例化并对其进行访问。大多数情况下，Web 平台是一致的但内置或包含的SDK控件的数量是有限的。你必须自己画。浏览器之间的差异有时可引起很大麻烦，但是，至少在现代智能手机世界，大多数设备支持运行非常能干的 WebKit 渲染引擎，以仅小区别使之占上风。
不幸的 web，那些小的差异花费越来越大的成本。例如，在 iOS，CSS 位置属性不正确支持值的'固定'。（这在安卓系统，是一个问题，但在最新的 Android 2.2 代码中已更正）还有早期版本的黑莓操作系统6.0 运行的浏览器很不适应Web 开发人员的理智，需要付出深不可测的代价。幸运的是，RIM 已经处理过很多这样在 6.0 和一般情况，情况正在好转。
某些操作系统包括所谓的硬件加速。IOS 堆栈著名支持这一概念在 CSS 转换，这是一些 Web 框架如何实现视图状态之间的柔滑平滑转换。它是第一次实现是在 Dashcode 技术。它由 David 金田，jQTouch 率先 (http://jqtouch.com /)精心地实现了逆向工程，随后该技术Sencha Touch (http://www.sencha.com/)也得到实现。两者都是令人难以置信的 Web 项目和时极限挑战，开发人员可以做的事情的例子。
当我们第一次开始攻入这些下一代的移动浏览器，没有跨设备正常工作的框架。今天有超过 20个的移动框架，并支持快速添加到现有 DOM （文档对象模型） 图书馆中，而最重要的是John Re-sig的 jQuery (http://jquery.com/) 和jQuery Mobile (http://jquerymobile.com /); 现在代码每天改善和支持更多的设备。有了这样的工具，它变得越来越容易并且更容易支持从单个的面向 Web 的代码库到多个目标。
Web code和native code对比，快速执行和漂亮的用户界面并不是故事的全部。Web 技术生活在沙盒中，这也是从Native代码可以访问的低层 Api 的一个障碍 ~ 可以访问存储设备、 传感器和数据的 Api。但这种差距被弥合，以大多数移动浏览器为例，如今支持地理定位和 iOS 最近添加的加速度计和一系列其他 HTML5 Api。很可能我们将会看到很多更多的 Api给出了 W3C 有设备 API 工作组 (http://www.w3.org/2009/dap/)，在不久的将来达到浏览器。很快，在不久的将来，你可以使用 PhoneGap (http://docs.phonegap.com /)访问这些 Api。
当然，Web 技术堆栈 (HTML/CSS/JS) 本身就是在Native代码中实现。Native的层和浏览器之间的距离是只是一个编译环节了。换句话说，如果你想要将Native功能添加到浏览器，然后你可以弥合这一差距或重新编译的浏览器来实现该功能。如果浏览器不具有支持Native的能力，这不是因为它不能或不会，只是意味着它未完善。
3、用户体验 ︰ 与执行上下文
另一个领域，有一个大的影响对这两个Native和移动应用程序开发的 Web 用户体验， 我们的整体经验使用这个术语的用户具有与软件应用程序。用户体验甚至可以扩展应用程序之外。例如，我们可以使用推式通知，唤醒应用根据某些条件，例如位置的更改，或生成一个新的专用应用程序处理不同的应用程序方面的问题。很明显，一个成功的用户体验是关键成功应用通过。
一般来说，手机软件项目的用户体验可以分为两个主要类别 ︰
► 上下文 — — 必须被理解，但不能改变或控制的元素。这些包括硬件启示、 平台功能和 UI规则和您的应用程序使用的环境。
► 执行 — — 可以控制应用程序，如性能、 设计和集成平台的功能，例如加速度计数据或通知中的元素。
1）上下文在您的应用程序将使用会影响用户的期望。单个应用程序的上下文可能从一个用户到下一个，甚至在单个平台上完全不同。我们没有真正谈论的上下文，我们实际上谈论多个上下文。让我们看看定义的上下文的一个成功的移动应用程序必须适应的东西。
2）硬件也会影响，Android 设备生态系统 (图 2) 是一个奇妙的例子，该品种具有显著不同的显示 （物理尺寸、 颜色深度、 屏幕分辨率、 像素密度、 长宽比）; 设备上下文输入 （轨迹球、 触摸屏、 物理键盘、 麦克风、 摄像头）;和能力 （处理电源、 存储、 触角，等等）。
这些属性的组合极大地影响将您的应用程序的显示方式和各种可能的方式，用户可以选择要与之进行交互。如果特定组合现在不存在，它很可能以后会出现。成功的应用程序必须考虑与所有这些硬件设备相关联的习惯。
3）平台的规则。每个平台都有其自己用户界面规则、 通常人机界面指南文档中所述和操作系统界面中证明这一点。各种移动 Web 浏览器提供的这些规则可以有不同的例子 ︰一个常见的用户期望是能够在浏览器中'回去'。iOS 满足这一种虚拟按钮;Android 和黑莓设备依赖于物理硬件的后退按钮;webOS 使用后退按钮和一个背的手势。无论方法，用户期望他们能够'回去'到您的应用程序。
4）用户也期望上下文菜单。在默认的 Android 和黑莓浏览器，通过物理按钮位于屏幕底部的接近自然的拇指位置访问上下文菜单。IOS 和 webOS 通过位置靠近屏幕底部拇指持久性虚拟标签栏访问上下文菜单。持久性选项卡栏上 iOS 和 webOs 的设备的屏幕底部往往产生了糟糕的体验，因为用户可以很容易不小心撞到其上下文菜单或背部按钮，导致应用程序意外关闭。这些都是的限制Native和 Web 应用程序必须作斗争。
5）开发人员必须考虑为数据和用户明智的方法。HTML5 不支持菜单单元的概念，所以通用的抽象是可能在这里，但工作尚未完成。
6）环境是最大的野生动物 ！现在是白天还是夜间？用户是站着还是坐的？站这还是运动的？一只或两只手自由吗？在一个繁忙的地方吗？变量是无穷无尽的。
我们将会在哪里？承担脱离上下文的期望本来就不是跨平台。Native和 Web 实现必须提供设计和支持这些期望的代码。Web 开发人员来说，好消息是，他们可以依靠一个熟悉的范例在 Web 技术堆栈，以满足用户的期望。
7）执行。要产生最佳的用户体验，实现必须提供支持预期用户的特定上下文所提出的设计和代码。
4、性能 ︰ 软件开发的妖怪
毫无疑问，性能是绝佳的用户体验的一个基石。像安全，它是对软件开发人员的最被人误解和经常使用的代罪羔羊。它不是经常会轻易的听到开发人员的拒绝想法，'我们不能做，它会影响性能。很少量化和经常被援引，性能是软件开发的妖怪。我们如何量化性能？延迟是性能的一种形式。执行，操作时间来执行，是另一个。我们会分别解决这些。
延迟是在移动世界中的一个非常值得考虑。无论是本地还是一个 Web 应用程序，下载一个应用程序和数据它消耗或通过网络发布的性能损失。显然，越小的有效载荷、 速度越快的应用程序。
使用 JavaScript 对象符号 JSON 格式的数据是个好主意，因为它往往会导致在较小的数据有效负载相比等效 XML 有效负载，具体取决于如何设置 XML 的格式。另一方面，XML 数据可以有意义，当返回要插入到 Web 页的 HTML 片段，而不是返回 JSON 格式的数据，而较小在电线上，需要转换为 HTML 片段，用 JavaScript。您的里程将会发生变化。中断是肯定知道的唯一方法。
另一种延迟问题可以初始化的代码。一旦我们实际上进入内存的代码，但它仍然需要被解析。在这个过程中可以有明显的性能损失。我们可以假装和增强对与确定或不确定的进度指示器的表现作为指标。
当然，执行时间是性能的一个关键方面。解释代码 （像我们一样使用 JavaScript web）时有更多的时间解释执行时间。这里是Web技术堆栈迎头赶上的一些地方。JavaScript，为其所有的飞跃，性能，仍低于Native对应。另一方面，一个程序员比较用逻辑的语言来编写Native编译多个移动设备上所花费的时间可能导致时间惩罚的执行;然而，这无疑比一个代码库写在 JavaScript 中需要更多的维护，可以在多个设备，也许每个平台上运行会有一些微调。更少的代码往往导致较少和更容易的维护。
这就是说，少代码的好处对那些期望一个灵活的界面的终端用户都无所谓。开发人员进行权衡是
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[153441]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
