HTML5能取代Android和iOS应用程序吗？

大量新生移动设备的兴起，改变了互联网的未来。在技术的发展上，HTML5会取代App应用吗？或者说能够在多大程度上取代呢？

在HTML5规范中，已经加入了相机、磁力罗盘、GPS信息的支持。很多新兴浏览器也已经开始支持这些新特性。能否用一个统一的HTML5来替代android和ios并行开发的双重成本呢？以下Michael Mahemoff有一篇很详细的论述，使得借鉴。长篇E文，过敏者绕行。

注：今天自己开始仔细读一读，顺手加上大致翻译。

HTML5 VS NATIVE: THE MOBILE APP DEBATE

By Michael Mahemoff
http://www.html5rocks.com/en/mobile/nativedebate/

INTRODUCTION 说明

Mobile apps and HTML5 are two of the hottest technologies right now, and there’s plenty of overlap. Web apps run in mobile browsers and can also be re-packaged as native apps on the various mobile platforms. With the wide range of platforms to support, combined with the sheer power of mobile browsers, developers are turning to HTML5 as a “write one, run many” solution. But is it really viable? There are still compelling reasons to go native, and clearly, many developers are indeed going that route. This article is a debate on native versus the web.

移动应用程序(app)和HTML5都是目前最火的技术，二者之间也有不少重叠之处。在移动设备浏览器里运行的html5的web页面，也可以重新打包成不同平台上运行的app。目前很多浏览器都有很好的跨平台支持，（译注：firefox居然可以在android中使用和windows下同样的浏览器内核），HTML5的web方案，对开发者来说更为方便。完成一次，即可多平台使用。但这确实可行吗？仍然有许多必要原因，使得开发者选择了app开发。很明显，很多人已经在这么做了。本文将详细分析两种方案的优劣。

FEATURE RICHNESS – 功能丰富

POINT: NATIVE CAN DO MORE
正方：App里可以开发出更丰富的功能

We can divide mobile functionality into two dimensions: the experience of the app itself, and the way it hooks into the device’s ecosystem, e.g. for Android, this would be features like widgets and notifications. Native excels in both dimensions.

In terms of app experience, native apps can do more. They can easily get hold of swipe events, mutlitouch even, for those platforms which support it. They can typically act on hard keys being pressed, like Android’s search button and volume controls. They can access hardware too, like GPS and camera. And with the user’s permission, some platforms provide unfettered access to the operating system. Just try detecting how much battery remains with HTML5!

It’s more than the in-app experience though. An operating system like Android provides different ways for apps to interact with users, and indeed, with other apps. You have active widgets on the homepage. You have notifications, which show up in the device’s status bar. And you have intents, which allow your app to announce itself as providing a general service which other apps might require on occasion.

我们把移动功能分成两类。程序本身和程序与系统的结合。比如android里，加入widget图标或者通知提醒之类的。App对这两者都没问题。不用多说，这是肯定的。

COUNTERPOINT: NATIVE FEATURES CAN BE AUGMENTED, AND THE WEB IS CATCHING UP ANYWAY
反方：APP是挺强，但Web也正在迎头跟进

It’s true that many in-app features are simply beyond reach for an HTML5 app. No matter how hot your web-fu skills are, if your app is stuck in a sandbox with no camera API, it won’t be taking snaps anytime soon! Fortunately, you don’t have to be in that sandbox. If you really need your web app to take a photo, you can create a native app, one with an embedded web view which provides the bulk of the user interface. This is how the open-source PhoneGap framework operates: it fills the gap by exposing native features as web services, which the web view calls using a standard networking API. When you build a hybrid app like this, you’re also able to hook into those platform features like widgets, notifications, and intents.

Making a hybrid – native plus web – app is hardly an ideal solution. It adds complexity and applies only to web apps wrapped as native apps, rather than traditional websites accessed from a mobile browser. But it mightn’t be necessary for long. Web standards are evolving rapidly, and modern mobile browsers are keeping pace. Offline storage, geolocation, canvas graphics, and video/audio playback all enjoy widespread support among modern smarpthones, for example. Even camera is starting to be supported — as of Android 3.1, it’s possible to capture photos and videos using web standards. And the latest iOS browser supports WebSocket for 2-way streaming, as well as device orientation detection.

Overall, mobile is evolving. But the web is also evolving, and fast. Among desktop browsers alone, there are five major browser vendors evolving standards and adding features at lightning pace. While it’s not a trivial process to port these features to mobile, many of them have already made their way into the mobile browsers.

Native is a fast-moving target, but the web is closing the gap.

确实很多原生app实现的功能是HTML5望尘莫及的。不管你的web做的再牛，如果停留在一个没有摄像头支持的沙盒中，很多场合还是玩不转。幸运的是，现在没有这样的沙盒限制了。如果你需要你的web照相片，可以做一个负责照像的app，再把你的web打包进这个应用里面。开源的PhoneGap框架是这么干的。这样widget，手机提醒也都没问题了。
但这种混合开发的问题在于，增加了复杂性，而且不象传统web那样可以直接在浏览器里运行。这个问题短时间内恐怕没辙。好在现在网络标准在不断的高速扩充，先进的浏览器也在一直跟进。Android 3.1已经支持camera了。iOS浏览器也支持WebSocket和设备方向检测了。
总得来说，移动设备在发展，而web也同样在快速变化。桌面浏览器本身，有5家主要浏览器开发商在改进现有标准，丰富新的功能。所以原生App在快速前进，同时，web也在缩小差距。

PERFORMANCE

POINT: NATIVE RUNS FASTER
正方：原生APP速度更快

Native apps don’t have the web runtime barrier to deal with. They run close to the metal and can take advantage of performance boosters like GPU acceleration and multithreading.

原生APP没有瓶颈，而且可以直接调用GPU加速、使用多线程。

COUNTERPOINT: WEB RUNTIMES ARE MUCH FASTER TODAY, AND MOST APPS DON’T NEED THE SPEED ANYWAY
反方：现如今Web已经快多了，而且多数应用也用不着那么快。

It would be an understatement to say the web has gotten faster in recent years. V8, the JavaScript engine that ships with Chrome, was a major development in web performance when it launched, and since then, it has only gotten faster:

Graphic rendering engines has also sped up the web, and now hardware acceleration is starting to happen. Have a look at the speed bump provided by hardware accelerated-canvas:

In addition, the new Web Workers API makes multithreading a possibility, and modern web developers can also call on a range of performance-optimized libraries, and well-researched performance optimizion techniques. While most of those started life on the desktop web, they are still relevant to mobile, and there’s increased attention paid to mobile, e.g. performance guru Steve Souders has a page dedicated to mobile performance tools.

Not all desktop advances have made their way to every mobile platform yet, but the trends indicate they are on their way. It’s also important to note that the majority of mobile apps aren’t bleeding-edge 3D games, but fundamentally information-based: news, mail, timetables, social networks, etc. Visit a few sites from your mobile, e.g. GMail, Amazon, Twitter, and you can confirm mobile web performance is more than adequate. As for games, basic ones are already feasible with 2D canvas, and WebGL is starting to appear on mobiles – see Firefox 4. Until it’s widespread, there is a growing family of frameworks which compile WebGL apps to native apps that can take advantage of OpenGL, e.g. ImpactJS.

这说法有点落伍了。Chrome发布之时带来的Javascript V8，给Web速度带来的飞跃。而现在，计算速度变得更快了：
图片处理引擎已经使用web加速。现在硬件加速也已经开始应用了。看看用上硬件加速的canvas（图表见http://www.maximumpc.com/article/news/hardware-accelerated_chrome_7_60x_faster_previous_versions）。
要开发3D游戏的就不用抬杠了，但对于平而来说，新闻、邮件、时间管理、社交网络，这些用Web都够用了。试试Steve Souders的<a href=http://stevesouders.com/mobileperf/>手机性能测试工具</a>。 另外，越来越多的框架结合WebGL，可以发挥OpenGL的优势了。比如<a href=http://impactjs.com/>ImpactJS</a>，帮助开发JS游戏。

DEVELOPER EXPERIENCE 开发感受

POINT: NATIVE IS EASIER TO DEVELOP
原生APP好写

Native apps use robust programming languages (e.g. Java, Objective C, C++) which were designed for complex application development and have a proven track record. The APIs were designed ground-up to support the platform at hand. You can easily debug apps in desktop emulators which provide a close representation of the target device.

What makes web development particularly troublesome is the huge diversity of browsers and runtimes. When your app runs, it’s no guarantee feature X will be available. And even if it is, how will the browser implement it? Standards are open to interpretation.

原生APP使用强壮的程序语言（Java, Objective C, C++）。适合写复杂程序，经过历史验证，API丰富。在桌面环境可以方便的用模拟器测试。而Web程序的runtimes和乱七八糟的各路浏览器让人头大。

COUNTERPOINT: WEB IS OFTEN EASIER TO DEVELOP, ESPECIALLY IF TARGETING MULTIPLE DEVICES
反方：一般都是Web更简单，特别是需要兼容不同设备的时候。

Let’s tackle core technology first. It’s true that web standards were originally conceived in an era when the web was fundamentally about documents, not apps, with JavaScript built and deployed in just 10 days! But they’ve turned out to be much more capable than imagined – web developers have learned to leverage the good parts and tame the bad parts, with patterns now understood for scaleable design. Furthermore, the standards are not standing still, and efforts like HTML5, CSS3, and EcmaScript Harmony are all improving the developer experience. Whether you prefer C++ or Java or JavaScript is a matter of religious debate, and also depends on your legacy code base. But we can certainly include JavaScript as a serious contender these days.

The flipside to browser/runtime fragmentation is the fact that all these environments exist in the first place. Develop an Android app in Java, and you’re faced with a full port to Objective C to support iOS. Develop a web app once and it will run in Android and iOS, not to mention WebOS, BlackBerry, Windows Mobile and … well, that’s the theory anyway. In practice, you’ll need to tweak things for each platform if you really want to get the experience right. But you’d have to do that in native too, for most mobile operating systems – there are different versions and different devices.

The good news is “fragmentation” has always been this way on the web, and there are well-known techniques to deal with it. Most importantly, the principle of progressive enhancement urges developers to target a basic device first, and add layers of platform-specific awesomeness where it’s available. The mantra of feature detection also helps and these days, we have library support from the likes of Modernizr to support responsive web design. With judicious use of these techniques, you can expand your reach to the vast majority of devices, even old-school “feature phones”, even form factors like watches and TVs, regardless of make and OS. Witness our multi-UI demonstration at Google IO 2011, where we targeted distinct form factors (feature phone, smartphone, tablet, desktop, TV) with a common code base of logic and markup.

Web最初的功能只限于文档展示，而不是程序应用，貌似最近俩星期才有了JS。但有了JS后，web的世界马上就不一样了。更何况web不只是静止的，HTML5，CSS3，EcmaScript Harmony（谁知道这是什么？）都给开发者极大帮助。你是喜欢C++，java, JavaScript，那你的个人爱好，也是基于你已经攒下的代码。但是现在没人能否认JavaScript也和前者站在同一擂台上。
浏览器/runtime的互不兼容（碎片），反过来看做APP也是一样。用Java写了Android app，然后又要面对iOS的Objective C。如果能写一个程序，马上能在Android和iOS上运行，多省事啊。这咱还没提WebOS, BlackBerry，Windows Mobile呢。当然，这是理论上的。要是想让程序在每个平台都跑得很漂亮，得做不少调试和妥协。这对很多原生APP也是一样的。不同OS版本，不同的设备。。。
所谓的Web碎片化，一直都是如此。但好消息是现在已经有很多不错的解决办法。<a href=http://www.modernizr.com/>Modernizr</a>库，用得好的话，可以帮你兼容一大批主流设备，不管是啥系统，哪个牌子的。看看我们<a href=http://www.google.com/events/io/2011/sessions/mobile-web-development-from-zero-to-hero.html>2011年的Google IO演示</a>。

LOOK-AND-FEEL 外观和感受

POINT: NATIVE FITS PLATFORM LOOK-AND-FEEL
正方：原生APP更切合原有平台

One of the defining features of any platform is its look and feel. Users come to expect controls to be presented consistently and manipiulated in the same way. There are certain idioms which vary from platform to platform, e.g. what happens when the user performs a “long hold” (keep touching an element for several seconds)? Plaforms have standard idioms for such things, and you can’t satisfy them all with a single HTML5 app.

Furthermore, platform look-and-feel is orchestrated by the platform’s native software library, whose widgets encapsulate the kind of look and feel users expect. You get a lot of the expected look-and-feel “for free” just by using the native toolkit.

操作感受的定义之一，就是用户希望在你的程序里，用与系统连贯统一的方式来操作。不同的平台，都有一些约定俗成的习惯。比如长按按钮会有啥反应。你不能指望用一套统一的HTML5 App去满足所有用户。
此外，整个平台的操作感受都由用平台自有的软件库协调。直接调用平台工具包就能直接免费获得完整支持。

COUNTERPOINT: THE WEB HAS ITS OWN LOOK-AND-FEEL, AND YOU CAN ALSO CUSTOMIZE WEB INTERFACE FOR THOSE PLATFORMS YOU CARE ABOUT THE MOST
反方：我们Web有自己的传统，你要特想做原有平台那种感觉的web，也一样能做出来

As explained in the previous section, the way of web development is to write a basic “one size fits all” version, and then progressively enhance it. While the enhancement is typically based on features, you can also enhance it by targeting those platforms you care the most about. This is a kind of “browser detection”, which is sometimes frowned upon by the web community, mostly because there are so many possible browsers out there. But if you do view two or three platforms with a very high priority, and you’re willing to make the extra effort in order to stack up against native alternatives, this may be the way to go.

As far as the baseline version, the web has its own look-and-feel, and we can even say each mobile platform has its own “web look-and-feel” established by the default browser and web runtime. “Web look-and-feel” may be fine for your users, and in fact, allows you to achieve a greater degree of consistency with the desktop browsing experience, as well as those on other devices the user might be working with. Furthermore, there are many successful apps which don’t much support native look and feel anyway. This is certainly true of games (does your favorite mobile game follow your mobile OS’s look and feel?), and even true of more conventional apps, e.g. check out the more popular native Twitter clients on your platform of choice, and you’ll see a wide range of user-interface mechanisms at work.

前面说了，Web开发的方式，是先做一个大体适合所有平台的版本，然后再针对不同平台不断改进。当这些改进主要是针对功能时，你可以选择几个你最关心的平台做优化。类似于浏览器检测。技术论坛里的悲催技术员们，经常抱怨这事。太多不同的浏览器版本了。不过如果你优先关注两三种主流平台，是值得为他们多花点时间做做优化。
web本来就有自己的操作感受。我们也可以说，不同的默认浏览器以及运行环境造就了独特的"Web感受"。从更广的角度看，这本身就是一种用户公认的方式。此外，还有很多成功的案例并不遵循移动设备的原生操作习惯，人家也成功了。想想你最喜欢的手机游戏的界面？很多更传统的app也是一样，比如Twitter客户端。

DISCOVERABILITY
传播途径

POINT: NATIVE APPS ARE EASIER TO DISCOVER
正方：原生应用更容易接触客户

App distribution mechanisms, like Android’s Market and Apple’s App Store, have been overwhelmingly popular in recent years and are a major driving force for the entire mobile industry. Any developer can submit their native app to the marketplace, where users can discover it through a combination of browsing, searching, and getting recommendations. Not only that, but if you’ve done your job right, the glowing ratings and comments will convince users to hit the all-important install button.

象Google Play和Apple Store这样的app发布机制这几年势不可挡，推动了整个移动行业。每个程序员都能在市场里发布自己的应用。用户都挤在市场里浏览，搜索，接受推荐。不仅如此，只要你的程序够好，现有用户的打分会帮助你说服更多新的客户。

COUNTERPOINT: ACTUALLY, WEB APPS ARE EASIER TO DISCOVER
反方：其实web才容易接触到客户

The web is arguably the most discoverable medium ever created. In the humble URL, we have (in theory, at least) a unique identifier for everything ever published on the web, which includes any apps published on standard websites. Search engines make it easy to discover that content and other websites can link to it, including catalogues of web apps similar to mobile marketplaces. Indeed, any individual can share web apps with their friends by just linking to it in emails and social network messages. Links can be sent in SMS too, where mobile users will be able to click on the link and launch the app in their device’s browser.

We don’t yet have the same marketplaces where users can rate and comment on apps, but that’s changing too. Read on …

通过web找到内容，这是经过论证的可靠途径。利用URL，每一项发布的内容都有一个独立的地址，包括在网站上发布的应用程序。搜索引擎帮助发现内容，其他网站提供链接，还有一些类似应用市场的分类网站。用户还可以邮件、短信、在社交网站分享你的链接。你的应用链接可以直接在不同设备上直接打开。
web上还没有一个统一的评分系统，但这个情况也在发生改变。往下看。。。

MONETIZATION – 收费

POINT: NATIVE CAN BE MONETIZED
正方：App收费：应天意，顺民生

“6 year-old makes app during lunch hour, sells a zillion copies at $3 each”. You see that headline a lot these days, so it’s no wonder developers big and small are looking to the mobile marketplaces for monetization. Mobile platforms offer several avenues for developers to directly charge for their apps. Simplest is the one-time payment, to unlock the app for all eternity. There are also in-app payment and subscription mechanisms on offer in some platforms, and they are tightly integrated in a consistent, secure, mechanism. These newer forms of payment allow developers to convert a smash-hit app into a long-term revenue stream.

In addition to app payments, you can monetize with traditional web models, such as advertising and sponsorship.

“六岁孩子午饭时做app，$3一个，卖出几百万”。最近常听看到这样的新闻。各种大小厂商也跟着蜂拥而至，等着圈钱。应用商点帮开发商直接收费。最简单的办法，一次性收费。也有在app里再另行收费或者做订阅收费的，这帮助开发商赢得长期稳定的回报。
此外，传统网站的广告、赞助，在app里也同样适用。

COUNTERPOINT: IT’S ALWAYS BEEN POSSIBLE TO MONETIZE ON THE WEB, AND THE OPPORTUNITIES ARE GROWING
反方：网站赚钱，从来都不是问题。现在机会还越来越多

The web would not be the engine of modern industry if there weren’t ample opportunities to cash in. Although direct “pay-per-use” mechanisms haven’t yet flourished, there are various niches where subscription-based “software as a service” solutions have indeed become viable. Examples include Google Apps, 37Signals’ range of products, and premium versions of various email services. Furthermore, direct payments aren’t the only way to profit from web apps. There’s online advertising, affiliate links, sponsorships, cross-promotion to other products and services.

Having said that, it’s perfectly reasonable for a web developer to read the headlines and experience a dash of payment envy. You can’t submit a web URL to the native marketplaces, so what’s a web developer to do? What you do is create a native “wrapper app” – for each platform you want to target, create an empty native app that simply contains a web view. The web view is where you embed the real app. Then you just submit these apps to the various marketplaces (and hopefully watch the money roll in!). There are probably hundreds, if not thousands, of web-powered apps in the main marketplaces today, some of them so cunningly assimilated that we don’t even know their web apps at all.

The downside is the onus of cross-compiling to each platform. Here’s where an existing framework like PhoneGap can help. Even better, there are web services like PhoneGap Build and Apparatio under development. Point these websites to your code repository, and out pops an Android app, an iOS app, and so on…ready for you to submit to the respective stores. No installing native SDKs on your machine; all you needed to build all these native apps was a a code editor and a web browser.

Will the marketplaces ever support web apps directly, without all the overhead of wrapping them natively? It’s not yet clear. We do know that Google introduced the Chrome Web Store last year, and although it applies only to the desktop, the store has triggered interest from other browser vendors, and is overall part of a trend towards web app catalogues, including some mobile-specific attempts. It’s early days for the concept of a web store, but the signs are promising.

Web能成为现在社会的推动力，有能力用多种方式取得回报，这是基本条件。虽然使用付费并不普遍。但SaaS的模式已经相当普及了。成功案例包括Google Apps，37Signals的系列产品，各类邮件的收费版。另外，直接收费并不是web应用的唯一模式。广告、会员链接，赞助，其他产品服务的交叉推广都是可选的模式。
看着能在应用市场里直接赚钱而眼红的Web开发商们，你们不能直接把你的URL发进市场，但是做一个浏览web的app的壳子来连到自己的web上怎么样？现在市场中如果不说数以千计，至少也有上百的app这么干了。有些包装的好的，你甚至察觉不到他是一个web程序。
以后应用市场会直接支持web程序吗？这个现在还不好说，但去年Google已经建了个Chrome web store。虽然还只能从桌面电脑放问，但这已经挑起了浏览器厂商的兴趣。现在还只是个初步概念，但看起来挺有前途。

CONCLUSIONS 结论

It would be nice to declare a winner here, but right now, there is no clear winner. Some apps are best suited for native and some are best suited for the web. The web stack arguably has more momentum, but in terms of capabilities and execution qualities, native apps are moving fast too. And unless there comes a time when web technologies are a first-class citizen on the majority of mobile OSs, native will always be an important consideration.

One technique mentioned in this article is hybrid apps, and this may be the best compromise for some developers: web view where it’s possible and platform-specific native components where it’s not.

If you do choose the web path, be mindful of web standards and the principle of progressive enhancement. The web is a technology that knows how to target the multitudes of devices and operating systems around. Whether you choose to call it “fragmentation” or “diversity”, the web embraces it and you developers can benefit from all the prior art out there.

现在还看不出完胜的一方。有些应用适合做app，有一些适合用html5。目前的情况，原生APP肯定是一个很重要的选择。上面提到的混合式开发，可能是一个不错的妥协方案。能用web的时候用app调用web。web实现不了的功能用app开发。
如果你选择web方式，要在web标准和不断的改进上用心。web技术本身的优点就是能兼容大批不同的操作系统和设备。消极的看，你也可以这是碎片，但web就是一切通吃。