HTML5最近两年声誉鹊起，而基于HTML5技术的产品也风生水起。感觉现在你的产品要是不和HTML5沾点边，都不好意思和客户打招呼！移动应用开发中，HTML5更是不可或缺的角色，市面上不少移动应用中间件产品都号称支持HTML5,例如PhoneGap、JQueryMobile、Sencha Touc、ExMobi、APPCAN.但在支持的程度和方式上均各有不同。

    近来移动应用开发公司Kendo最近进行了一次调查，该调查有4034位软件开发者参与，调查显示94%的软件开发者已经开始或者计划使用HTML5,其中高达63%的开发者已经使用HTML5,而只有6%的开发者称2013年前不会使用HTML5.移动开发者对于HTML5的热情依然不减，那么HTML5到底是否适合移动开发呢？ 依笔者看来HTML5只是一项技术标准，就像爱情这东西，是个理想模式；真正做产品和项目才是真实的婚姻生活，合不合适到具体应用时才清楚。

    “王子和公主最终过上了幸福的生活，可是幸福生活的第一天就要为谁做饭而吵架”.

    在技术选择上，不可以过于盲目，特别是移动应用这块领域，HTML5有太多的特殊性。

    我们选择HTML5相关的开发框架或产品，需要慎重选择。

    引擎的可控性

    目前，在手机上，基于HTML5的引擎，一般是操作系统提供商集成到ROM中，通过WebView组件来为开发者提供接口；Android中的WebView是Google提供，iOS中的UIWebView是苹果公司提供。

    2011年，很多使用WebView开发的Android程序员突然发现，原来用的好好的WebView的addJavascriptInterface接口会导致程序崩溃，这可是基于HTML5开发的基础接口；PhoneGap等库也等莫名其妙崩溃了。

    最终发现，原来是Google的WebKit引擎出现了重大BUG.

    怎么办呢？只能等Google修复这个漏洞。Google是个特立独行的公司，修复这个漏洞到手机厂商更新也费了不少时间。这可把程序员们折腾了个够呛。

    我们看市场上支持或基于HTML5的产品：那些老牌的浏览器厂商，例如腾讯的QQ浏览器、优视的UC浏览器、海豚浏览器都有自己的引擎，扩展了自己的特性；一些中间件厂商，例如烽火的ExMobi中间件，也实现了自己的解析和渲染引擎。

    仅仅是因为这些厂商兵精粮足，技术雄厚吗？肯定不是，老板不会砸冤枉钱！

    不受制于人，是一个很重要的原因。

    自身没有引擎的一些产品，因为依赖于手机ROM中引擎的实现，不得不为了兼容性而左支右绌，不停折腾，影响产品自身的稳定性。

    引擎在HTML5实现上的一致性

    相信大部分Web程序员对历史悠久的IE6浏览器一定印象深刻，这是个特立独行的浏览器，对HTML5的支持极差，导致Web代码中充斥着一行行的垃圾。

    在移动应用开发上，我们似乎可以高枕无忧了，因为无论是Android还是iOS的浏览器引擎，都是WebKit.

    难道我们忘了Microsoft了吗？

    没有策略的使用HTML5,到了WinPhone大行其道的时候，你的代码可能需要重新修补，这对程序员将是场恶梦！

    那应用本身支持浏览器引擎，嵌入到应用中不就好了吗，这样就能实现一致性，为什么一定要用操作系统本身的呢？大哉问！

    要知道标准的浏览器引擎通常非常庞大，例如WebKit就达到30M以上，用户不可能接受一个普通的应用非资源型的内容达到30M以上，例如AppStore上面有一个应用“十二星座老婆说明书”有70M,似乎就太大了。这就是为什么基于HTML5的中间件为什么通常只是用手机ROM中的浏览器引擎的原因。

    另外，无论是移植引擎还是实现自有引擎，都是个技术活，不是每个公司都有实力去做这个事情。[page]
    引擎的尺寸

    基于HTML5的Web框架或产品，通常强调其“标准性”、“灵活性”.一些产品取得了成功，例如jQuery、Ext、GWT等。

    可是，当我们把目光转向移动应用开发时，情况还是这样吗？

    在移动应用开发上，交互性能至关重要，用户对程序的尺寸也非常敏感。

    如果过分要求“标准”和“灵活性”,那么引擎势必非常庞大而复杂。

    为什么我们就不能对引擎做裁剪，专门为移动应用而定制，实现一个精巧、高效的引擎呢。

    事实上，已经有一些软件厂商就是这么做的。

    量身定做的引擎，在性能上有绝对的优势，另外还可以根据移动应用自身的特性，支持适合移动应用本身的控件和API.如烽火ExMobi中间件就裁剪了WebKit,最终尺寸只有大约3M.

    HTML5的性能问题

    如果你决定采用HTML5或者基于HTML5的中间件进行移动应用的开发，性能问题需要时刻牢记。

    也许应用完成时，你在模拟器上运行的很流畅，可是到了手机上，发现不是那么回事。

    可能你花费在性能调优上的时间，比开发应用功能消耗的时间还要多！用过JQueryMobile的开发者都知道，其自身的演示应用在中低端Android手机上本身就不流畅（另外，它的滚动条会覆盖头部，比较难看）。

    没有自身渲染引擎的HTML5中间件，通常也在性能上容易掉链子。例如，AppCan上面有个例子“星座物语”,在中低端Android手机上运行，界面比较卡顿，很难正常使用。基于移动应用中间件AppCan的1.0版本，使用iScroll组件支持界面的滚动。由于性能问题，不得不推倒重新实现2.0版本。而基于1.0版本的应用，如果要提升滚动性能，则需要重新采取2.0的方式来实现。

    再看国外的，不管是Sencha还是JqueryMobile,如果无视其性能问题，从笔者的实际经历来看，会为项目埋下危险，可能导致项目推倒重来。

    标准HTML5在描述能力上的局限性

    众所周知，标准HTML在控件描述能力上很有限，支持的控件非常有限，即使是HTML5,增加了控件类型这块，但也非常有限。

    基于HTML5的中间件，如果要支持具有高级特性的控件，需要采用DIV+CSS组合拼接的方式进行支持。

    这就会使得代码异常复杂，通常维护起来很麻烦。

    笔者随便选取了一家支持“标准HTML5”的中间件厂商的应用代码，发现仅仅是一个简单的登录输入框，其代码看起来就显得非常复杂，难以阅读。

    仅仅为了“标准”,而编写难以维护的代码，似乎令人难以理解。

    一些移动应用中间件厂商，为了解决这个问题，扩展了HTML的描述能力，虽然“不是标准”,但能简单的解决问题。

    总结

    华为的任正非有句话：让听的见炮声的人来决策。在移动应用开发上，开发者就是听得见炮声的人。笔者作为具有多年Web开发和移动应用开发经历的技术控，在经历过对“标准HTML5”开发的狂热后，现在有了相对理性的认识。建议开发者应该根据项目实际情况，来决策自己项目的技术路线，而非盲目的跟风。



【推荐阅读】量体裁衣：Html5并非大势所趋
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。