Html5 是否适合移动应用开发

admin 发布于:2015-11-12 17:59 栏目: 浏览:692 评论:0
HTML5最近这几年声誉鹊起,而基于HTML5技术的产品也风生水起。感觉现在你的产品要是不和HTML5沾点边,都不好意思和客户打招呼!移动应用开发中,HTML5更是不可或缺的角色,市面上不少移动应用中间件产品都号称支持HTML5,例如APPCAN 、PhoneGap、JQueryMobile、SenchaTouc、ExMobi。但在支持的程度和方式上均各有不同,其中APPCAN和PhoneGap其最核心的东西就是利用了webkit内核。

 依笔者看来HTML5只是一项技术标准,就像爱情这东西,是个理想模式;真正做产品和项目才是真实的婚姻生活,合不合适到具体应用时才清楚。

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

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

 我们选择纯HTML5相关的开发框架或产品,需要慎重选择,我们以APPCAN为例,AppCan的客户端架构是以系统自带的WebView/UIWebView作为HTML5页面的解析引擎展示界面(webkit),通过桥接把系统本地能力封装为JS函数达到本地能力的调用。

 主要特点是依赖HTML5的标准作为界面展示,并自主封装了一套HTML5的UI规范,产品本身并没有系统引擎进行修改或者重构。虽说支持原生能力的窗口级扩展,但与HTML5的结合不够紧密,相对独立。我们从以下几点来分析下利用webkit作为产品架构核心的劣势。

 引擎的可控性

 目前在手机上,基于HTML5的引擎,一般是操作系统提供商集成到ROM中,通过WebView组件来为开发者提供接口;Android中的WebView是Google提供,iOS中的UIWebView是苹果公司提供,HTML5虽然本身很强大,但是作为利用它当自己产品的核心架构,却是不可控的。

 还记得2011年,很多使用WebView开发的Android程序员突然发现,原来用的好好的WebView的addJavascriptInterface接口会导致程序崩溃,这可是基于HTML5开发的基础接口;PhoneGap等库也等莫名其妙崩溃了。最终发现,原来是Google的WebKit引擎出现了重大BUG。怎么办呢?只能等Google修复这个漏洞。Google是个特立独行的公司,修复这个漏洞到手机厂商更新也费了不少时间。这可把程序员们折腾了个够呛。

 最新消息标明Google最近也准备放弃webkit内核,据TheNextWeb报道,谷歌宣布将与苹果的开源浏览器核心Webkit分道扬镳,在Chromium项目中自主研发Blink渲染引擎(即浏览器核心),内置于Chrome浏览器之中。

 在不久的将来,android手机的游览器内核势必也会放弃webkit,而采用Blink游览器内核。那么这些受制于他人技术的HTML5移动应用厂商,必将面临重大灾难。

 我们看市场上支持或基于HTML5的产品:那些老牌的浏览器厂商,例如腾 讯的QQ浏览器、优视的UC浏览器、海豚浏览器都有自己的引擎,扩展了自己的特性;一些中间件厂,也实现了自己的解析和渲染引擎。仅仅是因为这些厂商兵精粮足,技术雄厚吗?肯定不是,老板不会砸冤枉钱!不受制于人,是一个很重要的原因。

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

 引擎在HTML5实现上的一致性

 “反正我就用HTML5,不管怎么样,就目前而言,在移动应用开发上,我们似乎可以高枕无忧了,因为无论是Android还是iOS的浏览器引擎,都是WebKit”。但是我们不要忘了Microsoft。

 像APPCAN这样的厂商,没有策略的使用HTML5,到了WinPhone大行其道的时候,你的代码可能需要重新修补,这对程序员将是场恶梦!那应用本身支持浏览器引擎,嵌入到应用中不就好了吗,这样就能实现一致性,为什么一定要用操作系统本身的呢?大哉问!要知道标准的浏览器引擎通常非常庞大,例如WebKit就达到30M以上,用户不可能接受一个普通的应用非资源型的内容达到30M以上,例如AppStore上面有一个应用“十二星座老婆说明书”有70M,似乎就太大了。这就是为什么基于HTML5的中间件为什么通常只是用手机ROM中的浏览器引擎的原因。另外,无论是移植引擎还是实现自有引擎,都是个技术活,不是每个公司都有实力去做这个事情,换而言之,能够做到自己实现引擎的公司,都是具有强大技术实力和充足资金的。

 引擎的尺寸

 我们不可否认HTML5的强大之处, 基于HTML5的Web框架或产品,通常强调其“标准性”、“灵活性”。些产品取得了成功,例如jQuery、Ext、GWT等。可是,当我们把目光转向移动应用开发时,情况还是这样吗?在移动应用开发上,交互性能至关重要,用户对程序的尺寸也非常敏感。为什么我们就不能对引擎做裁剪,专门为移动应用而定制,实现一个精巧、高效的引擎呢。

 事实上,已经有一些软件厂商就是这么做的。量身定做的引擎,在性能上有绝对的优势,另外还可以根据移动应用自身的特性,支持适合移动应用本身的控件和API。国内有家中间件就裁剪了WebKit,最终尺寸只有大约3M。

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

 众所周知,标准HTML在控件描述能力上很有限,支持的控件非常有限,即使是HTML5,增加了控件类型这块,但也非常有限。基于HTML5的中间件,如果要支持具有高级特性的控件,需要采用DIV+CSS组合拼接的方式进行支持。这就会使得代码异常复杂,通常维护起来很麻烦。笔者随便选取了一家支持“标准HTML5”的中间件厂商的应用代码,发现仅仅是一个简单的登录输入框,其代码看起来就显得非常复杂,难以阅读。

 另外如果我们想扩展控件怎么办,如果仅仅利用WebKit内核本身无法做到的,不过一些利用Html5开发移动应用的厂商比如APPCAN ,即便做到了原生应用集成,也是页面级别的,也就说如果我想自定义一个按钮,都需要重新用一个页面来显示。

 那么HTML5在移动应用中该如何利用呢,虽然HTML5在移动应用开发中有很多的不足,但并不是没有使用他的场景,HTML5应用上的表现更多是由HTML/CSS渲染技术控制的,而不是由JavaScript解析生成的。如果使用正确,HTML5技术无疑可以给予你大量新增的表现效果,那么如何利用HTML5这些优点,而又不让整个应用是用HTML5进行开发的呢,国内有些中间件厂商就做到这一点,使用HTML5,只不过是其的一个控件功能罢了,把HTML5的页面通过集成的游览器控件可以很方便的进行展示,而不需要向原生程序一样集成在打包在一起。

 总结

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

返回顶部