HTML5与原生App大战方兴未艾 浏览器能力很重要

用过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为基础的方式，也算是这种模式。这当然是因为这种方式有不少的优点，而这，就让我们留待下回再继续介绍了。 via：王建兴

标签:HTML5浏览器相关App