html5webapp源碼

Ⅰ HTML5定稿了，為什麼原生App世界將被顛覆

一、 HTML5的誕生
自W3C於1999年發布HTML4後，Web世界快速發展，一片繁榮。人們一度認為HTML標准不需要升級了。一些致力於發展Web App的公司另行成立了WHATWG組織，直到2007年，W3C從WHATWG接手相關工作，重新開始發展HTML5。
HTML5的發展史，有用戶的需求在推動，有技術開發者的需求在推動，更有巨大的商業利益在推動。
在互聯網的早期，對用戶而言，能打開瀏覽器接入到互聯網世界就是一個神奇的事情，但互聯網發展到2005年前後，開始出現下一個變化，就是寬頻互聯。
隨著寬頻的普及和電腦性能的增強，人們不再滿足於單純的通過互聯網看新聞、收發郵件，消耗更高帶寬的娛樂產品開始出現，就是流視頻和網頁游戲。其實視頻和游戲是古老的需求，在互聯網不普及的時候，需求的滿足方式是離線傳輸的VCD和游戲光碟;後來互聯網逐漸普及，人們更改了使用方式，通過下載軟體+本地媒體播放器來看視頻，下載體積較大的端遊玩游戲。
但是對消費者體驗更好的新方式還是出現並顛覆了以前的一切，那就是流媒體和網頁游戲。Youtube等公司把握住潮流飛速崛起，各種頁游公司也如雨後春筍。
但是HTML標准沒有把握住產業的變化及時演進，瀏覽器產品也未升級，這塊新需求被瀏覽器插件滿足了，那就是Flash。這個部署在億萬瀏覽器里的商業插件儼然成為事實標准。2005年Adobe巨資收購Macromedia，把Flash收歸旗下，緊接著大幅推廣FLV流媒體和action script語言，很明顯這樁收購可以列為IT並購的經典案例，FLV流媒體和Flash游戲風靡互聯網，Adobe在新的產業升級中攫取了大量的利潤。
除了Flash這個商業產品成為了事實標准，W3C還面臨一個尷尬，就是另一個私有擴展協議的製造者—IE。IE當時在桌面瀏覽器佔有壟斷地位，並且擴展了大量的IE Only語法，開發者完全不知道這些語言是誰定義的。整個web世界，就被兩家公司微軟+Adobe綁架了。
很多IT巨頭都坐不住了，尤其是蘋果和Google。PC操作系統的世界難有突破，Web瀏覽器被蘋果寄予厚望，而且第一代iPhone只支持網頁，那時還沒有Appstore，Safari是喬布斯非常看重的產品;新貴Google雖然大量贊助Mozilla，但並未對IE的地位產生實質影響，收購了YouTube後發現底層被Adobe控制，也是非常難過，而且Google每年給IE的搜索框和Adoble FLV繳納的費用真不是小數目。
既然大家都是W3C的主席單位，好吧，我們重新開始做HTML5吧。
是的，HTML5其實就是這么誕生的。那是2007年，IE和Flash由盛轉衰的轉折點。
二、 HTML5第一階段： Web 增強與破壟斷
自HTML5誕生以來，一共經歷了兩個階段，分別是Web增強和移動互聯網。我們先從Web 增強說起。
web體驗的豐富增強主要表現在：1. webapp，比如gmail;2. 流媒體;3. 游戲。我們就這3個方面來講HTML5做了什麼。
1. webApp
HTML5新增了離線存儲、更豐富的表單(比如Input type=date)、js線程、socket王樂、標准擴展embed、以及很多css3新語法…
2. 流媒體
HTML5新增了audio、video
3. 游戲
HTML5新增了canvas、webgl
當然還有Google努力在HTML5中推進Header和Section等標簽，以利於搜索引擎分析，這些不多述。
HTML5補充流媒體和游戲能力後，加上蘋果強勢拒絕在iOS上引入Flash，成功的遏制了Flash的發展，然後就該遏制IE私有語法了。
在HTML5標準的升級過程中，蘋果和Google同時也看到了瀏覽器市場重新洗牌的機會，他們一方面參與HTML5的規范，一邊在瀏覽器產品上發力。Apple首先開始大力發展Safari，建立WebKit開源項目，Mac、iOS、Windows多平台齊發力;Google起初是贊助Mozilla開發Firefox，後來自己開發了v8引擎，合並WebKit，於2008年正式推出Chrome。「IE的私有規范+Flash不是標准，我們才是標准」這樣的口號在新一代瀏覽器大戰中打響，IE瞬間成為千夫所指的壟斷代表，甚至成了阻礙Web發展的罪人(當時IE6已數年未更新，並且絲毫不懼Firefox的發展)。
偏偏微軟此時也出了暈招，推出了一系列即不完整支持規范又互相不兼容的IE7、8、9、10，徹底失去了開發者的心。
Adobe的Flash被遏制，與Web霸主的位子擦肩而過;IE的私有標准被遏制，並且造成IE市場份額不停下滑，直到IE最新的移動版本反過來開始支持WebKit私有語法，真是令人唏噓。不知道HTML6是不是該打倒WebKit壟斷了。
三、 HTML5第二階段： 移動互聯網
隨著Chrome和Safari的高歌猛進，以及IE+Flash的衰落，HTML5告一段落，進入了下一個時代——移動互聯網。HTML5的跨平台優勢在移動互聯網時代被進一步凸顯。HTML5是唯一一個通吃PC、Mac、iPhone、iPad、Android、Windows Phone等主流平台的跨平台語言。Java和Flash都曾夢想這個位置，但夢斷於iOS。此時人們紛紛開始研究基於HTML5開發跨平台手機應用。很多人當時認為，原生應用只是過渡，就像當年從C/S結構轉變為B/S結構一樣。而且學習Objective-C和Java很費勁，我既然會網頁開發，為何不試試HTML5。
W3C此時成立了Device API工作組，為HTML5擴展了Camera、GPS等手機特有的API，然而麻煩的是，移動互聯網初期的迭代太快了，手機OS在不停的擴展硬體API，陀螺儀、距離感應器、氣壓計。。。每年手機OS都有大版本更新。而W3C作為一個數百家會員單位共同決策的組織，從標准草案的提出到達成一致是非常復雜的過程，跟不上移動互聯網初期的快速迭代。
PhoneGap的出現，給開發者打開了一扇窗。很多人期待PhoneGap不停擴展API，來補充瀏覽器的不足。Adobe看到PhoneGap彷彿看到了重振江湖地位的希望，但在Adobe收購PhoneGap後，又發現這個東西可商用性不足，而且開源使得Adobe無法像Flash那樣獲取商業利益，於是就把PhoneGap捐給了Apache，改名為Cordova。
因為各種原因，Cordova的定位最終沒有成為瀏覽器的強化，而走向了混合式開發。基於當時的背景，他們認為原生是不可替代的，「原生+HTML5」的混合模式更有意義。所以現在Cordova的使用模型是「原生工程師+HTML5工程師」一起協作完成App。
這時Facebook加入了W3C，牽頭成立了Mobile Web工作組。Facebook是混Web圈的，並且在手機OS上沒有自己的領地，他不喜歡被蘋果和Google掌控的原生應用生態系統。Mobile Web這個工作組的重要目標就是讓HTML5開發的網頁應用達到原生應用的體驗。然而，事與願違，它不努力也就算了，結果是努力了卻失敗了。2012年，Facebook放棄了HTML5的新聞充斥了全世界的IT媒體，HTML5瞬間被打入冷宮。
Facebook為何放棄HTML5?核心是當時基於HTML5真的做不出好的移動App。對比Twritter等競爭對手的原生App，Facebook的HTML5版本實在無法讓用戶滿意。比如Push功能，到現在HTML5的推送和原生的推送體驗差距依然巨大，更不用說HTML5應用的頁面切換白屏、下拉刷新/側滑菜單不流暢等眾多問題。看著原生工程師輕松實現搖一搖、二維碼、語音輸入、分享到朋友圈等功能，更是讓HTML5工程師感覺自己站錯了隊。
即使Facebook不喜歡被控制，也不能拿被用戶拋棄來冒險。而且Facebook並沒有掌握關鍵點—手機瀏覽器內核。如果瀏覽器不跟上，徒然定一堆標准草案落不了地。
而瀏覽器在手機上的表現是什麼呢?先看Google，Chrome性能雖高，但Android上的瀏覽器卻並非Chrome，而是WebKit改出來的一個蹩腳的Android瀏覽器;再看蘋果，iOS上不允許其他瀏覽器引擎上架App Store，而且其他使用Safari引擎的應用也無法調用蘋果自己的JavaScript加速引擎Nitro。結果是蘋果和Google不但不在瀏覽器上積極實現HTML5關於移動App所需的規范，反而對HTML5做出種種限制。
不管是當時硬體能力不足，還是手機OS廠商的故意限制，總之結果就是：在移動互聯網的初期，一定是原生應用生態系統的天下，iOS和Android首先自己的地盤穩固後，產業才會向下個階段升級。
Facebook也好，PhoneGap也好，想在移動互聯網初期就分一杯羹是分不到的，但堅持下來，機會往往會出現。
四、 HTML5這回真的來了
終於，在2014年10月底，W3C宣布HTML5正式定稿。這個時間，不晚不早，硬體性能更強、手機OS迭代速度下降。
隨著HTML5標準定稿，一切紛爭將告一段落，現在，屬於HTML5的時代到來了。
有人說，游標準定稿沒用啊，配套起來了嗎?HTML5做的應用究竟能否匹敵原生App?答案是，HTML5不但可以匹敵原生App，甚至它天然的很多特性超越了原生App。
我們先談談HTML5原來不如原生應用的地方，業內俗稱HTML5有「性工能」障礙。即HTML5性能不如原生、開發工具不如原生、能力調用不如原生。

這幾個問題導致開發者無法使用HTML5做出與原生一樣的App。然而，不管是硬體升級還是OS廠商策略變化，以及相關軟體技術的成熟，已解決了HTML5的「性工能」障礙。
1. 硬體升級
2011年，iPhone 4s的CPU是A5，現在iPhone 6是A8，按蘋果的歷次發布會的說法，速度共提升了7.5倍。這3年間7.5倍的速度提升，抹平了太多HTML5的性能問題。
2. 蘋果、Google的策略變化
Google在2013年底發布的Android 4.4，內置的Webview不再是蹩腳的Android WebKit瀏覽器，而是Chromium，性能大幅提升。從最新的Android5.0開始，Webview可以通過Google Play Store實時更新，和Chrome的升級保持一致，用戶就可以不刷機享受到最新的瀏覽器引擎;再看Apple方面，2012年iPhone 5發布後，HTML5在iOS上的表現已令人滿意，Safari獨家的JavaScript加速引擎Nitro不再那麼重要，不過在iOS 8發布後，蘋果還是很識趣地取消了三方程序調用Nitro的限制，現在任意瀏覽器或應用調用iOS的UIWebview都可以利用Nitro加速，這樣在前端使用JS做大型運算也成為可能。兩大手機操作系統霸主和瀏覽器巨頭的態度發生了變化，使得HTML5在手機上的發展不再受限，而且這個變化不可逆只能繼續向前，這種變化勢必會產生深遠的影響。
3. 軟體技術的成熟
PhoneGap的發展雖然放緩了，但其他產品技術卻成熟了。2014年的iWeb大會上，眾多廠商的產品提供了面向開發者免費或開源的HTML5性工能障礙的解決方案。
(註：編者作為從業人員，也會在分析各種方案時提到我們公司的方案，但編者會客觀不誇張的陳述方案，而且該方案是純免費的，沒有商業銷售嫌疑。)
DCloud公司在iWeb大會上發布了系統的HTML5「性工能缺失」的解決方案，包括：
a) 性能：提升HTML5性能的手機端引擎，讓側滑菜單、下拉刷新等動態交互卡頓的問題得以解決;
b) 工具：HTML5開發IDE產品HBuilder, 超快的編程利器;
c) 能力：把40萬原生API封裝成JavaScript對象，以解決HTML5能力不足問題的Native.js技術;
d) 最接近原生體驗的高性能框架：MUI框架，體積只有幾十K，載入、運行遠快於一般框架。
基於該方案開發的HTML5應用完全可以達到原生App的功能和體驗。

使用HBuilder開發HTML5應用
英特爾公司發布了Crosswalk引擎，可以讓Android 4.0-4.3的手機上的應用打包Chromium引擎而不是Android WebKit。畢竟目前市場上存在大量Android 4.0-4.3的手機，同時統一的webview也避免了兼容性的煩惱。
在專業方向上很多公司也做出了不錯的成績。觸控的Cocos2d-html5、Egret runtime和Ludei CocoonJS強化了Canvas的表現，讓HTML5游戲體驗更好;UC、獵豹等手機瀏覽器都強化了音視頻播放的表現。
不管是硬體升級、軟體成熟，還是操作系統廠商策略變化，都在強力推動HTML5的爆發。
不過要注意，我說的HTML5爆發，不是指手機瀏覽器會替代桌面成為應用入口。有人說HTML5不好，因為用戶討厭打開瀏覽器輸入URL的過程。我想說這種想法是對HTML5的片面理解。HTML5!=傳統瀏覽器，雖然編程語言還是HTML、Javascript、CSS，但發行方式絕不是傳統網站那麼簡單。HTML5應用的入口，反而很少是啟動瀏覽器輸入URL，它可以是存在於手機桌面的圖標、也可以來自超級App(如微信朋友圈)、以及搜索引擎、應用市場、廣告聯盟。。。到處都是它的入口。它的入口，比原生App更多。
五、 原生App的顛覆
HTML5的「性工能」障礙得到解決，可以接近原生App的效果，所以它就可以替代原生App嗎?很多人認為，即使HTML5會發展的比現在好，也將是與原生App各佔一部分市場的格局，要求不高的長尾應用會使用HTML5，而主流應用仍是原生App的天下。
但我認為這樣的想法很危險，就像Apple成立前，HP的高層告訴沃茲：誰會在家裡擺一台電腦呢?未來HTML5肯定會顛覆原生App。「性工能」障礙的消除，只是HTML5的劣勢被削弱，但劣勢被消除後，它的優勢就會大放異彩，HTML5的優勢是什麼?我們分別就開發者和最終用戶來看。
■HTML5對開發者的7大優勢
● 跨平台：
在多屏年代，開發者的痛苦指數非常高，人人都期盼HTML5能扮演救星。多套代碼、不同技術工種、業務邏輯同步，這是折磨人的過程。有點類似個人電腦早期世界，那個時候的每家電腦都有自己的操作系統和編程語言，開發者疲於做不同版本，其實DOS的盛行也很大程度是因為開發者實在沒精力給其他電腦寫程序。跨平台技術在早期大多因為性能問題夭折，但中後期硬體能力增強後又會占據主流，因為跨平台確實是剛需。
●快速迭代：
移動互聯網是一個快魚吃慢魚的時代，誰對用戶的需求滿足的更快，誰的試錯成本更低，誰就擁有巨大的優勢。互聯網產品大多免費、且有網路效應，後入者搶奪用戶的難度非常大。使用原生開發，從招聘、開發、上線各個環節的效率都慢一倍以上，而且參與的人越多，溝通效率往往拖慢不止一倍。
●持續交付：
很多人有這樣的體會，一個原生應用上線Appstore，突然有一個大bug，只好連夜加班修復，然後靜靜等待2周或更長時間的Apple審核，這2個星期被用戶的塗抹淹死，市場上一片差評，用戶大量流失。等新應用被審核上線了，用戶已經卸載了。但是，HTML5沒有這些問題，你可以實時更新，有問題立即響應。
●大幅下降成本：
創業者融資並不容易，如何花錢更高效非常重要。如果你使用原生開發的App和競爭對手使用HTML5開發的App沒什麼區別，但你的開發成本高出一倍，我相信沒有投資人會喜歡給你投錢。
●開源生態系統發達：
HTML5前端是開放的正反饋循環生態系統，大量的開源庫可以使用，開發應用變得更輕松、更敏捷，當然這也體現在了快速迭代和成本下降上。不過更重要的是，這種開放的正反饋循環生態系統未來的生命力是比原生生態系統更強勁的。
●開放的數據交換：
HTML是以page為單元開放代碼的，它無需專門開發SDK，只要不混淆，就能與其他應用交互數據。開發者可以讓手機搜索引擎很容易檢索到自己的數據， 也更容易通過跨應用協作來滿足最終用戶需求。
●更容易推廣、更容易爆發：
導流入口多：HTML5應用導流非常容易，超級App(如微信朋友圈)、搜索引擎、應用市場、瀏覽器，到處都是HTML5的流量入口。而原生App的流量入口只有應用市場。聰明的HTML5開發者當然會玩轉各種流量入口從而取得更強的優勢。
流量大：前段時間微信朋友圈風靡一時《神經貓》，這個游戲如果放到Appstore，絕對沒有那麼多流量，超級App帶來的流量，遠大於原生應用市場。假如微信允許游戲在桌面創建快捷方式、假如游戲後續升級解決持續娛樂問題，未來不可想像。
導流效率高：除了入口多、流量大，導流效率高也不可忽視，誰都知道：頁游和端游打同樣的廣告，廣告變用戶的轉化率，頁游遠遠高於端游。
可精準導流到二級頁：我們都知道搜索引擎可以直接進入到
■HTML5對最終用戶的3大優勢
●大幅降低使用門檻
為什麼流媒體會替代下載視頻成為主流?為什麼頁游會如此火爆?只因用戶太「懶」。讓用戶更方便的滿足需求，有時效果好於更多的滿足需求。
用戶眼睛看到一個興趣點，點擊後，就應該立即開始滿足用戶需求。比如流媒體可以立即看，頁游可以立即玩。而目前的原生應用市場，用戶需要這樣操作：選一個應用、等待下載、確認許可權、等待安裝，然後點擊打開。這樣糟糕的體驗遲早要被顛覆。
不管是App、游戲還是音視頻，未來都將即點即用。誰先滿足用戶這個需求，誰就制勝。
●實時更新、差量更新的優秀體驗
HTML5應用可以繞開應用市場的限制進行自主實時更新，用戶可以快速享受新服務。
而且這種更新完全可以是差量更新，比如某個HTML頁面或某個js文件有問題，只更新這個幾k的小文件就可以了，這比原生應用的更新體驗好太多。
●跨應用的使用體驗
目前手機應用切換是以桌面或任務管理器為中心的，但事實上這些中心很影響效率和體驗。用戶想出差三亞，先打開去哪App訂票，然後切回桌面，再找到並打開天氣App，搜索輸入三亞，再切到桌面，找到並打開航旅縱橫App，輸入航班號值機，哦對了，航班號多少來著，再切到桌面，找到並打開去哪App看航班號，最後找到並打開租車App，輸入租車地點，然後再切回桌面。。。
在原生應用體系下，用戶只能這樣。但在HTML5體系下，他不需要切回桌面，他可以在App間方便的直接跳來跳去，而不是使用一個一個孤島App;他更不用重復錄入數據，應用間可以方便的互相傳遞數據。
這種模式需要一點想像力，但未來遲早會來。
分析至此，我們可以明顯的看出，不管是站在最終用戶角度、還是站在開發者角度，HTML5必將取代原生應用當前的位置。並由此引發一系列顛覆。

Ⅱ 如何用html5構建移動端的webapp

H5e教育html5開發為您解答：
移動web在當今的發展速度是一日千里，作為移動領域的門外漢，在這段時間的接觸後，發現前端開發這一塊做一個小小的總結。
1.四大瀏覽器內核
1.Trident (IE瀏覽器) :因為在早期IE佔有大量的市場份額，所以以前有很多網頁是根據這個Trident的標准來編寫的，但是實際上這個內核對真正的網頁標准支持不是很好，同時存在許多安全Bug。
2.Gecko:( FireFox )優點就是功能強大、豐富，可以支持很多復雜網頁效果和瀏覽器擴展介面，缺點是消耗很多的資源，比如內存。
3.Webkit: ( Chrome/ Safari / UC )優點就是Webkit擁有清晰的源碼結構、極快的渲染速度，缺點是對網頁代碼的兼容性較低，會使一些編寫不標準的網頁無法正確顯示。
4.Presto: ( 歐朋 ) Presto內核被稱為公認的瀏覽網頁速度最快的內核，同時也是處理JS腳本最兼容的內核，能在Windows、Mac及Linux操作系統下完美運行。
移動端開發主要對象是手持設備，其中絕大部分是IOS和Android系統，基於Webkit內核，可使用Chrome瀏覽器調試即可。
2.手機瀏覽器
瀏覽器已經逐漸從傳統桌面轉向手機端，競爭也越來越激烈。目前國內市場主流的手機瀏覽器：UC、網路、歐朋、QQ、海豚、safari、Chrome，這些瀏覽器都是基於webkit內核的，兼容性方面不存在問題，同時對html5和css3的支持很好，所以，大膽地應用html5和css3技術吧。
在開始編寫webapp時，前端工程師使用HTML5，而放棄HTML4，因為HTML5可以實現一些HTML4中無法實現的豐富的WEB應用程序 的體驗，可以減少開發者很多的工作量，當然了你決定使用HTML5前，一定要對此非常熟悉，要知道HTML5的新標簽的作用。比如定義一塊內容或文章區域 可使用section標簽，定義導航條或選項卡可以直接使用nav標簽等等。
3.終端解析度
手機解析度比PC解析度要龐雜得多，各種解析度有木有？大小差距那麼大有木有？這在一定程度上給頁面製作帶來了不小的麻煩。所以針對這樣的因素，必須有充分的考慮。考慮到瀏覽器自適應，需要設計和製作完成各種不同的方法。
1) 市場上主流手機生產商的產品解析度。經過調研發現，目前主流的手機解析度為：480*800像素、320*480像素，而1280*720像素（720P）會是接下來的趨勢。這些都是很粗略的統計，要有精確的數據需要花費不少的精力，那是數據分析人員的工作。
2) 項目目標群所持設備的解析度。項目目標群即用戶，用戶擁有什麼樣的手機解析度，從一定程度上來說比第一點來得更加重要，它決定著項目開發的方向。
4.響應式web開發
在編寫CSS時，我不建議前端工程師把容器（不管是外層容器還是內層）的寬度定死。為達到適配各種手持設備，我建議前端工程師使用自適應布局模式（支付 寶 採用了自適應布局模式），因為這樣做可以讓你的頁面在ipad、itouch、ipod、iphone、android、web safarik、chrome都能夠正常的顯示，你無需再次考慮設備的解析度。
響應式web開發不是一項開創性的技術變革，簡單地說，響應式web設計採用了媒體查詢、流式布局、液態圖片三項技術，把它們組合在一起來製作頁面，使得頁面不只在傳統桌面，在平板電腦和手機上，各種不同的解析度都能夠完美顯示。而要做到這點，我覺得不難，請繼續往下：
1) 准備工作：
a) 插件安裝：window resize。您可以通過下載安裝谷歌瀏覽器插件，安裝成功後，當您調整瀏覽器窗口時，在瀏覽器右下角會有灰度提示當前窗口和類似於手機視圖的大小提示。
b) 編輯器安裝：Hbulder或Webstorm
c) 弄清視圖和屏幕的區別。視圖是瀏覽器的內容顯示區域，屏幕是設備的物理顯示區域。比如視圖寬度我們一般用width表示，而屏幕寬度是用device-width來表示。相信做過手機頁面的童鞋都經常見過這段代碼：
<meta name="viewport" content="width=device-width,initial-scale=1.0">
其中width=device-width就是說把頁面寬度設置成和屏幕寬度一樣。
d) 響應式設計創意網站收集 。這里有很多響應式Web設計的網站，供您參考和學習。
2) 征途ING：
e) 響應式web設計之媒體查詢：
為了減少http請求，我想在css樣式表裡進行媒體查詢會是個不錯的選擇，而不是在頁面head部分使用link進行載入。樣式表裡的媒體查詢格式為：
@media screen and (max-width:960px){}
大括弧內部書寫樣式。該語句相當於判斷語句，有兩個條件，一個是視口寬度最大不超過960px，screen代表顯示屏，這兩個條件都具備了，就調用大括弧內的樣式。
f) 響應式web設計之流式布局：
流式布局以百分比進行布局。最重要是時刻關注元素的父級層，所有的元素都是以父級層為基準。流式布局的應用是為了和媒體查詢完美地結合，形成平滑的布局變 化跳轉效果。一般而言，media里的樣式多以width、padding、margin、font-size、line-height這些為主。
g) 響應式web設計之液態圖片：
要實現液態圖片，只需加入如下代碼：img{max-width:100%;}
web移動頭部書寫

1、首先我們來看看webkit內核中的一些私有的meta標簽，這些meta標簽在開發webapp時起到非常重要的作用
<meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0;" name="viewport" />
這個meta標簽表示：強制讓文檔的寬度與設備的寬度保持1:1，並且文檔最大的寬度比例是1.0，且不允許用戶點擊屏幕放大瀏覽；
<meta content="yes」 name=" apple-mobile-web-app-capable" />
meta標簽是iphone設備中的safari私有meta標簽，它表示：允許全屏模式瀏覽；
<meta content="black" name=" apple-mobile-web-app-status-bar-style" />
meta標簽也是iphone的私有標簽，它指定的iphone中safari頂端的狀態條的樣式；
<meta content="telephone=no" name="format-detection" />
meta標簽表示：告訴設備忽略將頁面中的數字識別為電話號碼