本篇文章給大家談?wù)刪5混合app開(kāi)發(fā)，以及app h5框架對(duì)應(yīng)的知識(shí)點(diǎn)，希望對(duì)各位有所幫助，不要忘了收藏本站喔。

說(shuō)說(shuō)H5和native app

開(kāi)發(fā)者選項(xiàng)里打開(kāi)顯示布局邊界，如果能看到各種邊框則為native app，如果只為一大塊則為H5 app。

native app使用原生系統(tǒng)內(nèi)核（Android linux、iOS等等），相當(dāng)于直接在系統(tǒng)上操作，更加穩(wěn)定、快速，可以使用非常非常多的API,用那句流行的話來(lái)說(shuō)是“不知道多到哪里去了”，因此開(kāi)發(fā)出來(lái)的功能逼格更高。而H5 APP是先調(diào)用系統(tǒng)的瀏覽器內(nèi)核，相當(dāng)于是在網(wǎng)頁(yè)中進(jìn)行操作，較原生APP穩(wěn)定性稍差、速度較慢，同時(shí)在一些老Android版本上運(yùn)行非常慢。但是H5最大的優(yōu)點(diǎn)是可以跨平臺(tái)，同時(shí)開(kāi)發(fā)容易、效率高、方便調(diào)試。native的話需要用Java和Swift語(yǔ)言各自寫(xiě)，甚至還要為WP寫(xiě)??，而H5只要開(kāi)發(fā)一套。

就目前來(lái)說(shuō),Native的運(yùn)行性能和UI控件的渲染性能都要比H5有明顯優(yōu)勢(shì),而H5優(yōu)勢(shì)在于快速開(kāi)發(fā)迭代。長(zhǎng)遠(yuǎn)來(lái)看,H5的流行得要看H5是否能更進(jìn)一步的貼近Native的性能和效率。未來(lái)比較多的方案可能是H5+Native混合開(kāi)發(fā)模式。（微信應(yīng)用號(hào)）

native APP不會(huì)垮，H5 app傳播快準(zhǔn)狠，時(shí)效性高，但是持續(xù)性短。

H5適合做表示層，如果常見(jiàn)界面經(jīng)常換，或者要做跨平臺(tái)的軟件，又要很快上線的，H5還是很合適的。調(diào)用硬件什么的- -|||好像可以建議采用H5+native混合開(kāi)發(fā)模式。

h5做app和原生app有什么區(qū)別？

1.H5的性能很差，一般經(jīng)常改的地方可以用H5，比如論壇，咨詢之類的，而且限制也是很大，很多效果是沒(méi)辦法做到的。GUI框架的WebView普遍是這樣的。如果一個(gè)APP全部由H5來(lái)做(不太可能，送審很可能被拒)，那么會(huì)顯得非?？ā?/p>

2.用iOS SDK，如果實(shí)現(xiàn)熱更新是比較麻煩的。對(duì)于論壇，咨詢這種模塊，動(dòng)不動(dòng)就改版，做起來(lái)比較頭疼，用H5就很合適了。尤其在APP跨安卓和iOS的時(shí)候，這類模塊如果直接用H5，那么就很容易共用。

H5網(wǎng)頁(yè)App開(kāi)發(fā)和純?cè)腁pp的差距主要聚集在以下幾個(gè)方面：

1、動(dòng)畫(huà)

動(dòng)畫(huà)有很多種，比如側(cè)邊欄菜單的滑入滑出、元素的響應(yīng)動(dòng)畫(huà)、頁(yè)面切換之間的過(guò)場(chǎng)等等，在H5之下的眾多實(shí)現(xiàn)方法都沒(méi)有辦法達(dá)到純?cè)男阅?。一般這些的話有幾種不同的選擇：css3動(dòng)畫(huà)、javascript動(dòng)畫(huà)、原生動(dòng)畫(huà)。

css3動(dòng)畫(huà)非常的消耗性能，如果某一個(gè)元素用到css3動(dòng)畫(huà)可能還看不出來(lái)，但大面積或過(guò)場(chǎng)使用css3動(dòng)畫(huà)會(huì)讓app低端手機(jī)體驗(yàn)非常差。最好的選擇一般是通過(guò)框架調(diào)用底層的動(dòng)畫(huà)，但不管怎么樣等于在原來(lái)的代碼上包上了一層，性能還是不可避免的受到影響。

比如在一個(gè)新頁(yè)面的載入上，如果調(diào)用底層動(dòng)畫(huà)要考慮的問(wèn)題有兩個(gè)，一個(gè)是本身資源頁(yè)面的渲染問(wèn)題，另一個(gè)是遠(yuǎn)程數(shù)據(jù)的獲取。即便是這些動(dòng)畫(huà)能夠很快的響應(yīng)，但大量的css頁(yè)面會(huì)導(dǎo)致渲染卡頓，滑入時(shí)可能會(huì)有白屏/機(jī)器卡頓的現(xiàn)象。為了解決這些性能問(wèn)題又必須要用到預(yù)加載或模擬動(dòng)畫(huà)。即便是這樣，滑入滑出的動(dòng)畫(huà)在低端的安卓機(jī)器上還是有很多問(wèn)題，如果獲取服務(wù)端數(shù)據(jù)處理的方式不合適，卡頓白屏的現(xiàn)象會(huì)更嚴(yán)重。具體看下面的數(shù)據(jù)獲取方式。

2、獲取服務(wù)端數(shù)據(jù)

首先要接受的是，這里的數(shù)據(jù)獲取都是在資源頁(yè)面上異步完成的，因?yàn)橹挥羞@樣才能讓這些資源頁(yè)面完成預(yù)加載或者渲染。但是異步拿到的數(shù)據(jù)在填入頁(yè)面中時(shí)可能會(huì)涉及DOM操作，眾所周知，DOM操作非常消耗性能，如果頁(yè)面小還好，頁(yè)面稍大數(shù)據(jù)稍微復(fù)雜一點(diǎn)，頻繁的DOM操作會(huì)導(dǎo)致明顯的閃白。而且最重要的一點(diǎn)是，如果頁(yè)面加載進(jìn)來(lái)之后數(shù)據(jù)更新的速度太慢，也會(huì)讓頁(yè)面模板等待很長(zhǎng)時(shí)間，對(duì)用戶體驗(yàn)又不友好，總不能每次打開(kāi)都像瀏覽器一樣等待刷新是吧

這個(gè)問(wèn)題如果沒(méi)有得到解決，H5開(kāi)發(fā)是很難承擔(dān)大規(guī)模數(shù)據(jù)的頁(yè)面，在它們之中頻繁切換更是難上加難，那么肯定有人也會(huì)想到用MVVM的方式，其實(shí)我也寫(xiě)過(guò)一些基于MVVM的H5app開(kāi)發(fā)，相對(duì)來(lái)說(shuō)它們獲取數(shù)據(jù)和更新數(shù)據(jù)的方式更敏捷更科學(xué)，但寫(xiě)的過(guò)程中又要注意很多H5獨(dú)有的問(wèn)題，這些問(wèn)題在下面的頁(yè)面切換里來(lái)講。

3、頁(yè)面切換

上面我們看到了幾種不錯(cuò)的實(shí)現(xiàn)方式，比如預(yù)加載和模擬動(dòng)畫(huà)，甚至有批量的預(yù)加載，批量的截圖模擬動(dòng)畫(huà)等等，雖然看起來(lái)很友好解決了不少問(wèn)題，但事實(shí)上如果頁(yè)面足夠多就會(huì)引發(fā)另一個(gè)問(wèn)題——頁(yè)面的生存周期。

試想一下，如果引導(dǎo)頁(yè)或者主頁(yè)面緩存了5個(gè)子頁(yè)面的資源，在跳轉(zhuǎn)到響應(yīng)的子頁(yè)面時(shí)又會(huì)緩存這些子頁(yè)面的下級(jí)頁(yè)面資源，如此反復(fù)肯定會(huì)占據(jù)大量?jī)?nèi)存使APP的體驗(yàn)下降。那么怎么知道那些頁(yè)面是需要的，最多緩存多少頁(yè)面，什么時(shí)候結(jié)束哪些頁(yè)面的生存周期呢？在我用過(guò)的很多H5APP的框架里都沒(méi)有對(duì)這些問(wèn)題有一個(gè)完美的解答，因此在頁(yè)面較多內(nèi)容較多的app開(kāi)發(fā)中可能會(huì)因這些資源分配的問(wèn)題降低性能。

這時(shí)候我們回過(guò)頭來(lái)再看看MVVM的數(shù)據(jù)加載問(wèn)題，實(shí)際上不管哪個(gè)MVVM框架，寫(xiě)過(guò)的人都知道管理這種新型的前端代碼最重要的問(wèn)題是內(nèi)存的問(wèn)題，你既要保證代碼寫(xiě)的足夠優(yōu)雅沒(méi)有任何內(nèi)存泄露問(wèn)題，也要考慮到在頁(yè)面生存周期結(jié)束時(shí)它們的控制器/頁(yè)面資源是否得到釋放，這對(duì)全局有沒(méi)有什么影響，在多個(gè)請(qǐng)求時(shí)也要合理的分配資源，甚至是復(fù)用這些父級(jí)頁(yè)面?zhèn)鬟^(guò)來(lái)的緩存資源等等。較小的APP可能并不會(huì)有這些問(wèn)題，如果你想用純H5來(lái)開(kāi)發(fā)大型app，這很可能會(huì)浪費(fèi)你很多時(shí)間——而且結(jié)果還不會(huì)讓你滿意。

4、Android/iOS的區(qū)別

很多人都說(shuō)純H5app開(kāi)發(fā)一次編寫(xiě)就能編譯Android/iOS兩種不同的APP，大大降低了成本。實(shí)際上這個(gè)觀點(diǎn)本身就是值得懷疑的，如果你寫(xiě)過(guò)這類APP就能明白我在說(shuō)什么，它們既不省事，又存在很多BUG，調(diào)試時(shí)尤其繁瑣。舉一個(gè)很簡(jiǎn)單的例子，Android和iOS在返回上一頁(yè)的處理方式上就有明顯的區(qū)別，iOS的頂部bar在全屏下怎樣處理，Android機(jī)器出現(xiàn)smart bar怎樣處理頁(yè)面的布局，調(diào)用底層硬件時(shí)怎樣區(qū)分不同的場(chǎng)景等等，你需要寫(xiě)一個(gè)又一個(gè)機(jī)型和系統(tǒng)的判斷，然后分別在Android和iOS下調(diào)試，最后你卻發(fā)現(xiàn)這并沒(méi)有卵用，累的要死卻什么沒(méi)學(xué)到，只有一堆不知道什么時(shí)候會(huì)過(guò)時(shí)的經(jīng)驗(yàn)。

現(xiàn)在做H5混合APP開(kāi)發(fā)的人很多，但是純H5卻很年輕，很多問(wèn)題都沒(méi)有很好的解決，這幾個(gè)是我在做這些APP時(shí)考慮最多的問(wèn)題。最后說(shuō)一個(gè)很少人注意到的H5優(yōu)勢(shì)，大家大談H5APP時(shí)都是快速開(kāi)發(fā)、低成本、多平臺(tái)等等，但我卻覺(jué)得它和很多APP開(kāi)發(fā)方式相比有一個(gè)不同之處——圖文混合的排版。正是這些復(fù)雜多變的CSS樣式消耗了性能，但是它帶來(lái)了排版的多樣性，能夠細(xì)致到每一個(gè)字寬行高和風(fēng)格的像素級(jí)處理，才是H5的優(yōu)異之處。

APP原生開(kāi)發(fā)和H5開(kāi)發(fā)以及APP混合開(kāi)發(fā)三者有什么區(qū)別？

這個(gè)如果詳細(xì)說(shuō)，那就是很復(fù)雜了，但是可以以口語(yǔ)方式簡(jiǎn)單的說(shuō)

APP原生開(kāi)發(fā)：就是安卓版，IOS版，和后臺(tái)，最起碼為3個(gè)人制作，3個(gè)不同的人掌握不同的技術(shù)，也就是說(shuō)，這個(gè)成本最高。

H5開(kāi)發(fā)：就是HTML5的網(wǎng)頁(yè)制作，也可以理解為網(wǎng)頁(yè)制作，然后加個(gè)殼打包，這個(gè)殼和打包對(duì)于外行也是比較模糊的概念，你只需要理解為最簡(jiǎn)單的html5制作就行，這個(gè)沒(méi)有什么技術(shù)含量，也最便宜。一個(gè)人可以搞定。

APP混合開(kāi)發(fā)：這個(gè)是介于原生開(kāi)發(fā)和H5開(kāi)發(fā)之間的，難度也是居中，相對(duì)來(lái)說(shuō)，技術(shù)上由2個(gè)人完成，一個(gè)前臺(tái)一個(gè)后臺(tái)，APP上有H5的制作內(nèi)容，也有原生開(kāi)發(fā)的制作內(nèi)容，所以叫混合開(kāi)發(fā)，或者說(shuō)也有WEB開(kāi)發(fā)的痕跡，這個(gè)是不能一句話說(shuō)清楚的。

從價(jià)格來(lái)說(shuō)這樣排列：最貴原生開(kāi)發(fā)，居中混合開(kāi)發(fā)，最便宜H5開(kāi)發(fā)。

如何辨別app是原生開(kāi)發(fā)的還是h5開(kāi)發(fā)的 或是混合開(kāi)發(fā)

1、看斷網(wǎng)的情況

把手機(jī)的網(wǎng)絡(luò)斷掉。然后點(diǎn)開(kāi)頁(yè)面。然后可以正常顯示的東西就是原生寫(xiě)的。

顯示404或則錯(cuò)誤頁(yè)面的是html頁(yè)面。

2、看布局邊界

可以打開(kāi) 開(kāi)發(fā)者選項(xiàng)中的顯示布局邊界，頁(yè)面元素很多的情況下布局是一整塊的是h5的，布局密密麻麻的是原生控件。頁(yè)面有布局的是原生的否則為h5頁(yè)面。

3、看復(fù)制文章的提示，需要你通過(guò)對(duì)比才能得出結(jié)果。

比如是文章資訊頁(yè)面可以長(zhǎng)按頁(yè)面試試，如果出現(xiàn)文字選擇、粘貼功能的是H5頁(yè)面，否則是native原生的頁(yè)面。

有些原生APP開(kāi)放了復(fù)制粘貼功能或者關(guān)閉了。而H5的css屏蔽了復(fù)制選擇功能等等情況。需要通過(guò)對(duì)目標(biāo)測(cè)試APP進(jìn)行對(duì)比才可知。

這個(gè)在支付寶APP、螞蟻聚寶都是可以判斷的。

4、看加載的方式

如果在打開(kāi)新頁(yè)面導(dǎo)航欄下面有一條加載的線的話，這個(gè)頁(yè)面就是H5頁(yè)面，如果沒(méi)有就是原生的。

H5 手機(jī) App 開(kāi)發(fā)入門(mén)：技術(shù)篇

手機(jī) App 的技術(shù)?？梢苑殖扇?/p>

原生技術(shù)棧指的是，只能用于特定手機(jī)平臺(tái)的開(kāi)發(fā)技術(shù)。比如，安卓平臺(tái)的 Java 技術(shù)棧，iOS 平臺(tái)的 Object-C 技術(shù)?；?Swift 技術(shù)棧。

混合技術(shù)棧指的是開(kāi)發(fā)混合 App 的技術(shù)，也就是把 Web 網(wǎng)頁(yè)放到特定的容器中，然后再打包成各個(gè)平臺(tái)的原生 App。所以，混合技術(shù)棧其實(shí)是 Web 技術(shù)棧 + 容器技術(shù)棧，典型代表是 PhoneGap、Cordova、Ionic 等框架。

跨平臺(tái)技術(shù)棧指的是使用一種技術(shù)，同時(shí)支持多個(gè)手機(jī)平臺(tái)。它與混合技術(shù)棧的區(qū)別是，不使用 Web 技術(shù)，即它的頁(yè)面不是 HTML5 頁(yè)面，而是使用自己的語(yǔ)法寫(xiě)的 UI 層，然后編譯成各平臺(tái)的原生 App。

這個(gè)技術(shù)棧就是純粹的容器技術(shù)棧，React Native、Xamarin、Flutter 都屬于這一類。學(xué)習(xí)時(shí)，除了學(xué)習(xí)容器的 API Bridge，還要學(xué)習(xí)容器提供的 UI 層，即怎么寫(xiě)頁(yè)面

總結(jié)：H5 開(kāi)發(fā)主要用在混合技術(shù)棧。但是，跨平臺(tái)技術(shù)棧的某些容器也會(huì)用到（比如 React Native），因?yàn)樗鼈兊?UI 層借鑒了 Web 模型。

另外，混合技術(shù)棧和跨平臺(tái)技術(shù)棧的基礎(chǔ)，都是原生技術(shù)棧，因?yàn)樽罱K都要編譯成原生App。所以，不管使用哪一種技術(shù)棧，多多少少要了解一些各平臺(tái)的原生技術(shù)。

不管什么技術(shù)，最終在 App 里面顯示網(wǎng)頁(yè)，一定需要一個(gè)網(wǎng)頁(yè)引擎，這樣才能解析網(wǎng)頁(yè)。通常情況下，App 內(nèi)部會(huì)使用 WebView 控件作為網(wǎng)頁(yè)引擎。這是系統(tǒng)自帶的控件，專門(mén)用來(lái)顯示網(wǎng)頁(yè)。應(yīng)用程序的界面，只要放上 WebView，就好像內(nèi)嵌了瀏覽器窗口，可以顯示網(wǎng)頁(yè)。不同的 App 技術(shù)棧要顯示網(wǎng)頁(yè)，區(qū)別僅僅在于怎么處理 WebView 這個(gè)原生控件。

不同系統(tǒng)的 WebView 控件名稱不一樣，安卓系統(tǒng)就叫 WebView，iOS 系統(tǒng)有較老的 UIWebView，也有較新的 WKWebView，作用都是一樣的，差異在于功能的強(qiáng)弱。

關(guān)于h5混合app開(kāi)發(fā)和app h5框架的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。