Native App和Web App孰強(qiáng)孰弱？Web App是否在將來能取代Native App？這一直是移動(dòng)互聯(lián)網(wǎng)從業(yè)者討論的話題，本文將從架構(gòu)的角度來進(jìn)行分析。

還記得C/S和B/S嗎

類似的技術(shù)趨勢(shì)之爭(zhēng)實(shí)際上已經(jīng)有很多了，我們不妨花點(diǎn)時(shí)間回顧一下十年前的C/S和B/S之爭(zhēng)。

20世紀(jì)90年代，C/S技術(shù)成熟并得到了快速發(fā)展，即系統(tǒng)是由客戶端和服務(wù)器兩部分組成?？蛻舳瞬糠值闹饕蝿?wù)是提供用戶交互的界面，控制應(yīng)用程序的邏輯。服務(wù)器負(fù)責(zé)有效地管理系統(tǒng)的資源，尤其是對(duì)安全性要求較高的數(shù)據(jù)庫管理和訪問控制等。

在C/S架構(gòu)中，對(duì)產(chǎn)品開發(fā)的要求是兩端都需要大量的開發(fā)工作。客戶端主要是針對(duì)Windows等用戶操作系統(tǒng)平臺(tái)進(jìn)行開發(fā)，使用大量與操作系統(tǒng)相關(guān)的API，開發(fā)工作量大，版本更新困難。服務(wù)器端主要是進(jìn)行數(shù)據(jù)庫管理方面的開發(fā)工作。因此，開發(fā)人員會(huì)分成兩類，基本上沒有交集。在系統(tǒng)維護(hù)上也比較復(fù)雜，最難的就是客戶端的版本控制和升級(jí)工作，給維護(hù)工作帶來很大的工作量。另外也不適合移植，如果用戶要求要支持Linux系統(tǒng)的客戶端，那就只能投入更多的客戶端人力重新開發(fā)一套客戶端軟件。

隨著三層C/S結(jié)構(gòu)、瀏覽器、腳本語言、Web技術(shù)的發(fā)展，出現(xiàn)了B/S架構(gòu)，即系統(tǒng)是由瀏覽器Browser和服務(wù)器Server兩部分組成。瀏覽器采用用戶設(shè)備上自帶的各種瀏覽器，這樣在用戶設(shè)備上無須再安裝客戶端軟件，也無須為客戶端軟件支付開發(fā)成本。服務(wù)器端采用三層或多層結(jié)構(gòu)，利用腳本語言等形成以網(wǎng)頁形式提供的用戶交互界面，然后與業(yè)務(wù)邏輯和數(shù)據(jù)庫進(jìn)行協(xié)作。顯然，相比C/S結(jié)構(gòu)，B/S一方面可以減少客戶端的開發(fā)和移植工作，節(jié)省客戶端的維護(hù)費(fèi)用；另一方面由于表示層、數(shù)據(jù)和業(yè)務(wù)邏輯都在服務(wù)器端，可以自由地進(jìn)行系統(tǒng)維護(hù)和升級(jí)工作。

但B/S結(jié)構(gòu)也有不足之處，比如受網(wǎng)絡(luò)制約，同時(shí)安全性難以控制。另外B/S也不能滿足所有的用戶需求，比如瀏覽器受安全性限制，不易于操作用戶設(shè)備上的更多資源。于是瀏覽器插件被引入進(jìn)來，通過瀏覽器插件，一些需要使用用戶本地資源的功能得以實(shí)現(xiàn)。

直到今天，Web技術(shù)已經(jīng)發(fā)展到2.0時(shí)代，Web頁面的展現(xiàn)效果已經(jīng)非常豐富，但C/S和B/S兩種架構(gòu)依然同時(shí)存在，二者的優(yōu)劣都相當(dāng)明顯，誰也無法替代對(duì)方。

Native App

Native App架構(gòu)的客戶端中包含了界面展現(xiàn)、業(yè)務(wù)邏輯、數(shù)據(jù)模型三個(gè)部分，如圖1所示。通過網(wǎng)絡(luò)訪問服務(wù)器端的各種服務(wù)。以手機(jī)導(dǎo)航軟件為例，在手機(jī)上會(huì)使用相應(yīng)操作系統(tǒng)的API開發(fā)界面，然后調(diào)度業(yè)務(wù)邏輯層的進(jìn)行功能實(shí)現(xiàn)。當(dāng)需要展現(xiàn)地圖時(shí)，如果手機(jī)上沒有地圖數(shù)據(jù)，就會(huì)使用經(jīng)緯度坐標(biāo)訪問服務(wù)器上的地圖服務(wù)，從服務(wù)器獲取地圖數(shù)據(jù)，解析后再通過界面繪制出來。在這樣的交互下，服務(wù)器端的服務(wù)獨(dú)立性較強(qiáng)，其業(yè)務(wù)形態(tài)完全是由客戶端控制和調(diào)度。

這與C/S結(jié)構(gòu)是一樣的。由于使用了客戶端的眾多特性，所以客戶端的表現(xiàn)力相當(dāng)豐富，性能較高，用戶體驗(yàn)也比較出色。但劣勢(shì)也比較明顯：客戶端的開發(fā)工作量大，邏輯復(fù)雜；客戶端不利于移植，必須針對(duì)不同的操作系統(tǒng)進(jìn)行單獨(dú)的適配開發(fā)工作；客戶端軟件升級(jí)和維護(hù)困難；服務(wù)器端要支持多客戶端，難于擴(kuò)展。

Web App

Web App基本上對(duì)應(yīng)了B/S架構(gòu)，如圖2所示?？蛻舳瞬辉傩枰_發(fā)工作，退化為使用內(nèi)置的瀏覽器與用戶交互。服務(wù)器端以HTML5、CSS3、JavaScript作為前端供瀏覽器展示，使用其他服務(wù)器端技術(shù)實(shí)現(xiàn)業(yè)務(wù)邏輯和數(shù)據(jù)庫管理。相對(duì)于C/S結(jié)構(gòu)，其最大優(yōu)勢(shì)在于無客戶端，不需要專門的開發(fā)和移植工作。即使使用WebView控件的客戶端，也易于開發(fā)和移植。另外的優(yōu)勢(shì)就是由于代碼全部在服務(wù)器端，所以易于擴(kuò)展和升級(jí)。

同樣，Web App的劣勢(shì)也比較明顯：服務(wù)器端的開發(fā)工作量大，邏輯復(fù)雜；界面響應(yīng)稍慢，性能弱；難于使用設(shè)備的特性比如傳感器、GPS定位、本地文件系統(tǒng)等。

Web App架構(gòu)圖

Hybrid App

在目前Web App受限于瀏覽器或前端技術(shù)未標(biāo)準(zhǔn)化的情況下，可以進(jìn)行組合應(yīng)用，這種應(yīng)用也被稱為Hybrid App，結(jié)構(gòu)如圖3所示。在這種結(jié)構(gòu)中，對(duì)于側(cè)重性能、體驗(yàn)、設(shè)備特性、本地?cái)?shù)據(jù)管理的部分，采用Native的方式，其余的部分采用Web方式，通過這種結(jié)合，可以有效地形成互補(bǔ)。這就像在B/S結(jié)構(gòu)上增加瀏覽器插件一樣，對(duì)二者進(jìn)行融合。

現(xiàn)在采用這種融合方案的應(yīng)用正在日漸增多，既可以發(fā)揮本地應(yīng)用的優(yōu)勢(shì)，又能有機(jī)地整合后端資源。對(duì)于需要本地化的部分，繼續(xù)采用操作系統(tǒng)的API接口進(jìn)行客戶端開發(fā)，對(duì)于適合Server端的部分，通過嵌入WebView等瀏覽器控件進(jìn)行實(shí)現(xiàn)，也可以采用像PhoneGap這樣的框架來消除網(wǎng)頁展現(xiàn)中難于使用設(shè)備本身特性的缺點(diǎn)。

Native與Web融合架構(gòu)

結(jié)語

移動(dòng)應(yīng)用并不是非此即彼，必須充分認(rèn)識(shí)到二者的特性，然后靈活地應(yīng)用在自己的產(chǎn)品架構(gòu)當(dāng)中，才能更好地平衡軟件的結(jié)構(gòu)。

作者曹文斌，是百度移動(dòng)互聯(lián)網(wǎng)事業(yè)部架構(gòu)師，主要負(fù)責(zé)制定手機(jī)客戶端產(chǎn)品的技術(shù)路線和實(shí)施方案。