深度分析HTML在移动开发方面发展状况.docVIP

深度分析HTML5在移动开发方面的发展状况 　　“我们正在用HTML5编写我们下一套移动产品。”“是啊，这些天很多人在玩着Appcelerator，我也在玩着。”“嗯，但这并不是我要说的那种HTML5产品。” 　　最近，我有很多类似的交流对话，可能因为我正在开发一套HTML5的应用吧。就像2005年的“AJAX”，“HTML5”这个术语现在还没有被清晰地定义，在未确定这个新技术有什么优势前，它就已经被四处套用，甚至投入运营。 　　如果你在一间被热衷新技术的管理人掌控的公司里任职，如果你走运，那么漫画人物呆伯特先生可能非常愿意坐在你隔壁的小房间。 　　两种看法 　　当人们讨论移动设备上的HTML5技术时，他们通常只会有两种不同的看法。 　　从感性的角度来看，HTML5技术的渲染过程主要是由浏览器、内嵌HTML5解析器的应用程序 (如PhoneGap)、支持书签打开方式的应用程序又或者是移动手机产品(iPhone和iPad)进行的。这种技术的好处就是能重用现有的网页设计，Web开发人员也更容易上手，同时产品具备更高质量，更适用于多平台产品。也更易于调试和修正错误，并且，版本更新会更快。此消彼长，优势是它的功能，如果你像PhoneGap一样使用内嵌的架构，那么你会少很多麻烦事，劣势就是它的表现，这也是HTML5技术面临的最大难题。 　　从理性的角度来看，HTML5技术就是使用JavaScript引擎直接控制本地功能，改变移动设备上的浏览器组件。而HTML5应用上的表现问题更多是由HTML/CSS渲染技术控制的，而不是由JavaScript解析生成的。如果使用正确，HTML5技术无疑可以给予你大量新增的表现效果。目前使用HTML5技术的例子包括Appcelerator Titanium、Mobage/ngcore、Game Closure以及PhobosLabs。 　　Node.js工具包 　　以PhobosLabs的项目为例，当这个项目是使用WebKit的JavaScriptCore组件完成，在设备端使用OpenGL渲染界面，而在开发时使用HTML5的canvas组件的API开发。这就是说，开发人员可以在一个对canvas有良好支持的桌面浏览器内开发和测试他的HTML5游戏，并且当他将这个游戏放到移动设备的浏览器打开时，也会出现同样优秀(甚至更优秀)的表现效果。这种用HTML5开发的效果跟使用Node.js工具包开发的效果很相像，使用Node.js时，只需启用JavaScript引擎，而你仅需把你需要使用的Node.js组件添加到你的应用即可。 　　Appcelerator的Titanium详述了HTML5技术的概念，给我们展现了一个完整的UI工具的抽象层，这使得它可以被应用到生成其他游戏产品。意即一个HTML5应用开发人员可以通过Appcelerator的JavaScript UI库创建按钮，而Appcelerator的内部逻辑会将这个按钮转换为iOS的原生界面按钮。我们可以通过JavaScript控制界面上的原生按钮。理论上，开发人员可以不需要写一句Objective-C代码。 　　HTML5技术有它的优势，当你依然在使用JavaScript编写代码时，你可以跟那些烦人的HTML/CSS布局逻辑和样式声明说再见。你还可以跟那些优秀的调试工具说再见。但这个技术也有蹩脚的一面，像HTML5的游戏API Mobage就存在一些小毛病，canvas组件可以在屏幕相对小一点的界面顺利显示，但如果屏幕稍微变大一点，就好像Appcelerator的例子一样，在调试时，你还需要考虑界面层额外的复杂性。在这里有很多Appcelerator的负面评论，如果你能把上面的几点记在心里，那么那些负面评论其实都可以被理解。 　　问题还在浏览器 　　开发一个完整的HTML5手机应用的首要难题就是运行速度过慢。而第二大难题就是非常愚蠢的工具束缚，许多组件或多或少在不同浏览器都存在一些漏洞，如jQuery Mobile的导航组件、iOS的innerHTML组件的漏洞，所以你需要减少功能去避免出现漏洞，又或者你愿意花一些时间去修复这些漏洞。 　　你可以自己做个实验，当你在一个iOS应用里仅使用一至两个界面库时，再加上你自己写的少量JavaScript代码，没有更多的JavaScript库，你会发现这个HTML5应用运行得流畅而完整，但却没什么功能。PhoneGap的iOS项目仅需要1至2秒的时间就可以在iPhone 3GS上发布运行。这个事实可以告诉你，最基本的HTML5应用运行起来真的非常流畅。所以，当你发现你的HTML5应用的某些操作花费了10-15秒时间时，又或者花了15秒时间才加载完整个程序时，这都是一些JavaScript界面库给拖累的。 　　两套有代表