像我手里的這個(gè)項(xiàng)目，把靜態(tài)頁(yè)面邏輯，都寫完，把頁(yè)面鏈接給app，然后app開(kāi)發(fā)人員會(huì)給你個(gè)他們特有的方法，你在你的頁(yè)面中判斷是否有這個(gè)方法，有就走app的方法，沒(méi)有就走自己的方法
創(chuàng)新互聯(lián)專注于桂東網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供桂東營(yíng)銷型網(wǎng)站建設(shè)，桂東網(wǎng)站制作、桂東網(wǎng)頁(yè)設(shè)計(jì)、桂東網(wǎng)站官網(wǎng)定制、微信小程序開(kāi)發(fā)服務(wù)，打造桂東網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供桂東網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。
HTML5為什么如此受歡迎？主要因?yàn)樗旧淼膬?yōu)勢(shì)。HTML5的主要優(yōu)勢(shì)如下：
1、基于HTML5強(qiáng)大的兼容性。因?yàn)镠TML5提供了前所未有的數(shù)據(jù)與應(yīng)用接入開(kāi)放接口，使外部應(yīng)用可以直接與瀏覽器內(nèi)部的數(shù)據(jù)直接相連，例如視頻影音可直接與microphones及攝像頭相聯(lián)，就因?yàn)檫@種強(qiáng)大的兼容性，使得在當(dāng)下開(kāi)發(fā)界是如此的火，同樣也是因?yàn)檫@強(qiáng)大的兼容性，使得手機(jī)應(yīng)用軟件，app更適合，也更方便。所以更適合手機(jī)app軟件開(kāi)發(fā)，正好補(bǔ)充了手機(jī)小巧的不足。
2、HTML5開(kāi)發(fā)支持的手機(jī)系統(tǒng)有android、ios。
3、HTML5其突出的特點(diǎn)就是強(qiáng)化了web頁(yè)的表現(xiàn)性,追加了本地?cái)?shù)據(jù)庫(kù)，可以用作離線應(yīng)用的開(kāi)發(fā)，離線應(yīng)用就是把需要的資源先緩存到本地，下次再查看時(shí)無(wú)需聯(lián)網(wǎng)。
4、HTML5開(kāi)發(fā)能提供更快、更簡(jiǎn)便的服務(wù)，代碼可高度重用，服務(wù)發(fā)布方便。
5、動(dòng)畫、游戲動(dòng)態(tài)效果，地理定位等很多app應(yīng)用正在崛起，而HTML5技術(shù)的強(qiáng)大優(yōu)勢(shì)就是這種讓我們驚嘆的效果。而未來(lái)采用HTML5開(kāi)發(fā)app的，將會(huì)大量減少代碼量，應(yīng)用軟件也會(huì)得到更高的用戶體驗(yàn)，更好的視覺(jué)效果。
html5現(xiàn)在還占優(yōu)勢(shì)的。
1、開(kāi)發(fā)方式
（1）代碼結(jié)構(gòu)：
React
Native更為合理，組件化程度高
（2）UI布局：Web布局靈活度
React
Native
Native
（3）UI截面圖：React
Native使用的是原生組件，
（4）路由／Navigation：React
Native
Native更勝一籌
（5）第三方生態(tài)鏈：Native
modules
+
js
modules
=
React
Native
modules
2、性能
體驗(yàn)
（1）內(nèi)存：Native最少；因?yàn)镽eact
Native含有框架，所以相對(duì)較高，但是后期平穩(wěn)后會(huì)優(yōu)于Native。
（2）CPU：React
Native居中。
（3）動(dòng)畫：React
Native動(dòng)畫需求基本滿足。
（4）安裝包體積：React
Native框架打包后，811KB。相比熱更新，可以忽略和考慮資源規(guī)劃。
（5）Big
ListView
（6）真機(jī)體驗(yàn)：Native
=
React
Native
H5/Hybrid
如果C++引擎和JavaScript做同樣的任務(wù)，C++很有可能領(lǐng)先于JavaScript。但這里仍提出了一個(gè)很有趣的課題：使用“快”的語(yǔ)言（比如C++）并不能保證比“慢”的語(yǔ)言（JavaScript）有更好的性能。
這周，我對(duì)電腦進(jìn)行了系統(tǒng)升級(jí)，采用Windows?8操作系統(tǒng)，全新的nVidia?GetForce?GTX?660顯卡。一切就緒后，我進(jìn)行了性能測(cè)試，瀏覽器是Chrome?Canary?25，結(jié)果表明?Construct2的WebGL渲染器明顯快于Native的C++?DirectX?9——基于Construct?Classic引擎開(kāi)發(fā)。
WebGL的測(cè)試結(jié)果是141911個(gè)sprite，而Construct?Classic為109280。顯然，WebGL比Native快了將近30%。
系統(tǒng)環(huán)境配置：Windows 8 RTM（64位）系統(tǒng)、Intel Core i5-2500 @ 3.3GHz (quad core)、8GB RAM、nVidia GeForce GTX 660 (driver v306.97)。然而，此結(jié)果并不能在Windows 7上復(fù)制，使用AMD Radeon芯片驅(qū)動(dòng)（沒(méi)有在Windows 8上試過(guò)）。WebGL在Firefox 19上卻比Native慢很多，而IE根本就不支持WebGL。
這里也有些測(cè)試結(jié)果表明，WebGL是沒(méi)有這個(gè)能力的，所以，它總是呈現(xiàn)Canvas 2D渲染。這次在Chrome Canary 25上的得分是3821，而之前的結(jié)果竟比它快37倍。
為什么會(huì)出現(xiàn)如此好的結(jié)果？據(jù)理解，它可能把WebGL的安全檢查交由硬件處理，WebGL的操作規(guī)范要求瀏覽器必須在使用時(shí)正確檢查所有的緩沖區(qū)，而不是在訪問(wèn)前或后。使用長(zhǎng)緩沖區(qū)來(lái)渲染大量的sprites，為了保證安全使用，CPU采用排水作業(yè)的方式檢查緩沖區(qū)。然而，一些GPU廠商可能會(huì)在GPU的硬件上檢查緩沖區(qū)?；蛟S，這僅僅適用于一些特定的OS，在驅(qū)動(dòng)和硬件設(shè)備支持的情況下，否則，CPU仍然會(huì)做這些檢查。這或許就是快的原因吧！
這兒還有另外一個(gè)重要原因：WebGL渲染器的設(shè)計(jì)比Construct Classic系列的C++ DirectX 9更加高效。當(dāng)使用C++編寫時(shí)，它的速度很容易降下來(lái)，雖然C++速度很快，但這并不表明編寫任何C++代碼都可以運(yùn)行很快。當(dāng)把引擎移到JavaScript上時(shí)，在大多數(shù)的基準(zhǔn)測(cè)試中，它要比C++的慢好幾倍。這驅(qū)使我們更加密切地關(guān)注性能并且采取更加明智的整體策略。當(dāng)對(duì)每個(gè)精靈進(jìn)行渲染時(shí)，經(jīng)典的Native引擎會(huì)計(jì)算頂點(diǎn)位置（對(duì)象角落）。在使用collisions engine中已經(jīng)把所識(shí)別的位置信息進(jìn)行了計(jì)算和儲(chǔ)藏。這就阻止了Construct 2重新計(jì)算——它們只需復(fù)制collisions engine中的計(jì)算。所以JavaScript只需做很少的事情。這可能會(huì)稍微縮小彼此間的差距。
這就解釋了為什么只有在特定的環(huán)境下，JavaScript引擎才能領(lǐng)先于不那么高效地C++引擎。如果C++引擎和JavaScript做同樣的事情，C++很有可能領(lǐng)先于JavaScript。但這里卻提出了一個(gè)很有趣的課題：使用“快”的語(yǔ)言（比如C++）并不能保證比“慢”的語(yǔ)言（JavaScript）有更好的性能。這也表明會(huì)有一些更加靈巧的JavaScript/WebGL渲染引擎會(huì)打敗Native引擎。這就預(yù)示著未來(lái)移動(dòng)端的HTML5游戲也能像Native引擎一樣，達(dá)到同樣的基準(zhǔn)測(cè)試結(jié)果（或者更多！）。
希望這個(gè)結(jié)論不是什么技術(shù)錯(cuò)誤或者故障。另一方面，如果該結(jié)果是真實(shí)的，那么它會(huì)讓人欣喜若狂的。大多數(shù)時(shí)候，人們會(huì)抱怨把本地游戲移植到HTML5上是多么的慢，那么它很快就會(huì)結(jié)束！
判斷android應(yīng)用是否是基于html5還是native控件開(kāi)發(fā)主要有兩種方式：
1.根據(jù)android的native控件開(kāi)發(fā)的界面，是由一個(gè)個(gè)的控件組合而成，而html是包裹在一個(gè)webview控件里面的，所以可以通過(guò)查看布局邊界，如果界面上是由很多的框組成的就是native控件開(kāi)發(fā)的，反之為html5開(kāi)發(fā)。在設(shè)置中找到開(kāi)發(fā)人員工具，然后找到顯示布局邊界，選中，這個(gè)時(shí)候會(huì)發(fā)現(xiàn)屏幕中到處都是框框。
2.根據(jù)html5需要保持網(wǎng)絡(luò)連接，斷開(kāi)網(wǎng)絡(luò)之后會(huì)顯示錯(cuò)誤的網(wǎng)頁(yè)信息來(lái)判斷。手機(jī)的網(wǎng)絡(luò)斷掉。然后點(diǎn)開(kāi)android程序頁(yè)面。然后可以正常顯示的東西就是原生寫的。顯示404或則錯(cuò)誤頁(yè)面的是html頁(yè)面
近段時(shí)間，android應(yīng)用的開(kāi)發(fā)趨向于使用html5，因?yàn)槠涓赂?jiǎn)單，容易維護(hù)。
烽火星空很高興為您解答：
以下譯自Michael Mahemoff的一篇文章，詳細(xì)分析了HTML5能否取代Android和ioS應(yīng)用程序。
介紹
移動(dòng)應(yīng)用程序(App)和HTML5都是目前最火的技術(shù)，二者之間也有不少重疊之處。在移動(dòng)設(shè)備瀏覽器里運(yùn)行的html5的web頁(yè)面，也可以重新打包成不同平臺(tái)上運(yùn)行的app。目前很多瀏覽器都有很好的跨平臺(tái)支持，（譯注：firefox居然可以在android中使用和windows下同樣的瀏覽器內(nèi)核），HTML5的web方案，對(duì)開(kāi)發(fā)者來(lái)說(shuō)更為方便。完成一次，即可多平臺(tái)使用。但這確實(shí)可行嗎？仍然有許多必要原因，使得開(kāi)發(fā)者選擇了app開(kāi)發(fā)。很明顯，很多人已經(jīng)在這么做了。本文將詳細(xì)分析兩種方案的優(yōu)劣。
功能豐富
正方：App里可以開(kāi)發(fā)出更豐富的功能
我們把移動(dòng)功能分成兩類。程序本身和程序與系統(tǒng)的結(jié)合。比如android里，加入widget圖標(biāo)或者通知提醒之類的。App對(duì)這兩者都沒(méi)問(wèn)題。不用多說(shuō)，這是肯定的。
反方：APP是挺強(qiáng)，但Web也正在迎頭跟進(jìn)
確實(shí)很多原生app實(shí)現(xiàn)的功能是HTML5望塵莫及的。不管你的web做的再牛，如果停留在一個(gè)沒(méi)有攝像頭支持的沙盒中，很多場(chǎng)合還是玩不轉(zhuǎn)。幸運(yùn)的是，現(xiàn)在沒(méi)有這樣的沙盒限制了。如果你需要你的web照相片，可以做一個(gè)負(fù)責(zé)照像的app，再把你的web打包進(jìn)這個(gè)應(yīng)用里面。開(kāi)源的PhoneGap框架是這么干的。這樣widget，手機(jī)提醒也都沒(méi)問(wèn)題了。
但這種混合開(kāi)發(fā)的問(wèn)題在于，增加了復(fù)雜性，而且不象傳統(tǒng)web那樣可以直接在瀏覽器里運(yùn)行。這個(gè)問(wèn)題短時(shí)間內(nèi)恐怕沒(méi)轍。好在現(xiàn)在網(wǎng)絡(luò)標(biāo)準(zhǔn)在不斷的高速擴(kuò)充，先進(jìn)的瀏覽器也在一直跟進(jìn)。Android 3.1已經(jīng)支持camera了。ioS瀏覽器也支持WebSocket和設(shè)備方向檢測(cè)了
。
總得來(lái)說(shuō)，移動(dòng)設(shè)備在發(fā)展，而web也同樣在快速變化。桌面瀏覽器本身，有5家主要瀏覽器開(kāi)發(fā)商在改進(jìn)現(xiàn)有標(biāo)準(zhǔn)，豐富新的功能。所以原生App在快速前進(jìn)，同時(shí)，web也在縮小差距。
運(yùn)行效率
正方：原生APP速度更快
原生APP沒(méi)有瓶頸，而且可以直接調(diào)用gpu加速、使用多線程。
反方：現(xiàn)如今Web已經(jīng)快多了，而且多數(shù)應(yīng)用也用不著那么快。
這說(shuō)法有點(diǎn)落伍了。Chrome發(fā)布之時(shí)帶來(lái)的Javascript V8，給Web速度帶來(lái)的飛躍。而現(xiàn)在，計(jì)算速度變得更快了：
圖片處理引擎已經(jīng)使用web加速?，F(xiàn)在硬件加速也已經(jīng)開(kāi)始應(yīng)用了?？纯从蒙嫌布铀俚腸anvas（圖表來(lái)源）
要開(kāi)發(fā)3D游戲的就不用抬杠了，但對(duì)于平而來(lái)說(shuō)，新聞、郵件、時(shí)間管理、社交網(wǎng)絡(luò)，這些用Web都?jí)蛴昧恕Ｔ囋嘢teve Souders的手機(jī)性能測(cè)試工具。 另外，越來(lái)越多的框架結(jié)合WebGL，可以發(fā)揮OpenGL的優(yōu)勢(shì)了。比如Impactjs，幫助開(kāi)發(fā)js游戲。
開(kāi)發(fā)感受
正方：原生APP好寫
原生APP使用強(qiáng)壯的程序語(yǔ)言（Java, Objective C, C++）。適合寫復(fù)雜程序，經(jīng)過(guò)歷史驗(yàn)證，api豐富。在桌面環(huán)境可以方便的用模擬器測(cè)試。而Web程序的runtimes和亂七八糟的各路瀏覽器讓人頭大。
反方：一般都是Web更簡(jiǎn)單，特別是需要兼容不同設(shè)備的時(shí)候。
Web最初的功能只限于文檔展示，而不是程序應(yīng)用，貌似最近倆星期才有了js。但有了js后，web的世界馬上就不一樣了。更何況web不只是靜止的，HTML5，CSS3，EcmaScript Harmony（誰(shuí)知道這是什么？）都給開(kāi)發(fā)者極大幫助。你是喜歡C++，java, JavaScript，那你的個(gè)人愛(ài)好，也是基于你已經(jīng)攢下的代碼。但是現(xiàn)在沒(méi)人能否認(rèn)JavaScript也和前者站在同一擂臺(tái)上。
瀏覽器/runtime的互不兼容（碎片），反過(guò)來(lái)看做APP也是一樣。用Java寫了Android app，然后又要面對(duì)ioS的Objective C。如果能寫一個(gè)程序，馬上能在Android和ioS上運(yùn)行，多省事啊。這咱還沒(méi)提WebOS, BlackBerry，Windows mobile呢。當(dāng)然，這是理論上的。要是想讓程序在每個(gè)平臺(tái)都跑得很漂亮，得做不少調(diào)試和妥協(xié)。這對(duì)很多原生APP也是一樣的。不同OS版本，不同的設(shè)備。。。
所謂的Web碎片化，一直都是如此。但好消息是現(xiàn)在已經(jīng)有很多不錯(cuò)的解決辦法。Modernizr庫(kù)，用得好的話，可以幫你兼容一大批主流設(shè)備，不管是啥系統(tǒng)，哪個(gè)牌子的?？纯次覀?011年的Google io演示。
用戶體驗(yàn)
正方：原生APP更切合原有平臺(tái)
操作感受的定義之一，就是用戶希望在你的程序里，用與系統(tǒng)連貫統(tǒng)一的方式來(lái)操作。不同的平臺(tái)，都有一些約定俗成的習(xí)慣。比如長(zhǎng)按按鈕會(huì)有啥反應(yīng)。你不能指望用一套統(tǒng)一的HTML5 App去滿足所有用戶。
此外，整個(gè)平臺(tái)的操作感受都由用平臺(tái)自有的軟件庫(kù)協(xié)調(diào)。直接調(diào)用平臺(tái)工具包就能直接免費(fèi)獲得完整支持。
反方：我們Web有自己的傳統(tǒng)，你要特想做原有平臺(tái)那種感覺(jué)的web，也一樣能做出來(lái)
前面說(shuō)了，Web開(kāi)發(fā)的方式，是先做一個(gè)大體適合所有平臺(tái)的版本，然后再針對(duì)不同平臺(tái)不斷改進(jìn)。當(dāng)這些改進(jìn)主要是針對(duì)功能時(shí)，你可以選擇幾個(gè)你最關(guān)心的平臺(tái)做優(yōu)化。類似于瀏覽器檢測(cè)。技術(shù)論壇里的悲催技術(shù)員們，經(jīng)常抱怨這事。太多不同的瀏覽器版本了。不過(guò)如果你優(yōu)先關(guān)注兩三種主流平臺(tái)，是值得為他們多花點(diǎn)時(shí)間做做優(yōu)化。
web本來(lái)就有自己的操作感受。我們也可以說(shuō)，不同的默認(rèn)瀏覽器以及運(yùn)行環(huán)境造就了獨(dú)特的"Web感受"。從更廣的角度看，這本身就是一種用戶公認(rèn)的方式。此外，還有很多成功的案例并不遵循移動(dòng)設(shè)備的原生操作習(xí)慣，人家也成功了。想想你最喜歡的手機(jī)游戲的界面？很多更傳統(tǒng)的app也是一樣，比如Twitter客戶端。
傳播途徑
正方：原生應(yīng)用更容易接觸客戶
象Google Play和Apple Store這樣的app發(fā)布機(jī)制這幾年勢(shì)不可擋，推動(dòng)了整個(gè)移動(dòng)行業(yè)。每個(gè)程序員都能在市場(chǎng)里發(fā)布自己的應(yīng)用。用戶都擠在市場(chǎng)里瀏覽，搜索，接受推薦。不僅如此，只要你的程序夠好，現(xiàn)有用戶的打分會(huì)幫助你說(shuō)服更多新的客戶。
反方：其實(shí)web才容易接觸到客戶
通過(guò)web找到內(nèi)容，這是經(jīng)過(guò)論證的可靠途徑。利用URL，每一項(xiàng)發(fā)布的內(nèi)容都有一個(gè)獨(dú)立的地址，包括在網(wǎng)站上發(fā)布的應(yīng)用程序。搜索引擎幫助發(fā)現(xiàn)內(nèi)容，其他網(wǎng)站提供鏈接，還有一些類似應(yīng)用市場(chǎng)的分類網(wǎng)站。用戶還可以郵件、短信、在社交網(wǎng)站分享你的鏈接。你的應(yīng)用鏈接可以直接在不同設(shè)備上直接打開(kāi)。
web上還沒(méi)有一個(gè)統(tǒng)一的評(píng)分系統(tǒng)，但這個(gè)情況也在發(fā)生改變。往下看。。。
收費(fèi)
正方：App收費(fèi)：應(yīng)天意，順民生
“六歲孩子午飯時(shí)做app，$3一個(gè)，賣出幾百萬(wàn)”。最近常聽(tīng)看到這樣的新聞。各種大小廠商也跟著蜂擁而至，等著圈錢。應(yīng)用商點(diǎn)幫開(kāi)發(fā)商直接收費(fèi)。最簡(jiǎn)單的辦法，一次性收費(fèi)。也有在app里再另行收費(fèi)或者做訂閱收費(fèi)的，這幫助開(kāi)發(fā)商贏得長(zhǎng)期穩(wěn)定的回報(bào)。
此外，傳統(tǒng)網(wǎng)站的廣告、贊助，在app里也同樣適用。
反方：網(wǎng)站賺錢，從來(lái)都不是問(wèn)題。現(xiàn)在機(jī)會(huì)還越來(lái)越多
Web能成為現(xiàn)在社會(huì)的推動(dòng)力，有能力用多種方式取得回報(bào)，這是基本條件。雖然使用付費(fèi)并不普遍。但SaaS的模式已經(jīng)相當(dāng)普及了。成功案例包括Google Apps，37signals的系列產(chǎn)品，各類郵件的收費(fèi)版。另外，直接收費(fèi)并不是web應(yīng)用的唯一模式。廣告、會(huì)員鏈接，贊助，其他產(chǎn)品服務(wù)的交叉推廣都是可選的模式。
看著能在應(yīng)用市場(chǎng)里直接賺錢而眼紅的Web開(kāi)發(fā)商們，你們不能直接把你的URL發(fā)進(jìn)市場(chǎng)，但是做一個(gè)瀏覽web的app的殼子來(lái)連到自己的web上怎么樣？現(xiàn)在市場(chǎng)中如果不說(shuō)數(shù)以千計(jì)，至少也有上百的app這么干了。有些包裝的好的，你甚至察覺(jué)不到他是一個(gè)web程序。
以后應(yīng)用市場(chǎng)會(huì)直接支持web程序嗎？這個(gè)現(xiàn)在還不好說(shuō)，但去年Google已經(jīng)建了個(gè)Chrome web store。雖然還只能從桌面電腦放問(wèn)，但這已經(jīng)挑起了瀏覽器廠商的興趣?，F(xiàn)在還只是個(gè)初步概念，但看起來(lái)挺有前途。
結(jié)論
現(xiàn)在還看不出完勝的一方。有些應(yīng)用適合做app，有一些適合用html5。目前的情況，原生APP肯定是一個(gè)很重要的選擇。上面提到的混合式開(kāi)發(fā)，可能是一個(gè)不錯(cuò)的妥協(xié)方案。能用web的時(shí)候用app調(diào)用web。web實(shí)現(xiàn)不了的功能用app開(kāi)發(fā)。
如果你選擇web方式，要在web標(biāo)準(zhǔn)和不斷的改進(jìn)上用心。web技術(shù)本身的優(yōu)點(diǎn)就是能兼容大批不同的操作系統(tǒng)和設(shè)備。消極的看，你也可以這是碎片，但web就是一切通吃。
英文原文：HTML5 VS native: THE mobile APP debate
中文翻譯：unicom-china
本文地址：
重慶分公司
重慶分公司
