用過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為基礎的方式,也算是這種模式。這當然是因為這種方式有不少的優點,而這,就讓我們留待下回再繼續介紹了。

 

作者簡介


Advertisement

更多 iThome相關內容