HTML5和本地化的对比：移动应用之辩

原作者：
来源HTML5 vs Native: The Mobile App Debate
译者Elaine.Ye

前言

---

移动应用和HTML5是目前最热门的两种技术，其彼此间存在着大量的重叠之处。Web应用运行在移动浏览器上，而且它们也可被重新包装成运行在各种移动平台上的本地化（native）应用。有着对范围广泛的各种平台的支持，结合了移动浏览器威力十足的强大功能，开发者正转向HTML5这一被称作“一次编写，多处运行”的解决方案。不过这真的可行吗？我们依然有充分的理由选择本地化，不过很明显，许多的开发者的确会选择走这一路线。本文就本地化和web之间的比较进行了一番辩论。

功能的丰富性

---

观点：本地化能做到更多

我们可以把移动功能分成两个维度：应用本身所带来的体验，和应用挂进设备的生态系统中的方式。例如，就Android来说，这会是类似小部件（widget）和通知（notification）一类的功能。本地化在这两个维度中都有过人之处。

就应用的体验来看，本地化应用可以做到更多。它们可以很容易地为那些提供支持的平台抓到滑动事件、多触摸事件；它们可以在被按下的硬式按键上提供典型的操作行为，比如说Android的搜索按钮和音量控制。它们还可以访问硬件，比如说GPS和摄像头。如果得到用户的允许的话，一些平台提供了到操作系统的不受限访问。而使用HTML5的话，就只能检测电池还有多少电量剩余！

然而这不仅仅是应用内部的体验问题。诸如Android一类的操作系统为应用提供了不同的与用户交互的方式，实际上，还有和其他应用的交互方式。你的主页上有活动的小部件（widget），你会收到通知（notification），这些通知显示在设备的状态栏上。你有一些意图（intent），允许哪些应用声明成是提供一般性服务的，哪些只是偶尔用到的。

对方观点：本地化功能可作为增强和补充，无论从哪种角度来说web都正在迎头赶上。

的确，许多应用内置的功能完全超越了HTML5应用所能实现的功能。无论你的web功夫技能多么的新鲜热辣，如果你的应用被困在一个没有摄像头API的沙盒中的话，它是不会立马就会拍出照来的！好彩的是，你没有被逼着呆在那一沙盒里面。如果你真的需要web应用拍照的话，你可以创建一个本地化应用，该应用内嵌web视图，web视图提供主要的用户界面。这就是开源的PhoneGap框架的运作方式：其通过把本地化功能暴露成web服务来填补这一差距，web视图使用一个标准的网络API来调用这些web服务。在你构建类似这样的一个混搭应用的时候，你还可以往这些平台挂入诸如小部件（wedget）、通知（notification）和意图（intent）一类的功能。

制造一种混合的——本地化的加上web的——应用很难说是一种理想的解决方案。它增加了复杂性，只能应用在被包装成本地化应用的web应用上，不能应用在从移动浏览器访问的传统web站点上，不过这可能不会是一种长期的需要。Web标准的发展迅速，当前的移动浏览器正在不断进步。离线存储、地理位置、画板图形和视频/音频回放等在当前的智能手机中都享有广泛的支持。例如，即使是摄像头也开始得到支持了——从Android 3.1开始，使用web标准来捕获照片和视频就是可能的了。最新的iOS浏览器支持双路流（2-way streaming）的WebSocket以及设备朝向检测。

总的来说，移动技术正在发生着变化，但web也在不断地发展，而且速度很快。只在桌面浏览器中，就有五家主要的浏览器厂商正在以闪电般的速度发展标准和增加功能。尽管把这些功能移植到移动设备上并不是一个简单的过程，但其中的许多厂商已经朝移动浏览器领域进发了。

本地化可用于快速迁移的目的，但web正在缩小差距。

性能

---

观点：本地化运行得更快

本地化应用不需要处理web运行时壁垒。它们几近是在硬件上运行，可利用诸如GPU加速和多线程这样的性能助推器。

对方观点：当今的Web运行时速度已经变得更快了，任何情况下大部分的应用都不需要达到这样的速度。

web在近些年来已经变得更快了，不过这样的说法有些保守。随同Chrome一起发行的Javascript引擎V8，其的推出就是web性能方面的一个主要的进化。从那时起，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基本是与文档而非应用相关的年代设想出来的，在10天之内就可以使用JavaScript构建和部署出来！不过它们已被证明，其能力是远超出了我们的想像的——web开发者已经学会了利用好的部分并制服了糟糕的部分，方法是使用现在理解成可伸缩设计的模式。此外，标准并不会坐以待毙，诸如HTML5、CSS3和EcmaScript Harmony一类的工作成果都提升了开发者的体验。你是喜欢C++还是Java还是JavaScript，这是一个个人推崇问题，而且还取决于你的历史遗留代码库。但现如今我们肯定要把JavaScript做为一个不可忽视的竞争者包括进来。

浏览器/运行时的分裂（fragmentation）的反面情况是这样的一种事实，即所有的这些环境是早先存在了的。使用Java来开发一个Android应用，你所面临的就是要把它完整地移植到Objective C上以支持iOS。开发一个web应用一次，然后它会运行在Android和iOS上，更不用提还有WebOS、BlackBerry、Windows Mobile和.......好吧，不管怎么样，这仅是一个理论而已。

好消息是，web上的“ 分裂”总是以这种方式出现的，而且可以用大家熟知的技术来对付它。最重要的一点是，渐进增强的原则要求开发者先以基本的设备为目标，然后加入一些层面，在这些层面中平台特有的耍酷功能是可用的。念一下功能检测这种咒语也是有所帮助的，现在，我们已经有了从支持Modernizer爱好者到支持响应式web设计的库。随着这些技术的合理使用，你可以把范围延展到绝大多数的设备上，甚至是老式的“功能手机”，甚至是手表和电视一类的电子产品上，完全不用考虑是哪种品牌和操作系统。Google IO 2011大会见证了我们的多UI演示，针对各种不同的电子产品（功能手机、智能手机、平板电脑、台式电脑、电视），我们使用的是一个共同的逻辑和标记代码库。

外观感觉

---

观点：本地化能够满足平台的外观感觉

任何平台都已明确的一个功能是它的外观感觉。用户希望以一致的方式来提供控制，以相同的方式进行操纵。从一个平台到另一个平台都有着一些不同的惯用做法，例如，在用户执行一个“长按住”操作（保持触摸某个元素几秒钟的时间）时会出现什么样的情况？各个平台在这些事情上都有一些标准的常用做法，你不可能使用一个HTML5应用来满足所有的这些平台。

而且，平台的外观感觉是使用平台的本地软件库精心组装起来的，库的小部件封装了用户期待的观感类型。你只要使用本地的工具包就可以“无偿”获得许多想要的观感类型了。

对方观点：web有自己的外观感觉，你还可以为那些你最关心的平台定制web界面

正如前面一节所解释的那样，web开发的方式是编写一个基本的“一刀切”的版本，然后逐步地增强它。尽管这类增强一般来说是基于功能的，但你也可以针对那些你最关心的平台进行增强。这相当于一种“浏览器检测”，这种做法有时会让web社区颇为不悦，主要是因为存在太多可能的浏览器了。但是如果你以比较高的优先级来考虑两三个平台的话，你就会愿意付出额外的努力，与本地化的做法一争高低。这也许就是要选择的做法。

就基线版本而言，web有着自己的外观感觉，我们甚至可以说，每种移动平台都有自己的由默认的浏览器和web运行时建立起来的“web外观感觉”。“web外观感觉”可能对你的用户来说感觉会很好，且实际上，其允许你使用桌面浏览体验以及用户可能正在使用的其他设备上的浏览体验来实现一种更高度的一致性。此外，许多成功的应用总之就是不怎么支持本地化的外观感觉。游戏在这方面来说倒是千真万确的（你会喜欢移动游戏按照移动操作系统一样的外观感觉来设计吗？），甚至更多的常规应用也是如此，例如，看一下你选择的平台上比较流行的本地化Twitter客户端，你就会发现各种各样的用户界面机制都在发挥着作用。

可发现性

---

观点：本地化应用更容易被发现

应用分发机制，像Android的Market和Apple的App Store，在近些年已经是在势不可挡地流行起来了，已经成为了移动行业的主要驱动力所在。任何的开发者都可以把它们的本地化应用提交到市场上，用户可以在这里通过结合浏览、搜索和获得建议的方式来发现它。不仅如此，如果你的活干得漂亮的话，不断增长的评级和评论会说服用户按下最为重要的安装按钮。

对方观点：实际上，web应用更易于被发现

web可以说是有史以来最具可发现性的媒介。就在不起眼的URL中，我们拥有了（至少理论上是）任何已发布在web上的东西的一个唯一的标识符，这其中包含了已经发布在普通的网站上的任何应用。搜索引擎使得发现这些内容变得容易，且其他的网站可以链接到它，包括类似于移动市场的web应用产品目录表。事实上，任何个人都可以通过仅是在电子邮件和社交网络信息中链接web应用就可以和他们的朋友分享这些应用。链接也可以在短信（Short Message Service，SMS）中发送，移动用户可以在短信中点击链接，然后在他们的设备浏览器中启动应用。

虽然我们还没有相同的市场可让用户对应用进行评级和评价，但这方面也正在改进中，且听下回分解......

币值化

---

观点：本地化应用可以币值化

“六岁的小家伙在一餐午饭的时间内制作了一个应用，以每个拷贝三美元的价格售出了无数份”。现如今你会看到许多这样的头条新闻。因此多大或多小的开发者都在寻求能转换成货币的移动市场已经不是奇怪的事情了。移动平台为开发者提供了几种直接为他们的应用要价的途径。最简单的一种方式是一次付费，永久解锁应用。还有就是一些平台提供了应用内置的付费和订阅机制，它们以一种一致安全的机制紧密的集成在一起。这些新的付费形式允许开发者把一个受欢迎的应用转化成一个长期的收入来源。

除了应用付费之外，你还可以使用传统的web模式，比如说广告和赞助来赚钱。

对方观点：在web上赚钱始终都是有可能的，且机会越来越多。

如果不存在大量可兑现的机会的话，web就不会是现代工业的引擎。尽管直接的“按次计费”的机制还没有获得蓬勃发展，但是存在着各种机会市场，在这类市场中，基于订阅的“作为服务的软件”这类解决方案确实已经变得可行了。这方面的例子包括Google Apps、37Signals的一系列产品，以及各种邮件服务的高级版本。而且，直接付费并不是从web应用中获利的唯一手段，还有在线广告、会员链接、赞助、与其他产品和服务的关联促销等。

话虽如此，但对于web开发者来说，读到这样的新闻头条后体会到了对这种收入的一些嫉妒，这完全是合情合理的。你不能提交一个web应用的URL到本地化应用市场上，因此web开发者该怎么办呢？你要做的就是创建一个本地化的“包装器应用”——为每个你想把它作为目标的平台，创建一个空的本地化应用，该应用简单地包含了一个web视图。这一web视图就是你嵌入真正的应用的地方。然后你只要把这些应用提交到各种市场上就行了（然后就希望能看到钱滚滚而来！）主要的一些市场上可能存在着没有上千也有上百的web驱动的应用，其中的一些做了巧妙的同化处理，我们甚至完全不知道它们是web应用。

不好的一面是要负担每个平台的交叉编译工作。在这个方面现有的诸如PhoneGap一类的框架能够提供帮助。甚至有更好的做法，比如正在开发中的PhoneGap Build和Apparatio一类的web服务。把这些网站指向你的代码资源库，然后就弹出一个Android应用、一个iOS应用等等......为你做好提交给各个商店的准备。不需要在你的机器上安装本地SDK；要构建所有的这些本地化应用，你需要的只是一个代码编辑器和一个web浏览器。

市场到底会不会在不需要付出本地化包装web应用的代价的情况下直接支持它们呢？情况还不明朗。我们只知道Google在去年引入了Chrome Web Store，尽管它只是应用在桌面环境上，但这一商店已经引发了其他浏览器厂商的兴趣，大体来说，其部分趋势的朝向是web应用目录，其中包括了一些移动环境特有的尝试。对于web商店概念来说，现在时机尚早，但有获得成功的迹象。

结论

---

在这里宣布一下谁是胜出者当然好，但是现在，还没有明显的赢家。有些应用适合于本地化而有些则最适合web方式。web堆栈（web stack）可以说势头更强，不过就功能和执行质量方面来说，本地化应用也在快速向前发展。除非等到web技术成为大多数移动OS的头等选择那一天的到来，否则的话本地化始终会是一个很重要的考虑因素。

本文中提到的一种技术是混合应用，对于一些开发者来说，这有可能是最好的折中办法：在可能的地方使用web视图，在不可能的地方使用平台特定的本地化组件。

如果你确已选择了web路径的话，就要留意web标准和渐进增强的原则。web应用是一种了解如何针对众多设备和相关操作系统的技术，不管你是把它称作“分裂”还是“多元化”，web欢迎这种做法，你的开发者可以从所有现存在用的技术中获益。

添加新评论

相关文章：

  咖啡中国化，星巴克学习巴宝莉

  HTML5、本地化：开发者可用的IE9平台预览第三版

  『黏度』网站建议，让你的网站也这样

  如何成为百万富翁：把你的应用卖他个581395次

  HTML5初探