TechTarget 原創(chuàng)
很多年以來(lái)，開(kāi)發(fā)者一直在為使用web應(yīng)用而不是原生移動(dòng)app尋找各種充分理由。這些觀點(diǎn)認(rèn)為，原生app創(chuàng)建和維護(hù)的代價(jià)很大；而響應(yīng)式web應(yīng)用則利用了一個(gè)代碼庫(kù)和設(shè)計(jì)來(lái)支持所有設(shè)備。
你不需要舍近求遠(yuǎn)去尋找Web應(yīng)用觀點(diǎn)的對(duì)立面，但是在這場(chǎng)爭(zhēng)論中，行動(dòng)也許要?jiǎng)龠^(guò)言語(yǔ)。2016年，GovInsider上面的一篇文章煽動(dòng)了移動(dòng)平臺(tái)之爭(zhēng)的氣焰。在那篇文章中，英國(guó)政府?dāng)?shù)字服務(wù)（GDS）的前設(shè)計(jì)負(fù)責(zé)人Ben Terret討論了該機(jī)構(gòu)禁止原生app開(kāi)發(fā)而是轉(zhuǎn)向采用公共UX框架的HTML5 web應(yīng)用的理由。這些理由主要圍繞著大量的原生移動(dòng)應(yīng)用開(kāi)發(fā)和維護(hù)的巨大成本而展開(kāi)。
（圖片來(lái)源于網(wǎng)絡(luò)）
那么你是否也應(yīng)該取締原生移動(dòng)應(yīng)用呢？它們的開(kāi)發(fā)成本值得嗎？做出這一決定的條件是什么呢？
本土化
隨著iPhone的推出，其進(jìn)入的代價(jià)是通過(guò)蘋(píng)果應(yīng)用商店流通的編譯過(guò)的Objective-C二進(jìn)制代碼的分發(fā)。對(duì)于一般web開(kāi)發(fā)者學(xué)習(xí)來(lái)說(shuō)，Objective-C并非最友好的語(yǔ)言，但至少還有一個(gè)平臺(tái)，以及一個(gè)迅速形成的活躍社區(qū)來(lái)提供支持和鼓勵(lì)。
那是9年前的事了，在此后的這段時(shí)間里，Google推出了使用Java作為原生語(yǔ)言的Android，而萬(wàn)維網(wǎng)聯(lián)盟（W3C）則設(shè)計(jì)和采用了HTML5，這一協(xié)議的特性使得響應(yīng)式web應(yīng)用實(shí)用化，而像Xamarin和PhoneGap （Apache Cordova）這樣的跨平臺(tái)庫(kù)的出現(xiàn)則試圖集采這兩個(gè)世界的最好一面。在經(jīng)過(guò)將近10年的演進(jìn)之后，現(xiàn)在基本上你可以選擇4條道路：原生、跨平臺(tái)、web以及混合應(yīng)用，每一個(gè)都各有所長(zhǎng)。
考慮到特殊的一組用戶需求，原生app開(kāi)發(fā)仍然可能是最昂貴的一條路，尤其是在大量異構(gòu)設(shè)備的環(huán)境下。為了同時(shí)在Android和iOS設(shè)備上面部署，你需要精通Java以及Objective-C或者蘋(píng)果新的Swift語(yǔ)言的工程師。每一種情況下工具鏈，部署路徑，發(fā)布許可條件以及支持需求都不一樣。
此外，由于這些辦法依靠用戶主動(dòng)將編譯的二進(jìn)制代碼放到自己設(shè)備上，所以你沒(méi)有辦法在客戶始終升級(jí)新的帶每一個(gè)變更集的二進(jìn)制版本的情況下更新客戶體驗(yàn)。當(dāng)然你可以通過(guò)REST API利用公共的后端，但是在客戶端，那個(gè)世界的樣子很像1995年的時(shí)候。
（圖片來(lái)源于網(wǎng)絡(luò)）
Web和混合應(yīng)用
而在另一端，帶響應(yīng)式標(biāo)記和CSS風(fēng)格的HTML5 web應(yīng)用則是成本最低的替代方案。雖然在兼容瀏覽器上web應(yīng)用有一些新能力，但基本上這仍然是web開(kāi)發(fā)。設(shè)計(jì)師需要高度擅長(zhǎng)創(chuàng)建可伸縮的標(biāo)記，能夠在大范圍的設(shè)備上顯示正確。開(kāi)發(fā)者可以接觸到很酷的新功能，比如WebSockets和被存儲(chǔ)，但基本工具仍然是HTML，JavaScript以及web框架，所有這些東西你的團(tuán)隊(duì)已經(jīng)在用并且很熟悉。
而中間方案的成本規(guī)模也是折中的。類(lèi)似上述提到的那些跨平臺(tái)框架可以讓你的團(tuán)隊(duì)用一種語(yǔ)言（比如說(shuō)JavaScript或者C#）編寫(xiě)，然后編譯出適應(yīng)不同設(shè)備平臺(tái)的二進(jìn)制代碼。這些二進(jìn)制代碼通常要大很多，往往會(huì)大一個(gè)數(shù)量級(jí)，因?yàn)楸仨毎阉械墓矌?kù)代碼都包含進(jìn)去，而用戶界面模式和設(shè)計(jì)概念往往是能做所有支持設(shè)備上工作的各種組件的最小公約數(shù)。在開(kāi)發(fā)和支持方面，相對(duì)于原生開(kāi)發(fā)，跨平臺(tái)框架并沒(méi)有什么優(yōu)勢(shì)：那你仍然必須把二進(jìn)制代碼推給最終用戶設(shè)備并且為他們提供支持。
對(duì)于所謂的“混合應(yīng)用”（由web瀏覽器控件托管的原生庫(kù)包含的響應(yīng)式web應(yīng)用）來(lái)說(shuō)，最后一點(diǎn)也是如此。應(yīng)用啟動(dòng)后首先創(chuàng)建web控件，然后控件從服務(wù)器加載標(biāo)記?；旌蠎?yīng)用相對(duì)于單純HTML5應(yīng)用的優(yōu)勢(shì)包括對(duì)應(yīng)用生命周期有更多的控制，在通知方面有更好的用戶體驗(yàn)，并且可以使用漂亮的原生效果，以及web瀏覽器仍然很難再造的控件。而劣勢(shì)在于：你仍然需要懂設(shè)備原生語(yǔ)言，會(huì)創(chuàng)建和維護(hù)打包應(yīng)用的開(kāi)發(fā)者，但大部分或者全部的復(fù)雜用戶功能都可以用網(wǎng)頁(yè)來(lái)實(shí)現(xiàn)。
應(yīng)該選哪一個(gè)？
考慮到這些選擇，為什么不效仿GDS的做法，禁止原生app呢？無(wú)論是從金錢(qián)還是趨勢(shì)上都有若干合理的商業(yè)理由，而決策因素大部分都?xì)w結(jié)為下面這兩點(diǎn)：
你需要多少不同的版本？
以及用戶體驗(yàn)的觸覺(jué)和視覺(jué)屬性有多重要？
如果所有用戶都處在公共的設(shè)備平臺(tái)和OS的話，原生開(kāi)發(fā)的成本是會(huì)降低的，這僅僅是因?yàn)樯鲜鎏岬降臇|西——工程師，工具和過(guò)程需要更少了。這一點(diǎn)甚至在Android平臺(tái)更普遍，因?yàn)槠洳渴鹉Ｊ奖萯OS更加開(kāi)放，或者Windows Phone也是，因?yàn)槿绻枰脑捘憧梢該碛凶约旱姆职l(fā)管道。
（圖片來(lái)源于網(wǎng)絡(luò)）
而在客戶端體驗(yàn)方面，不難看到許多仍然繼續(xù)專(zhuān)注于原生開(kāi)發(fā)的組織正在把許多的品牌資本投入到出色的用戶體驗(yàn)上。做聊天應(yīng)用、新聞流、視頻流媒體、游戲等許多價(jià)值取決于客戶端觀感的應(yīng)用的公司也有強(qiáng)烈的動(dòng)機(jī)投入這一領(lǐng)域。
而企業(yè)側(cè)應(yīng)用（LOB）的情況也許有所不同，對(duì)于它們來(lái)說(shuō)，安全、信息準(zhǔn)確度以及可用性是更重要的考慮。一些組織會(huì)發(fā)現(xiàn)自己兩頭都要兼顧，對(duì)于內(nèi)部LOB應(yīng)用以及廣大的客戶群來(lái)說(shuō)，他們都預(yù)期有復(fù)雜平滑的用戶體驗(yàn)來(lái)滿足自己。
對(duì)于我們其他人來(lái)說(shuō)，混合與響應(yīng)式web應(yīng)用成為默認(rèn)選擇的趨勢(shì)似乎還在繼續(xù)。導(dǎo)致web比1990年代的胖客戶端更有吸引力的經(jīng)濟(jì)問(wèn)題，同樣在企業(yè)支持可在差別各異的異構(gòu)設(shè)備上運(yùn)行的原生app時(shí)出現(xiàn)，這些力量會(huì)繼續(xù)引導(dǎo)組織朝著更容易創(chuàng)建和部署移動(dòng)應(yīng)用的工具轉(zhuǎn)變。
開(kāi)發(fā)原生app可能會(huì)非常值得，如果你的品牌是靠抓住用戶眼球來(lái)競(jìng)爭(zhēng)的話，但是一般的企業(yè)LOB應(yīng)用不會(huì)從選擇原生而不是響應(yīng)式web或者混合應(yīng)用模型上看到很大的投資回報(bào)。
