最近Firefox OS（原來的Boot to Gecko）將mobile web進一步往前推，不僅是通過web執行環境，而是整個應用架構和執行環境，所有的API都是基於web，屬於系統級別。雖然要到明年推出商用機，在業界也是扔下石頭激起漣漪。繼雲端計算後，Web/HTML5是現在炒作當紅詞彙，之前我們在談談HTML5對生態系統的影響中從產業生態鏈的角度出發進行分析，本次將從應用的角度出發再做一些思考。

面向使用者：是web還是native的偽命題

開發者開發一個應用，針對的使用者，平臺只是依託，考慮的是在現有平臺技術上，即在可能UI/UX下，能夠為使用者提供什麼內容或服務。 開發應用的出發點是使用者，選擇web抑或是native是根據應用的特點，具體port在哪個原生平臺上，則是目標使用者以及開發者的可行的成本預算。

一切迴歸簡單的經濟學：應用面向哪些使用者，應用為使用者提供哪些價值，應用的特點是什麼，開發應用的成本和收益情況。最後根據這些決定選擇web還是native。

脫離具體應用需求，而單純討論web和native的孰優孰劣沒有意義。例如單純用覆蓋面廣來褒揚web，native實際也就兩個版本iOS和Android，多哉乎？不多也。至於還有覆蓋Symbian，BREW，考慮到使用應用的使用者人群，以及低價智慧手機的發展，這些理由並不那麼具有說服力。哪些應用適合web，哪些應用適合native才是關鍵。

一般來講，需要優秀的使用者體驗，使用系統的底層功能，即具深度需求的，適合原生應用；而重在內容體現，特別是PC瀏覽器的服務的擴充套件，側重雲端能力，即具廣度需求的，適合web應用。

深度還是廣度，依賴終端還是依賴雲端，是兩個重要維度。

底層功能，包括圖形加速，感測器的使用等等。這些據說都在HTML5中給出，確實HTML5可以給出標準的介面， 但對底層功能的支援，需要由平臺以及OEM廠商共同支撐。HTML5支援簡單的遊戲，很有懷舊感，但目前3D類的複雜圖形處理的遊戲能力仍不足。

智慧終端和智慧家居、智慧物流等相結合，如涉及到定製化，native是自然的選擇，至少早期如此。

網際網路應用，SNS、微博、報刊雜誌等之類出版行業適合web。Android碎片化程度很大，具有不同尺寸的屏，web具有自排版功能，在一定範圍可適配終端尺寸，也可在請求內容的時候，帶上尺寸，由雲端進行適配。對以網際網路雲端服務為主的廠商，終端是服務的延伸。

Mobile web技術有哪些技術欠缺

Web有很多優點，門檻低，維護成本低，避免app store分成，為何有些出版商放棄應用而壓注在web給出了出版行業，內容提供商選擇web的理由。web技術推出應用沒有問題，但是在應用經濟學中的釋出、版權保護，以及本身的安全、效率、體驗方面仍舊有欠缺。

效能制約：HTML/CSS/JS都是指令碼類語言，在web執行環境中進行解析，比二進位制執行程式碼或者中間語言java bite程式碼的效率要低，效能低於原生是無法突破的界限。

底層功能受限：HTML5支援很多本地功能，包括增加離線儲存，2D影象能力，視訊/音訊流，地理位置，訪問手機攝像頭和感測器，以及使用者介面工具。但是對深入的底層功能，利用硬體晶片的媒體處理，3D圖形庫（OpenGL的呼叫），仍然受到限制，只能呼叫經過封裝的功能。

新功能的滯後：平臺所有的新功能都會現在平臺本身，即native中實現，然後再由web執行環境支援這個新功能，native應用在使用新功能佔有商業先機，web執行環境支援最快也要到下一個版本。

版權保護問題：指令碼語言可以檢視原始碼，對保護應用的智慧財產權存在缺陷。當然，版權在雲端的內容供應商不算問題，但對於普通的需要盈利的開發者是個頭疼問題。

安全問題：iOS和Android都是將應用視為單個使用者在沙盒中執行，也就是針對程序進行安全保護措施。我們在PC上啟動一個瀏覽器，無論我們在上面開啟多少個頁面，仍是一個瀏覽器程序。HTML5具備訪問本地敏感資訊，例如聯絡人，在同個web執行環境中開啟的應用和這個應用之間是否架設藩籬。安全問題轉化為：web是否支援多程序？以及新的效能問題：若每個mobile web應用要開啟一個web runtime，是否會導致裝置資源大量消耗。

單程序和多程序的差異

需要提醒，這和HTML5無關，HTML5只是API標準介面集，並不包括系統的具體實現。

如果只能單程序，則不能利用底層原生系統提供的安全保護機制，必須提供新的安全框架。此外，單程序除了安全問題，還有一個重大問題：其中一個發生crash，將造成整個程序的crash，也即其他在該程序上執行的web也crash掉。

對於需要提醒，這和HTML5無關，HTML5只是API標準介面集，並不包括系統的具體實現。

對於通過跨平臺工具，例如PhoneGap、MoSync等對web進行，成為原生應用，有或者通過系統提供的嵌入方式，例如Android中通過對WebView控制元件，在該應用中，封裝了完整的web runtime。不同的應用是不同獨立程序，如下圖所示。這種不在我們的討論範圍中。

我們需要討論的是下面兩種情況：

1、通過widget管理器，在widget pannel中開啟的widget

2、通過URL在瀏覽器開啟，多個應用可能在不同瀏覽器視窗開啟，可能是瀏覽器不同的tag。

單程序的webkit

webkit瀏覽器，例如Android瀏覽器是單程序的。無論是開啟系統瀏覽器，還是在應用中指定url通過intent調起，系統有唯一一個程序com.android.browser。

這種情況有兩個問題需要注意：

1、穩定性和強健性問題（我一直對翻譯為魯棒性很有意見）：單個APP的crash，會引發整個browser的崩潰，即在該browser上執行的app都將崩潰。

2、安全性問題：不同App執行在同一程序。如今HTML5支援很多本地敏感操作，包括儲存、使用者資訊，如何隔離這些App，如何在一個程序內提供各自的安全。

不久前，Mozilla推出了完全意義上的web作業系統：Firefox OS。Mozilla的PC瀏覽器是支援多程序的，但不清楚在Firefox OS中是如何？必須解決單程序引發的安全問題，才可能商用。

解決之道：多程序

隨著HTML5的推廣，web能力變大，除了能夠實現更多應用，也承擔更大的責任。為了確保各應用正常執行和安全執行，解決的方式是將單一程序分為多個程序，他們之間彼此隔絕，以保證任何一個失效，不會危及全部。

多程序有不同方式，一種是應用的多程序，即父子程序，有一個主程序，有多個子程序；一種是獨立的多程序。前者父子程序具有相同的使用者ID，具有同樣的安全策略，而後者可採用原生系統的安全架構。這兩種方式都能解決穩定性和強健性。

Google的Chrome和微軟IE8率先實現多程序，接著是Mozilla的Firefox，並很快在其他基於WebKit的網路瀏覽器，例如Apple Safari實現。

WebKit2

WebKit2支援多程序，由於與原來的WebKit在API上存在不相容，所以重新命名為WebKit2。Web內容(JS，HTML、layout）在獨立的程序，和應用UI相分離，直接在框架中提供程序分離，有利於其他基於WebKit的客戶端，如chat client，mail client等可以從中受益，也就是app部分可以保持不變。

程序邊界在API邊界的下面。部分Webkit將在App的UI process中，處理應用邏輯；餘下的WebKit，WebCore和JS引擎，在web process中，處理實際的渲染。這兩個程序相互獨立，為在安全上將web process放置在sandbox中提供可能。

有兩個子系統支援程序的分離：CoreIPC，和DrawingArea。CoreIPC顧名思義，是UI程序和web程序之間的通訊，包括訊息傳遞和事件。DrawingArea是跨平臺的抽象drawing area，可有多種跨圖策略，簡單的就是共享記憶體的bitmap。

WebKit（UI Process）中的webPageProxy通過IPC，傳遞url，調起web Process程序，而web process的webkit（web process）進行網路處理，webCore進行渲染，如果一個HTML5的url存在惡意code，那麼將使對應的web process崩潰，而不會影響其他App的執行。

Chrome

Chrome是第一個支援多程序的瀏覽器，也是最負責的一個。Chrome中，程序的分解是在API邊界之上，作為一個多程序應用而優化，自己進行proxy和程序管理。也就是這是父子程序的方式，而不能像webKit2那中作為獨立的程序由系統進行安全保障，相關的工作有Chrome自己提供。

Chrome有四個主要程序型別：1、browser process（也即圖中的Host process），處理瀏覽器使用者介面和管理所有的其他程序；2、render preocess，一個render程序可以處理一個或者多個tab，在圖中舉了單個tab和多個tab的例子，即對已一個或者兩個RenderView；3、plugin process；4、extension process。

微軟IE 8瀏覽器

微軟採用了相類的實現結構，也稱為鬆耦合IE（Loosely-Coupled IE，LCIE）。從rendering process中分離開browsing process。主程序包括瀏覽器、UI和框架（windows），包含tab。多個tab可以在相同的程序中處理，但是如果具有不同安全等級則必須分開。AtviceX控制由tab程序處理。

Mozilla

Mozilla的情況，實現思路基本一樣，在資料中給出了早期的版本架構Firefox 3.6.4 beta builds的情況，那是主要是分離瀏覽器的plugin。

現在Mazilla推出了手機作業系統Firefox OS，web執行環境將成為系統所有應用的執行環境，就必然有一套行之有效的多程序機制。

參考和說明：

【注】上面各圖，帶藍色虛框的是我畫的，由於沒做程式碼級研究，為我目前所認知方式。