移动应用之争
简介
移动应用和 HTML5 是目前最热门的两项技术，两者之间存在大量重叠。Web 应用可在移动浏览器中运行，也可在各种移动平台上重新打包为原生应用。由于需要支持的平台种类繁多，再加上移动浏览器的强大功能，开发者纷纷转向 HTML5，将其作为“一次编写，多处运行”的解决方案。但这种解决方案真的可行吗？原生应用仍然有其优势，显然，许多开发者确实选择了原生应用。本文将探讨原生应用与 Web 应用之争。
功能丰富性
观点：原生应用的功能更强大
我们可以从两个维度来划分移动功能：应用本身的体验，以及应用与设备生态系统的连接方式。例如，对于 Android，这包括 widget 和通知等功能。原生应用在这两个维度上都表现出色。
就应用体验而言，原生应用的功能更强大。它们可以轻松获取滑动事件，甚至多点触控事件（对于支持多点触控的平台）。 它们通常可以响应按下的硬键，例如 Android 的搜索按钮和音量控制按钮。它们还可以访问硬件，例如 GPS 和摄像头。在获得用户许可后，某些平台会提供对操作系统的完全访问权限。不妨尝试使用 HTML5 检测剩余电量！
这不仅仅是应用内的体验。Android 等操作系统为应用提供了与用户互动以及与其他应用互动的方式。您可以在首页上使用活跃的 widget。您可以使用通知，这些通知会显示在设备的状态栏中。您可以使用 intent，让应用声明自己提供其他应用可能偶尔需要的通用服务。
反驳：原生功能可以增强，而且 Web 应用也在迎头赶上
诚然，许多应用内功能对于 HTML5 应用来说是遥不可及的。无论您的 Web 技术有多么高超，如果您的应用被困在没有摄像头 API 的沙盒中，它都不会很快拍照！幸运的是，您不必被困在沙盒中。如果您确实需要 Web 应用拍照，可以创建一个原生应用，其中包含一个嵌入式网页视图，该视图提供大部分界面。这就是开源 PhoneGap 框架的运作方式：它通过将原生功能作为 Web 服务公开来填补空白，网页视图使用标准网络 API 调用这些服务。当您构建这样的混合应用时，还可以连接到微件、通知和 intent 等平台功能。
制作混合应用（原生应用 + Web 应用）并非理想的解决方案。它增加了复杂性，并且仅适用于封装为原生应用的 Web 应用，而不适用于通过移动浏览器访问的传统网站。但这种情况可能不会持续太久。Web 标准正在迅速发展，现代移动浏览器也在紧随其后。 例如，离线存储、地理位置、画布图形和视频/音频 播放都受到现代智能手机的广泛支持。 甚至摄像头也开始受到支持 - 从 Android 3.1 开始，可以使用 Web 标准拍摄照片和视频。最新的 iOS 浏览器支持双向流式传输的 WebSocket，以及设备方向检测。
总而言之，移动技术正在发展。但 Web 技术也在发展，而且发展速度很快。仅桌面浏览器就有五大浏览器供应商，它们以闪电般的速度发展标准并添加功能。 虽然将这些功能移植到移动设备并非易事，但其中许多功能已进入移动浏览器。
原生应用是一个快速发展的目标，但 Web 应用正在缩小差距。
性能
观点：原生应用运行速度更快
原生应用没有 Web 运行时障碍需要处理。它们在底层运行，可以利用 GPU 加速和多线程等性能提升工具。
反驳：Web 运行时现在快得多，而且大多数应用都不需要这种速度
如果说 Web 技术在最近几年变得更快了，那还是轻描淡写。V8 是 Chrome 附带的 JavaScript 引擎，在推出时是 Web 性能方面的一项重大发展，此后，它的速度只会越来越快：
图形渲染引擎也加快了 Web 的速度，现在硬件加速也开始出现。请查看硬件加速画布提供的速度提升：
此外，新的 Web Workers API 使多线程成为可能，现代 Web 开发者还可以调用一系列经过性能优化的库，以及经过充分研究的性能优化技术。虽然其中大多数都始于桌面 Web，但它们仍然与移动设备相关，并且人们越来越关注移动设备，例如性能专家 Steve Souders 专门有一个页面介绍移动性能工具。
并非所有桌面技术进步都已进入每个移动平台，但趋势表明它们正在进入。另请注意，大多数移动应用并非尖端的 3D 游戏，而是基于信息：新闻、邮件、时间表、社交网络等。不妨在移动设备上访问一些网站，例如 Gmail、Amazon、Twitter，您会发现移动 Web 性能绰绰有余。至于游戏，基本游戏已经可以使用 2D 画布实现，WebGL 也开始出现在移动设备上 - 请参阅 Firefox 4。在它广泛普及之前，越来越多的框架会 将 WebGL 应用编译为可以利用 OpenGL 的原生应用，例如 ImpactJS。
开发者体验
观点：原生应用更易于开发
原生应用使用强大的编程语言（例如 Java、Objective C、C++），这些语言专为复杂的应用开发而设计，并且拥有良好的记录。这些 API 从一开始就旨在支持手边的平台。您可以在桌面模拟器中轻松调试应用，这些模拟器可以准确地表示目标设备。
Web 开发特别麻烦的原因在于浏览器和运行时的种类繁多。当应用运行时，无法保证功能 X 可用。即使可用，浏览器又将如何实现它？标准可以有多种解读。
反驳：Web 应用通常更易于开发，尤其是在面向多种设备时
我们先来了解核心技术。诚然，Web 标准最初是在 Web 基本上是关于文档而不是应用的时代构思的，JavaScript 仅在 10 天内构建和部署！但事实证明，它们的功能比想象的要强大得多 - Web 开发者已经学会了利用好的部分并驯服坏的部分，现在已经了解了可扩展设计的模式。此外，这些标准并非一成不变，HTML5、CSS3 和 EcmaScript Harmony 等工作都在改善开发者体验。您是喜欢 C++、Java 还是 JavaScript，这取决于您的个人偏好，也取决于您的旧代码库。但我们现在肯定可以将 JavaScript 视为一个强有力的竞争者。
浏览器/运行时碎片化的另一面是，所有这些环境都存在。在 Java 中开发 Android 应用，您需要完全移植到 Objective C 才能支持 iOS。Web 应用只需开发一次，即可在 Android 和 iOS 中运行，更不用说 WebOS、BlackBerry、Windows Mobile 等。实际上，如果您真的想获得正确的体验，则需要针对每个平台进行调整。 但您也必须在原生应用中这样做，因为大多数移动操作系统都有不同的版本和不同的设备。
好消息是，Web 上的“碎片化”一直都是这样，并且有众所周知的技术来处理它。最重要的是，渐进式增强原则促使开发者首先面向基本设备，并在可用时添加特定于平台的强大功能层。Modernizr通过明智地使用这些技术，您可以将覆盖范围扩大到绝大多数设备，即使是老式的“功能手机”，甚至是手表和电视等设备，无论其制造商和操作系统如何。请观看我们在 Google IO 2011 上的多界面演示， 其中我们使用通用的逻辑和标记代码库面向不同的设备类型（功能手机、智能手机、平板电脑、桌面设备、电视）。
外观和风格
观点：原生应用符合平台的外观和风格
任何平台的标志性特征之一就是其外观和风格。用户希望控件以一致的方式呈现并以相同的方式操作。某些惯用语因平台而异，例如，当用户执行“长按”（持续触摸元素几秒钟）时会发生什么？ 平台对此类事物有标准惯用语，您无法通过单个 HTML5 应用满足所有这些惯用语。
此外，平台的外观和风格由平台的原生软件库编排，其 widget 封装了用户期望的外观和风格。只需使用原生工具包，您就可以“免费”获得许多预期的外观和风格。
反驳：Web 应用有自己的外观和风格，您还可以为最关心的平台自定义 Web 界面
如上一部分所述，Web 开发的方式是编写一个基本的“通用”版本，然后逐步增强它。虽然增强通常基于功能，但您也可以通过面向最关心的平台来增强它。这是一种“浏览器检测”，有时会受到 Web 社区的反对，主要是因为存在太多可能的浏览器。但是，如果您确实非常重视两三个平台，并且愿意付出额外的努力来与原生替代方案竞争，那么这可能是可行的方法。
就基准版本而言，Web 应用有自己的外观和风格，我们甚至可以说每个移动平台都有自己的“Web 外观和风格”，由默认浏览器和 Web 运行时建立。“Web 外观和风格”可能适合您的用户，事实上，它还可以让您与桌面浏览体验以及用户可能使用的其他设备上的体验保持更高的一致性。此外，许多成功的应用并不太支持原生外观和风格。对于游戏来说，这肯定是正确的（您最喜欢的移动游戏是否遵循移动操作系统的外观和风格？），甚至对于更传统的应用也是如此，例如，在您选择的平台上查看更受欢迎的原生 Twitter 客户端，您会看到各种各样的界面机制在运行。
曝光度
观点：原生应用更易于发现
Android Market 和 Apple App Store 等应用分发机制近年来非常受欢迎，是整个移动行业的主要推动力。任何开发者都可以将其原生应用提交到应用商店，用户可以通过浏览、搜索和获取推荐来发现这些应用。不仅如此，如果您做得好，用户会看到好评如潮，并点击最重要的“安装”按钮。
反驳：实际上，Web 应用更易于发现
可以说，Web 是有史以来最易于发现的媒介。在不起眼的网址中，我们（至少在理论上）为 Web 上发布的所有内容提供了一个唯一标识符，其中包括在标准网站上发布的任何应用。搜索引擎可以轻松发现这些内容，其他网站也可以链接到这些内容，包括类似于移动应用商店的 Web 应用目录。事实上，任何人都可以通过在电子邮件和社交网络消息中链接到 Web 应用来与朋友分享这些应用。链接也可以通过短信发送，移动用户可以点击链接并在设备浏览器中启动应用。
我们还没有相同的应用商店，用户可以在其中对应用进行评分和评论，但这种情况也在发生变化。请继续阅读…
创收
观点：原生应用可以创收
“6 岁儿童在午休时间制作应用，以 3 美元的价格售出 10 亿份”。您最近经常看到这样的标题，因此，无论大小开发者都希望通过移动应用商店创收也就不足为奇了。移动平台为开发者提供了多种直接收取应用费用的途径。最简单的方式是一次性付款，以永久解锁应用。某些平台还提供应用内付款和订阅机制，并且这些机制紧密集成在一个一致、安全的机制中。这些较新的付款方式让开发者可以将热门应用转化为长期收入来源。
除了应用付款之外，您还可以使用传统的 Web 模式（例如广告和赞助）创收。
反驳：Web 应用一直可以创收，而且机会越来越多
如果没有充足的创收机会，Web 就不会成为现代工业的引擎。虽然直接的“按使用付费”机制尚未蓬勃发展，但在各种细分市场中，基于订阅的“软件即服务”解决方案确实已变得可行。例如，Google Apps、37Signals 的一系列产品以及各种电子邮件服务的付费版本。 此外，直接付款并不是从 Web 应用中获利的唯一方式。还有在线广告、联盟链接、赞助、与其他产品和服务的交叉推广。
话虽如此，Web 开发者看到这些标题并产生一丝付款羡慕之情也是完全合理的。您无法将 Web 网址提交到原生应用商店，那么 Web 开发者该怎么办？您需要做的是创建一个原生“封装应用” - 对于 您要面向的每个平台，创建一个仅包含网页视图的空原生应用。网页视图是您嵌入实际应用的地方。然后，您只需将这些应用提交到各个应用商店（并希望看到收入滚滚而来！）。如今，主要应用商店中可能有数百甚至数千个由 Web 提供支持的应用，其中一些应用巧妙地融入了原生应用，以至于我们根本不知道它们是 Web 应用。
缺点是需要针对每个平台进行交叉编译。这时，PhoneGap 等现有框架可以提供帮助。 更好的是，PhoneGap Build 和 Apparatio 等 Web 服务正在开发中。将这些网站指向您的代码库，然后就会弹出 Android 应用、iOS 应用等，供您提交到相应的应用商店。无需在您的机器上安装原生 SDK；您只需一个代码编辑器和一个 Web 浏览器即可构建所有这些原生应用。
应用商店是否会直接支持 Web 应用，而无需将它们封装为原生应用？目前尚不清楚。我们知道，Google 去年推出了 Chrome 应用商店，虽然它仅适用于桌面设备，但该应用商店已引起其他浏览器供应商的兴趣，并且总体上是 Web 应用目录趋势的一部分，包括一些特定于移动设备的尝试。Web 应用商店的概念尚处于初期阶段，但迹象令人鼓舞。
总结
我们很想在此宣布获胜者，但目前还没有明显的获胜者。有些应用最适合原生应用，有些应用最适合 Web 应用。Web 堆栈可以说更具发展势头，但在功能和执行质量方面，原生应用也在快速发展。除非 Web 技术在大多数移动操作系统上成为一流公民，否则原生应用始终是一个重要的考虑因素。
本文中提到的一项技术是混合应用，对于某些开发者来说，这可能是最佳的折衷方案：在可能的情况下使用网页视图，在不可能的情况下使用特定于平台的原生组件。
如果您选择 Web 路径，请注意 Web 标准和渐进增强原则。Web 是一项知道如何面向众多设备和操作系统的技术。无论您选择称之为“碎片化”还是“多样性”，Web 都接受它，而您开发者可以从所有在先技术中受益。