Facebook引发原生开发和Html5大战何时终结?

u=2475232590,2093426352&fm=0&gp=0

用过Facebook在iOS还有Android上App的朋友,应当都知道,过去,Facebook App是使用HTML5的技术来做为用户接口的主要基础,但是使用过之前Facebook App的人应该都有诸多的不满意,像是接口的操作反应,以及执行上的速度等等,其实都不尽理想。

所以在今年八月左右,Facebook重新推出了iOS版本的App,而且做了重大的技术决定,也就是舍弃原有以HTML5为基础的架构,改用原生(native)的方式来重新打造。当这个重新以原生方式设计而成的App上架之后,立即获得广大的回响,使用者纷纷对示其运行速度及流畅,感到惊艳。

在此之后,Facebook的创办人Mark Zuckerberg 在今年九月出席《TechCrunch》Disrupt 大会时,也表示旧式以HTML5为基础的Facebook App因为反应慢而且稳定度不足,他甚至说出了”以HTML5撰写而成的Facebook App,是Facebook成立以来最大的策略错误”。使得他们决定重新开发原生版本的App。当然,新版本的Facebook App大获使用者青睐。不过,这是否说明了,对于在选择用户接口基础技术的战争中,HTML5明显落于下风呢?

对于HTML5的拥获者而言,自然不能如此轻易的吞忍下去。

有一家位在美国加州的移动App开发商——Sencha,对Facebook App的功能做了研究,并且选出了其中他们认为最难的部份,利用他们工作之余的时间,以HTML5的方式予以撰写,并且取名为”Fastbook”,挑战意味相当浓厚。

而且,他们还录制了一段影片来说明Fastbook运行速度还胜过Facebook官方的App。这结果自然又引起众多的讨论——关于以HTML5为用户接口基础技术,以及用原生方式打造,究竟二者孰优孰劣呢?

HTML/JavaScript成为服务器端应用程序开发的要角
在Web成为主流的应用程序平台之后,以HTML/JavaScript为基础技术的应用程序架构,几乎就支配、主宰了服务器端的应用程序开发。谈到了服务器上的应用程序开发,几乎快要和Web应用程序画上了等号。

除了服务器端之外,也有不少应用程序将脑筋动到了客户端的用户接口上,也就是说,利用这种以HTML/JavaScript为基础技术的应用程序架构,来做为客户端用户接口的主轴。

例如,你可以开发一个Windows上的客户端应用程序,以微软的MFC应用程序框架写成,但是,这个MFC应用程序只负责做为Windows上应用程序的起点,本身并不提供真正用户接口的功能。而这个MFC应用程序骨子里其实是内嵌一个浏览器的组件,在Windows上通常就是一个IE浏览器中的ActiveX组件。这个组件拥有完整的浏览器能力,能处理所有的HTML呈现,以及JavaScript程序的执行。

对于此组件中要加载的HTML页面内容,你可以选择将它导到远程的服务器上,也就是说,即使是在客户端应用程序所呈现的用户接口,事实上,其内容的展现、数据的取用,都可以在服务器上完成。只不过,在客户端的浏览器组件里,应用程序可以透过诸如Ajax之类的技术,和服务器端互动,并且透过JavaScript,来动态呈现各种接口上的效果。

这么一来,即使是客户端的应用程序,其实也是套用了服务器端应用程序的技术,甚至骨子里本来就是服务器端的应用程序。

除了IE这样的浏览器组件之外,像是WebKit,有不少人运用在非Windows的平台。而在Mac上,开发应用程序时,也有现成的浏览器组件可用

网页应用程序开发的先天限制

在说明这种方式的优点之前,我们先来看看这样子做有什么缺点。

首先,用户接口上的元素会受限于HTML所能提供的,也就是说,在原生的平台上,不论是Windows或是Mac OSX,不属于HTML所能提供的用户接口组件,在你的应用程序里都无法使用。

第二个问题是,由于客户端上能执行应用程序部份是以JavaScript为主(应用程序的另一部份是在服务器端),所以,一些存取本地端资源的动作,例如开启本地端的档案并进行读写等等,都是没有办法倚靠JavaScript程序来做到的。这当然是基于安全性的考虑,浏览器是不会允许自远程加载的程序存取本地端的资源,否则,使用者本机上的档案被远程的程序任意存取,肯定是个大问题。

除此之外,有很多原生应用程序上可以做的动作,是Web应用程序做不到的,这些通常是透过一些原生操作系统上的API,以及原生的程序代码才能做到的。例如,你想开发的是个影音多媒体串流的应用程序,而播放影音串流的动作,却是单纯的HTML或JavaScript程序所无法提供的。

在本文中最后要提的一个问题是,应用程序的效能会取决于浏览器组件对于HTML呈现,以及JavaScript程序运行效能的优化结果。也就是说,倘若所使用的浏览器组件先天上在呈现及运行程序上,就有效能不够快的问题,那么,想要从应用程序来改善,其难度就会很高。不过,运行效能的问题,在个人计算机上通常问题不大,在移动装置上受限于CPU的计算力,这个问题才会突显出来,待我们谈到移动装置上的App时,再回过头来细谈。

克服限制的代价——失去跨平台特性
对于采用这种方式又想要取得原生支持,或是打破对存取本地端资源限制的应用程序来说,有一个开后门的方式,使是采取各浏览器下”外挂”组件的方式。在IE的浏览器上,你可以撰写自有的ActiveX组件,它可以是用Windows原生平台上可运行的程序语言,例如C/C++写成,也可以像原生程序一样的进行任何动作,就像执行原生的程序。另一方面,JavaScript程序也可以和ActiveX组件沟通,不论是让JavaScript过程调用AcitveX的函式,或是ActiveX产生JavaScript的事件,让JavaScript程序收到来自ActiveX组件的通知,都可以做到。

这么一来,倘若你的应用程序中存在非要不可的原生功能时,就可以利用这种方式。除了IE底下的ActiveX组件之外,还有像Safari的Plugin,或是NSAPI(Netscape Server Application Programming Interface)的Plugin等等。

不过,一旦运用了此类的原生支持,你的应用程序就会失去了跨平台的特性,也就是说,原先你采用HTML/JavaScript为基础的方式,其目的之一,可能是想得到跨平台的好处(这是优点之一,容后再述),但是,一旦动用了原生的支持,这个好处就会消失一些,最起码,动用原生的部份,必须随着不同的平台而分别提供。

也就是说,如果你想要让你的应用程序兼容于Windows上和Mac上,那么,在Windows上你必须撰写一个ActiveX组件来提供原生的部份,而在Mac上,则用类似的Plugin技术,撰写等价的部份。这当然不是说,可移植性完全消失,但是,仍有一部份的程序代码,是有平台相依性的。和单纯的HTML/JavaScript的应用程序相比,跨平台的能力显然失色不少。

不过,即使是存在这些限制和麻烦,还是有愈来愈多的开发者采用这种方式来开发,当然,Facebook之前以HTML5为基础的方式,也算是这种模式。这当然是因为这种方式有不少的优点,而这,就让我们留待下回再继续介绍了

 

移动信息化交流QQ群:一号群:211029692 二号群:344692795 CIO交流群:316076815(需认证)

移动化问答社区:wenda.yidonghua.com



1 星2 星3 星4 星5 星 (还没有打分,快来打分吧!)
Loading...
 
已有 0 条评论
返回顶部

无觅相关文章插件,快速提升流量