HTML5这条路，谁先走？怎么走？

2012年对HTML5来说， 可谓流年不利。就好比NBA的湖人队和CBA的青岛队，积聚了足够的眼球和人气，但高开低走，目标从“剑指总冠军”一路下调到“如何终止连败”。 但是，这并不意味着HTML5出局了， 正如跌进乐透区的球队，也有建立王朝的那一天。

今天，依然有不少公司， 通过各种不同的技术， 围绕着HTML5这个跨平台标准来开发移动应用。HTML5这条路谁先走？怎么走？对于移动开发者来说依然是颇具战略价值的问题。以下是IT经理网对业界HTML5最新观点和动态的梳理，希望能对移动开发者选择移动技术路线有所帮助。

 

理想与现实的博弈

对于移动开发者来说，HTML5的优点和缺点都同样突出（参考阅读：移动开发的三种模式选择），对于短期的产品开发来说，HTML5的缺点更容易为人诟病：

• ● HTML5的可用性还有问题： 当德国的移动游戏开发商Wooga在2011年中宣布放弃HTML5 开发的时候， 它指出了不光是人们常说的HTML5性能的问题。 它特别提到， HTML5应用通常需要不断的连接网络以加载代码。 这样带来了很多可用性的问题。
• ● HTML5的口碑不好：最出名的就是脸书的CEO扎克伯格在今年9月TechCrunch大会上说的“我们最大的失误就是去在移动应用上押宝HTML5， 而不是原生应用”。
• ● HTML5的性能问题：HTML5在加载大图片的时候的性能会有下降。 另外， Forrest Research的分析师 Jeffrey Hammond指出， 当大量用户同时访问同一个HTML5应用时， 性能也会下降。

虽然HTML5的问题很多，但即使是Facebook的扎克伯克也从未有过抛弃HTML5的想法。 HTML5的支持者和反对者都应该注意到扎克伯格在最近的一次演讲中的一句话：

“其实我并不是想说HTML5不好， 相反， 从长期来看， HTML5是相当令人振奋的”。

从短期来看， 相信很多开发者会同意汽车租赁公司Hertz的网站开发总监Luv Tulsidas的观点：“HTML5在某些方面很擅长， 但是还能算完全成熟”。 由于有两个标准工作组开发标准， 不同的浏览器对不同功能的支持也不同。 从开发者的角度看， HTML5是一个“正在不断完善”的标准， 还远没有定稿。

不过， 开发者就是喜欢这样的挑战， 这就是为什么小到一些媒体工作室， 到媒体巨人纽约时报， 到一些大企业如Hertz或儿童读物出版商Scholastic依然乐观的认为， HTML5是跨平台移动应用开发最好的选择。 而且他们也跟随的HTML5标准的演进不断调整他们的应用。

哪些领域适合采用HTML5

采用HTML5的都是哪些公司呢， 它们为什么要采用HTML5呢？ Jeffery Hammond估计， 在移动应用中， 大约有60%是原生应用， 40%采用HTML5（他估计有10%采用了基于HTML5的中间件的方式）。

Scholastic的CIO Saad Ayub说：

我们采用HTML5的原因是， 移动设备的种类太多了， 为了每种移动设备去开发对我们来说成本太高了。 如果我们采用HTML5而不是原生应用的方式， 我们进入市场的速度就会快得多。

Hertz采用的是基于CSS开源开发框架Compass， 作为基于Javascript的HTML5开发的基础， 以此来适应多平台的需求。 开发总监Luv Tulsidas说： “我们的用户群差别化非常大， 你根本无法预测他们会通过什么渠道上来， 所以我们的应用需要能够针对各种渠道。”Luv补充道：“采用了HTML5开发框架， 你也可以做到类似原生程序的用户体验， 所以，对用户来说， 他感觉好像是一个原生程序。”

如何用HTML5开发

 

埃森哲移动部门的执行总监Aidan Quilligan提到， 他们的一些客户， 在一年或者一年半以前， 开始开发内部使用的移动应用， 最初都是采用原生的应用。 当时， 客户员工希望应用的外观和体验类似于手机上其他原生应用。

然而， 随着使用的逐渐增多， 员工们开始对应用的功能提出更多的要求， 他们希望能增添各种新的功能， 希望能够在自己的不同设备上都能使用， 这样的要求， 很多都需要后台的整合。 这也就是为什么现在很多客户开始逐渐转向基于HTML5的应用开发的原因。

采用HTML5开发的应用， 可以一次部署在不同类型的设备上。 而员工们则要求这些应用的外观和体验都能类似于他们的iOS原生应用。 所以， 有的公司就开始在HTML5环境中开发类似原生的体验。

英国的Atex公司是一个基于网站的内容管理应用开发商， 4年前， 当它开始觉得开发基于浏览器的移动版本时， 开发人员比较了Microsoft Silverlight， Adobe Flash/Flex， 以及HTML5 。 最后， 他们选择了Adobe。 但是不久， 苹果就宣布不再支持Adobe Flash。 于是他们又转到了HTML5 。

当它转到HTML5是， 发现HTML5标准的发展已经足以满足Atex的要求了。 Atex的高级营销副总裁Pete Marsh说：

“要是让我们再选择一次， 我们现在一定直接选HTML5， 它太棒了！”

Atex采用的是响应式设计（Responsive Design）来帮助它的媒体行业客户设计移动应用。 响应式设计技术结合了HTML5 和 CSS3标准， 可以帮助网站根据终端的类型， 自动调整内容和格式的样式。 来适用不同的终端。

“网页开发人员不需要为了同一个报道或者照片， 因为不同设备而开发各种不同的网页， 他们只需要开发一个网页， 这个网页会根据终端的类型进行自适应。 这样， 公司可以用同一拨开发人员开发跨平台的网站了。” Pete Marsh补充道：“响应式设计使我不必为了不同运营商， 不同的设备而去扩充开发团队了。”

Pete Marsh也承认， 响应式设计也有一些问题。 其中之一就是性能问题。 不过， 这个问题也不见得全是问题。 他说：“响应式设计的网页， 在最初加载的时候， 会比一般网页慢1到2秒， 因为最初会有一个检测设备属性的过程。 不过， 一旦加载完成， 速度就会很快了。” 所以也并不是完全不可接受。

此外， 响应式设计也有一些功能上的局限。 不过， Atex和其他一些应用开发者采用Javascript来弥补。 Pete Marsh指出， Atex有一整套关于如何把Javascript， CSS和HTML5三者结合起来的规则。 可以保证在不改变用户后台现有代码， 不影响用户的内容管理和工作流的基础上提供需要的功能。

Pete Marsh对未来支持HTML5的浏览器性能的提高也很有信心。 Forrest Research的分析师Jeffery Hammond也指出， 基于WebGL加速技术和对CSS3 更好的支持，使得HTML5在大图片支持和动画方面的性能已经提高了不少。

原生和HTML5的混搭

像Atex一样， Taqtile公司也是一个移动应用的开发商， 他们为不同机构开发跨平台的移动应用， 包括为斯坦福大学开发的用来观看体育比赛重播和查比分的应用 iCardinal， 为HyVee市场开发的购物车和折扣券应用等等。

Taqtile的创始人John Tomizuka说到：“最初，为了避免跨平台开发的复杂性， 我们用了一个跨iOS和安卓平台的开发工具， 但是这个工具的Bug太多了。 所以我们就直接开发原生应用。 但是，这样的开发太复杂了， 特别是需要代码更新的时候。” 所以， 现在Taqtile采用的一种主要依赖于HTML5混合的模式， 简化开发的同时， 也能给用户一个类似原生应用的体验。

John Tomizuka解释说：

“我们能用HTML5的地方就尽量用HTML5， 我们加了一个外壳来适用不同操作系统的菜单结构。 比如安卓系统的菜单在屏幕的上方， iOS的菜单在屏幕下方。 我们从原生应用里面调用HTML5网页， 90%的屏幕渲染是HTML5应用， 菜单和导航则是用Java或是Objective-C写的原生应用。”

他承认在HTML5应用的开发有一个学习过程，“最开始我们的应用， 就是在哪儿不停地’加载中， 加载中’ 。 后来， 我们就把HTML5代码放入缓存。 在用户下载应用的时候， 就把HTML下载到了本地， 这样的话， 我们应用的加载速度就变得飞快了。”

Taqtile在开发HTML5应用中， 还遇到一些问题。 比如对硬件设备如摄像头， 感应器等， 现有的HTML5标准并不很好的解决如何对这些硬件的进行操作。 这个问题尤其在安卓设备上更加麻烦， John Tomizuka说到“对Windows Mobile的设备， 如果你测试成功， 你就能在所有设备上运行。而对安卓系统， 有成千种设备， 很难有效地一一测试， 你就无法保证你的应用对摄像头或者感应器的操作100%没问题”

分层化的应用设计

 

日本的Wizcorp公司也是一个基于HTML5进行跨平台社交游戏开发的公司， Wizcorp的品牌经理Mark Armitage说， 在日本， 移动游戏天然的就必须是多用户的。 人们喜欢登陆进社交网络， 和朋友们分享游戏成就。

Wizcorp有一个基于Javascript, HTML5和NoSQL的游戏引擎Mithril， 它采用了开源跨平台游戏开发框架PhoneGap/Cordova， 最近， 游戏平台Gree投资了他们， 所以他们的平台也采用了部分Gree平台的元素。

“为了适应HTML5带来的挑战， 我们的工程师为此创造了一系列的插件。 我们的平台有HTML5， Gree的SDK， 还有PhoneGap/Cordova的API， 你可以把这些想象成不同的分层， 我们的插件的目的就是使得这些不同的部分能够互相工作， 同时互不干扰。”

这些插件可以让跨平台开发变得容易， 可是要想适用不断变化的HTML5标准却也并不容易， Mark Armitage说：“我们的工程师开发的期限很紧， 他们很难有时间去追踪标准的最新更新， 而标准几乎每周都有更新。”

不过， 好的方面是， 在开源社区里， 有大量的开发者都会面临同样的问题。 Mark Armitage说：“在开源社区里， 大家分享针对各种问题的最佳解决方案， 在应对不断变化的标准方面， 我们也并不是在孤军奋战”。 就像Wizcorp的高级前端工程师Micky Brunetti所说的：“我们是遇到了不少问题， 可是同时我们也学到了不少东西。”

其实， 开发者在用户界面开发的复杂性也不是从HTML5 才开始的。 从早先的Windows界面和Mac界面的开发， 到目前不同浏览器之间的适应性， 开发者一直都在为用户界面开发而努力。 埃森哲的Quilligan对HTML5的复杂性的评论是：“所有的新技术， 都需要一个完善的过程， 标准需要完善， 开发工具需要完善， 用户需要适应。 没有什么能从根本上阻碍HTML5， 它只是需要一些时间来慢慢成熟。”

工具和中间件

对移动应用的巨大需求增长， 已经开发工具的不成熟， 使得开发者需要不断的进行学习。 埃森哲移动部门的高级总监Quilligan说：

“很多客户都处于这样的矛盾中， 他们觉得移动应用潜力巨大， 然而一评估具体实施， 又觉得很麻烦。”对用户体验的担心， 对性能的担心， 以及考虑需要适应不同的安卓操作系统， 使得很多企业认为移动应用开发是一个巨大的挑战。 Quiligan说：“这些并不是不能完成， 但是需要很多努力， 因此， 对很多企业来说， 移动应用还无法进入战略层面的操作。”

不过， 在过去的2到3个季度里， 移动应用开发工具方面已经有了一些可喜的进步。

一是中间件开发工具的兴起， 中间件分为两类，一类是移动应用开发中间件， 如Kony或者Verivo的产品， 一类是移动网站开发工具， 如PhoneGap, SenchaTouch, jQueryMobile 和 Appcelerator 这样的一些生成HTML5代码也能够调用原生代码的开发框架。

这两类工具有什么不同呢，主要的区别在于多少代码跑着服务器端， 多少代码跑在客户端。移动开发中间件通常更多地代码在服务器端， 使用专门的服务器端模块与客户端通信， 而类似于PhoneGap这样的网站应用开发工具则更多的代码在客户端， 使用RESTful API与服务器端通信。

不过这样的区分其实也很难说准确， 有些移动企业开发平台（Mobile Enterprise Application Platform） 如IBM的Worklight就采用了PhonaGap来实现用户界面部分， 而在服务器端在加了大量连接性和安全性的代码。

移动企业开发平台最近起的很猛， 除了Worklight外， 还不断出现如Sybase Unwired PlatformWebMobi， AMPchroma， Agentry Mobile Platform等不同的开发平台， 这些开发平台， 很多都支持HTML5 。

此外， HTML5也并不是唯一能够实现“一次编写， 到处运行”这样跨平台要求的唯一解决方案。 现在， 也还有基于云开发平台的如Tiggzi 和 July Systems这样的的解决方案。 另外， 移动应用还可以利用云计算来解决接入和安全性等问题。