應(yīng)用程序開發(fā)的兩種流行方法是本機(jī)應(yīng)用程序和混合應(yīng)用程序

在過去的幾年中，我們周圍的世界經(jīng)歷了一次強(qiáng)大的范式轉(zhuǎn)換，其中，我們?nèi)粘Ｉ畹膸缀趺總€(gè)方面都圍繞以應(yīng)用程序?yàn)橹行牡纳鷳B(tài)系統(tǒng)旋轉(zhuǎn)或與之相關(guān)。早上報(bào)警?有一個(gè)應(yīng)用程序可以通過量身定制的機(jī)制喚醒您。早餐?火起來的食譜書，鞭打東西。出租車上班嗎?幾下水龍頭，幾分鐘之內(nèi)就會(huì)出現(xiàn)在路邊。這種轉(zhuǎn)變所產(chǎn)生的回旋效應(yīng)使人們期望應(yīng)用程序能夠完成每項(xiàng)任務(wù)(無論多么艱辛)，每天都被初創(chuàng)企業(yè)和開發(fā)人員迅速填補(bǔ)。隨著市場以驚人的速度發(fā)展，開發(fā)人員被迫在兩種方法之間進(jìn)行選擇，每種方法都有自己的優(yōu)缺點(diǎn)。

什么是本機(jī)和混合應(yīng)用程序?

應(yīng)用程序開發(fā)的兩種流行方法是本機(jī)應(yīng)用程序和混合應(yīng)用程序。您問這些術(shù)語是什么意思?讓我們快速看一下這兩種范例。

本機(jī)應(yīng)用程序是使用平臺(tái)的既有方法專門為其創(chuàng)建的。他們尊重平臺(tái)的設(shè)計(jì)模式，使用平臺(tái)的主流編程語言(例如，Android的Java)，可以完全訪問可用的API，并提供比混合應(yīng)用程序更好的性能。

混合應(yīng)用是使用HTML和Javascript等網(wǎng)絡(luò)技術(shù)創(chuàng)建的，然后打包在一起并包裝在本機(jī)瀏覽器中。設(shè)想此模型的一種簡單方法是，設(shè)想一個(gè)網(wǎng)站，該網(wǎng)站在應(yīng)用程序的WebView中本地運(yùn)行?；旌蠎?yīng)用程序不具有完整的API訪問權(quán)限，提供的設(shè)計(jì)體驗(yàn)不盡人意，并且使用Web包裝程序會(huì)對性能產(chǎn)生重大影響。

代碼可重用性

眾多應(yīng)用程序是混合的主要原因是該模型在代碼可重用性方面擁有巨大的優(yōu)勢?；旌蠎?yīng)用程序產(chǎn)生了“一次構(gòu)建，多次部署”的理念，該理念允許開發(fā)人員使用Web語言對應(yīng)用程序進(jìn)行一次編碼，然后將其包裝在瀏覽器中即可在各種平臺(tái)上進(jìn)行部署。據(jù)說這可以節(jié)省大量的初始版本和更新麻煩，但是這種方法的分散性常常被忽略–并非所有開箱即用的瀏覽器都支持較新的Web標(biāo)準(zhǔn)，并且開發(fā)人員經(jīng)常最終編寫一個(gè)大量的兼容性代碼和替代CSS規(guī)則，針對每個(gè)平臺(tái)的瀏覽器并滿足其要求，從而降低了混合應(yīng)用程序攜帶的“ 100%可移植”標(biāo)簽的重要性。

用戶界面

社會(huì)的

近年來，設(shè)計(jì)已起著舉足輕重的作用，每個(gè)平臺(tái)都可以創(chuàng)建和完善自己已經(jīng)適應(yīng)用戶的視覺樣式，并且期望該平臺(tái)上的所有應(yīng)用程序都能使用它，原生應(yīng)用程序可以輕松地使用平臺(tái)的設(shè)計(jì)SDK所提供的組件，而混合應(yīng)用需要花費(fèi)大量精力才能實(shí)現(xiàn)用戶熟悉的界面。盡管如此，混合應(yīng)用程序只能在“一次構(gòu)建，多次部署”的理念下一次滿足一個(gè)平臺(tái)的熟悉程度，而更占主導(dǎo)地位的平臺(tái)的可視語言通常在應(yīng)用程序中占據(jù)中心位置，從而使其他平臺(tái)的用戶陷入混亂混亂，因?yàn)樗麄冇恿嗽S多外星人的布局。

設(shè)備訪問

Android-4.55.0-L-Lollipop

每個(gè)平臺(tái)都提供自己的API集，開發(fā)人員可以使用這些API，從布局設(shè)計(jì)和動(dòng)畫集到電池優(yōu)化和安全訪問。本機(jī)應(yīng)用程序通?？梢酝ㄟ^簡單的方法調(diào)用來無縫利用這些API，但是混合應(yīng)用程序在此方面的差距很大。盡管諸如Cordova和Ionic之類的某些框架提供了訪問基本API(如藍(lán)牙，WiFi等)的插件，但覆蓋范圍還遠(yuǎn)遠(yuǎn)不夠完整，并導(dǎo)致缺乏優(yōu)化，眾多折衷和功能受限的問題。

性能

htc-one-m9基準(zhǔn)

在過去的幾年中，硬件功能已經(jīng)走了很長一段路，與軟件行業(yè)的需求保持同步，并確保用戶獲得優(yōu)化和流暢的設(shè)備體驗(yàn)。盡管當(dāng)今大多數(shù)旗艦店采用的CPU，GPU和RAM配置令人印象深刻，但應(yīng)用程序并沒有在這種架構(gòu)級(jí)別上運(yùn)行，而是封裝在眾多軟件層中以提供高級(jí)開發(fā)體驗(yàn)。應(yīng)用程序和硬件之間的每個(gè)包裝器都會(huì)顯著影響設(shè)備的性能和效率，而本機(jī)應(yīng)用程序在層次結(jié)構(gòu)中的特定級(jí)別運(yùn)行，而混合應(yīng)用程序則需要圍繞HTML代碼的另一個(gè)包裝器。因此，性能影響雖然并不總是很明顯，但肯定會(huì)存在，并且在執(zhí)行更多苛刻的操作時(shí)可能會(huì)成為明顯的缺點(diǎn)。

成本

代碼可重用性的必然結(jié)果是，如果不是在本地應(yīng)用程序上選擇混合應(yīng)用程序，則成本降低是主要原因，即使不是主要原因。在一個(gè)平臺(tái)上構(gòu)建然后在多個(gè)平臺(tái)上部署的能力可以降低成本，因?yàn)槊總€(gè)平臺(tái)都可以聘請獨(dú)立的團(tuán)隊(duì)，由一個(gè)多產(chǎn)的HTML團(tuán)隊(duì)創(chuàng)建該應(yīng)用，然后執(zhí)行將其包裝在每個(gè)平臺(tái)的瀏覽器包裝中的簡單任務(wù)，甚至使用諸如Phonegap Build之類的自動(dòng)化工具來進(jìn)行最后一英里的平臺(tái)分配。即便如此，瀏覽器碎片化仍然是一個(gè)不容易解決的嚴(yán)重問題，其修復(fù)程序更多地是不需要JavaScript中的try-catch塊和大量替代CSS規(guī)則。要順利實(shí)現(xiàn)這一目標(biāo)非常困難，并且需要一支技術(shù)嫻熟的Web開發(fā)團(tuán)隊(duì)，

用戶體驗(yàn)

關(guān)注用戶，其他所有操作都將隨之而來。這個(gè)口號(hào)是由Google設(shè)計(jì)團(tuán)隊(duì)提出并提出的，在這個(gè)時(shí)代，用戶的期望，參與度和滿意度可以證明是應(yīng)用與其替代品或競爭對手之間的關(guān)鍵區(qū)別，這一說法是正確的。正確完成后，本機(jī)應(yīng)用程序可以提供最完美的用戶體驗(yàn)，在設(shè)計(jì)時(shí)會(huì)考慮該平臺(tái)的用戶群，并隨后無縫使用用戶習(xí)慣的模式，樣式和組件來制作。另一方面，混合應(yīng)用程序提供的用戶體驗(yàn)卻遠(yuǎn)遠(yuǎn)不能令人滿意，僅滿足特定平臺(tái)的需求，無法在觸摸反饋，布局響應(yīng)等方面滿足用戶期望。盡管許多開發(fā)人員繼續(xù)忽略UX的重要性，

我該選擇哪一個(gè)?

在這兩種方法之間進(jìn)行探索的目的不是要找到并確定兩者中的更好方法，而是要突出選擇一個(gè)或另一個(gè)缺點(diǎn)的各種優(yōu)勢。每種方法在某些方面都有優(yōu)勢，而在其他方面則有所欠缺，最終由開發(fā)人員做出選擇。問自己一些簡單的問題即可簡化此選擇，例如：

我需要立即為多個(gè)平臺(tái)發(fā)布我的應(yīng)用程序，還是可以從一個(gè)平臺(tái)開始然后擴(kuò)展?

犧牲成本和縮短上市時(shí)間值得犧牲用戶界面和應(yīng)用程序的用戶體驗(yàn)嗎?

我是否需要訪問某些無法通過混合方法獲得的特定API?

我的應(yīng)用程序在性能方面是否繁重，混合方法是否可以滿足這種需求?

不要忘記看一些大型企業(yè)并從他們的錯(cuò)誤中學(xué)習(xí)。例如，F(xiàn)acebook和LinkedIn在過去都使用混合應(yīng)用程序，這導(dǎo)致用戶極度不滿，導(dǎo)致兩家公司走本機(jī)路線并分別為每個(gè)平臺(tái)構(gòu)建。只有您知道什么是最適合您的解決方案!