㈠ Native App與Web App
Native App開發
即原生APP開發模式，利用iOS、Android開發平台官方提供的開發工具進行APP的開發。
特點：
（1）功能多：可以訪問手機的所有功能，如定位、GPS、攝像頭等。
（2）速度快、性能高、整體用戶體驗好。
（3）離線使用：若App內部涉及到大量的視頻、圖片等信息，在流量有限的情況下，需要用戶將這些文件保存到本地，以供離線使用。並且再次打開時，不需要重新載入，訪問速度快。
（4）App質量及安全性好。
（5）Native App開發非常費時費力，不同的版本需要單獨開發。
Web App開發
Web App開發主要依靠H5框架開發，類似於網頁，而不是單獨的程序。
特點：
（1）在瀏覽器上運行，項目獨立。
（2）單一版本開發，開發周期短、難度小。
（3）Web APP的功能有限，不能調用手機功能。
（4）性能需要進行檢驗，不如原生App。
（5）每次打開都需要重新載入，訪問速度慢，無法離線瀏覽。
（6）技術不成熟，質量及安全性無法得到保障。
㈡ ios怎麼和h5界面實現交互
實現ios怎麼和h5界面實現交互比較常見的方法就是使用OC中自帶的UIWebView類，來實現載入H5網頁界面。
創建webView，遵循代理並實現其方法：
1.--webViewDidStartLoad
在該方法中可以讓「小菊花」即UIActivityIndicatorView開轉
2.--webViewDidFinishLoad
小菊花停止轉動，並從界面中移除
3.--webViewDidFailLoadWithError
做相關操作，列印錯誤原因，重載等
㈢ Hybrid App開發中，web端與native端幾種常見的通信場景
本篇文章，我們主要敘述一下Hybrid App中常見的幾種通訊場景，包括 注冊 、 登錄 、 支付 、 登錄狀態的保持 以及 退出 。由於我在前面的文章中已經有過對web端和native之間通信方式的講解，所以本篇文章主要是以使用為主。如果您還不了解web端和原生端的通信方式，請查看我的這篇文章 《Hybird App中 Android 和 IOS 與網頁之間的通信》 進行學習，了解基礎非常重要。
Register.vue
1、注冊按鈕點擊事件，針對不同的平台使用不同的邏輯。
2、調用android注冊方法。需要在android端注冊 register 方法，並返回是否通過校驗的值（boolean）。
3、調用IOS注冊方法。當然也需要在IOS原生端定義 register 方法，由於IOS中不能直接返回結果給web端，所以需要在web端的 window 對象中掛載一個回調方法 onRegisterCallback ,等IOS端完成處理後，執行該方法。
一定要注意，要在執行 window.webkit.messageHandlers.register.postMessage(userJson) 執行前將 注冊回調方法onRegisterCallback 進行掛載。
4、注冊回調方法
當我們完成了注冊功能，其他的功能其實就是簡單復制的過程了。話不多說，咱們碼上見真情。
Login.vue
1、登錄按鈕點擊事件
3、調用 android 登錄驗證
4、調用 ios 登錄驗證
5、接收登錄驗證結果
當然，在登錄成功後，我們需要將用戶通過 vuex 進行保存，這里就不細講了。同時，在原生端也會將用戶名進行保存。
在原生端啟用webview載入完web端頁面的後回去執行，我們掛載在web端 window 下面的方法 nativeFunctionUserLogin 方法，並將原生端保存的用戶名發送給web端。web端再將用戶保存在vuex中，如此，就實現了登錄狀態的保持。
App.vue
首先看一下支付頁面。
1、支付點擊事件
2、支付方式點擊事件
1、退出登錄按鈕點擊事件
2、調用 android 退出登錄的方法
3、調用 android 退出登錄的方法
4、退出登錄的回調方法
㈣ 如何區別一個 App 是 Native App，Web App 還是 Hybrid app
nativeapp是一個原生程序，一般運行在機器操作系統上，有很強的交互，一般靜態資源都是在本地的。瀏覽使用方便，體驗度高。在實現上要麼使用Objecttive-c和cocoaTouch Framework撰寫IOS程序，要麼選擇java+Android Framework撰寫android應用程序。
hybridapp是一個半原生程序，偽造了一個瀏覽器的apk/ipa原生程序，把地址寫死了，然後裡面運行了一個webapp。裡面是WebView UI 。但是還是運行在機器的操作系統上，交互較弱，資源一般在本地或者網路都可以。瀏覽體驗度次之。
webapp是生存在瀏覽器里的應用，所以只能運行在瀏覽器里，宿主是瀏覽器，不再是操作系統。
㈤ 如何選擇Web APP與Native App原生開發模式的區別，APP開發模式比較
NativeApp開發
Native App開發即我們所稱的傳統APP開發模式（原生APP開發模式），該開發針對IOS、Android等不同的手機操作系統要採用不同的語言和框架進行開發，該模式通常是由「雲伺服器數據+APP應用客戶端」兩部份構成，APP應用所有的UI元素、數據內容、邏輯框架均安裝在手機終端上。
WebApp開發
Web App開發即是一種框架型APP開發模式（HTML5 APP 框架開發模式），該開發具有跨平台的優勢，該模式通常由「HTML5雲網站+APP應用客戶端」兩部份構成，APP應用客戶端只需安裝應用的框架部份，而應用的數據則是每次打開APP的時候，去雲端取數據呈現給手機用戶。
原生APP開發及Web
APP開發模式的區別
Web
APP需開發「html5雲網站」和「APP客戶端」，昆明天度網路公司總結這類型APP應用呈現以下特點：
（1）每次打開APP，都要通過APP框架向雲網站取UI及數據；
（2）手機用戶無法上網則無法訪問APP應用中的數據。
（3）框架型的APP無法調用手機終端的硬體設備（語音、攝像頭、簡訊、GPS、藍牙、重力感應等）
（4）框架型APP的訪問速度受手機終端上網的限制，每次使用均會消耗一定的手機上網流量；
（5）框架型APP應用的安裝包小巧，只包含框架文件，而大量的UI元素、數據內容剛存放在雲端；
（6）APP用戶每次都可以訪問到實時的最新的雲端數據；
（7）APP用戶無須頻繁更新APP應用，與雲端實現的是實時數據交互；
適用企業：電子商務、金融、新聞資訊、企業集團需經常更新內容的APP應用。
Native
App（原生型APP）需要開發「雲伺服器數據中心」和「APP客戶端」，昆明天度網路公司總結這類型的APP應用呈現以下特點：
（1）每次獲取最新的APP功能，需要升級APP應用；
（2）原生型APP應用的安裝包相對較大，包含UI元素、數據內容、邏輯框架；
（3）手機用戶無法上網也可訪問APP應用中以前下載的數據。
（4）原生型的APP可以調用手機終端的硬體設備（語音、攝像頭、簡訊、GPS、藍牙、重力感應等）
（5）APP應用更新新功能，涉及到每次要向各個應用商店進行提交審核。
適用企業：游戲、電子雜志、管理應用、物聯網等無需經常更新程序框架的APP應用。
到底該如何選擇Web
App和Native App開發模式
移動Web無所不在，移動Web是目前唯一的支持各種設備訪問的平台，與桌面Web一樣，移動Web支持各種標準的協議。移動Web也是唯一一個可供開發者發布移動應用的平台，它將各種移動交互與桌面任務有效地連接了起來；而開發Native
App可以充分利用設備的特性，而這一點往往是Web瀏覽器做不到的，所以對一個產品本身而言，Native App是最佳的選擇。下面幾節將討論一下Native
App的一些主要功能。
什麼時候應該選擇Native
App
1.為應用收費
沒有任何地方規定開發者不能對一個移動Web
App收取使用費，但是由於某些原因，人們常常認為不能或是不應該對一個Web App收取費用。由於歷史原因，導致移動設備上付費服務遭遇兩大阻力：
2.付款方式
在移動設備上輸入信用卡號相當麻煩，而且在許多老式設備上也沒有安全保障。一種典型的方式是，如果你需要對你的應用收費，你可以與運營商達成協議，讓運營商代為為你的服務收費。這也意味著，你需要和多個運營商達成合作。這通常是首選的方法，因為許多手機用戶可能根本就沒有信用卡，比如青少年。
另一種方法是將用戶的信用卡信息保存在一個安全的網站上。用戶可以通過登錄到該網站購買應用服務。這個過程不算特別理想，因為這意味著用戶不能直接通過他們的移動設備購買服務了。
3.強制分成
移動運營商是會提成的。App無論是通過運營商還是通過移動設備發布，他們都為應用提供了一套收費機制。這些運營商和移動設備將會提取部分收益，然後將剩餘的部分交給應用開發商，這也意味著，開發人員必須遵守他們的市場規則。適應運營商的市場規則通常是非常困難的，需要投入大量的人力資源。相比而言，移動設備的市場規則則簡單許多，但是也存在不少的困難。
妨礙運營商和移動設備開發商利益的應用以及服務都將受到阻擾。過去，那些不靠運營商和移動設備開發商運作的網站如果收入過於顯眼的話，都逃脫不了被關閉的命運，但是最近，這樣的事情鮮少發生了。
如果你想為你的Native
App收費，那麼你就必須接受這個現實——你必須遵守別人的市場規則，還得放棄部分收益。
4.開發游戲
如果你是想開發一個移動游戲（移動游戲是移動市場上最大的一塊），那麼你需要開發一個Native
App。游戲對資源的佔用很大，並且需要使用許多設備API或平台API。雖然，現在有幾款完全使用Web技術開發的游戲佔有了一定的市場份額，但是和Native
App市場的佔有情況相比，還是微不足道的。游戲用戶對應用的視覺和操作效果要求很高。移動Web雖然提供了一些模擬體驗，但還遠遠不能滿足用戶的需求。
在開發移動游戲時，你需要慎重考慮你的應用需要支持哪些平台。幸運的是，現在有許多工具能夠幫助你將你的游戲推向多個平台，但是完成這些工作，還是需要花費大量的人力和物力。
5.使用定位功能
下一個功能就是定位功能，可以通過GPS或者是信號檢測確定用戶當前的位置信息。以前只能通過Native
App的APIs查看用戶的位置信息，但現在大多數主流移動瀏覽器上都嵌入了W3C Geolocation
API。像iPhone或Android這樣安裝了WebKit的設備，或是配置了Opera或Mozilla瀏覽器的設備，都可以獲取用戶的位置信息。
我相信定位功能會為Web技術帶來許多全新的應用。如果能夠合理利用Web瀏覽器，Web開發商就能使用用戶的位置信息和其他內容開發出更加有趣的應用。雖然這在技術上沒有太大的困難，但卻受到隱私保護條例的限制。我們將Web瀏覽器當做是用戶進入World
Wide
Web的入口。加入定位功能，意味著在網站中引入了一些敏感信息，這有可能導致嚴重的後果。但是位置感知應用中顯示的位置信息必須經過用戶的授權，用戶當然有權禁止應用發布自己的位置信息。
6.使用攝像頭
攝像頭可以為你的應用提供豐富的可能性。以往移動MMS（Multimedia Messaging
Service）被用於處理移動照片。換言之，你拍了一張照片後，需要使用MMS將它傳送給一個伺服器，伺服器對照片做出相應的處理，並將處理完成的結果通知給你。這個過程是非常耗時的，而且相當復雜，也沒有可靠性保障。
通過訪問攝像頭，Native
App開發者能夠簡化拍照的過程。用戶可以直接在客戶端對照片做一些簡單的處理，只有在有需要的時候才將照片上傳給伺服器，而且是通過可靠的HTTP傳輸。W3C正在開發一個訪問攝像頭的API，但現在還沒有將這部分工作正式整合到瀏覽器中。
在許多類型的移動Apps中，攝像頭是非常有用的，比如快拍應用、短片拍攝應用等等，攝像頭可以用來捕捉許多重要的瞬間。不久的將來，我們可以看到——只要通過攝像頭拍攝某個標識，應用程序就能自動完成對標識上的語言轉換工作——這個技術在日本已經開始流行起來了。
7.使用感應器
現在越來越來越多的移動設備上都新增了感應器功能，該裝置可以感知設備的物理速度以及重力，並將感知的數據結果傳送給設備。這個裝置常被用來感應設置是否被翻轉，應用根據接受到的信息自動調節畫面的方向。
感應器可以用來幫助用戶提升與設備交互時的真實感；大多數移動設備都是手持的，應用能夠根據設備的方向調整內容畫面，比如翻轉屏幕，或是檢測物理移動，並能據此猜測用戶所處的環境。舉一個簡單的例子：比如用戶正在走路，那麼感應器能夠檢測到一個輕緩的移動或是速度，這時可以為用戶提供一個大字體的用戶界面，從而使得用戶更容易看清屏幕上的內容。
然而，開發者也不能過分依賴感應器，因為感應器無法區分究竟哪些交互是有意的，而哪些是沒有意義的。每個移動交互都需要通過「傳輸測試」。設計你的交互時必須考慮用戶在一個擁擠的汽車或是火車上的場景。考慮一下如果用戶正身處擁擠的地鐵或是正在駕車時，你的應用能否正確處理用戶搖晃移動設備的動作。通常，大多數開發者都沒有考慮這些因素。確保為每個任務設計一個備用方案以處理特殊場景中的移動交互。
8.訪問文件系統
如果你的應用需要將數據保存在本地，那麼你需要開發一個Native
App。比如你要保存用戶的地址簿、電話或E-mail信息，或是保存從其他設備上獲取的數據。
訪問文件系統常常會涉及到安全和用戶隱私保護的問題。惡意應用程序可能會修改或是刪除你的移動設備上的數據。一個攜帶病毒的應用程序可以利用移動設備上的關系網將病毒擴散到許多其他的手機上，在採用移動應用認證機制以前，這種事情是常常發生的。
另一方面，移動設備正變得越來越私人化，移動設備上保存了大量用戶的個人信息，以及用戶的朋友信息和商業信息。針對這些私人信息開發應用是一個不錯的想法。但是這也存在一定的風險，使用保存在移動設備上的數據可以為用戶提供更加有針對性的服務。
開發者必須謹記，只有在獲得用戶的授權後才能訪問用戶的私人數據。我們看到許多應用在沒有得到用戶授權的情況下使用了大量的用戶私人數據，而被誤認為是垃圾信息或是釣魚應用，即使這些應用原本是在提供一些非常有用的服務。人們對你的應用的誤解將會影響到你的服務的推廣，如果運營商收到過多關於你的應用的投訴，那麼你的服務可能將被終止，甚至會牽連其他的應用。
訪問文件系統時至關重要的一點就是在沒有獲得用戶授權的情況下，不要訪問任何用戶的私人數據。而這一點，往往被大多數應用忽略了。W3C正在為移動開發商開發相關的標准API，但目前該工作尚未完成。
9.離線用戶
最後一個需要開發Native
App的理由就是，用戶有可能是離線的或者無法接入移動網路。這在城市可能很少發生，即使是在農村，網路的覆蓋也已經逐步普及了。但是短暫的網路連接中斷還是時常發生的，你的應用程序應該考慮如何處理這種情景。
想想用戶通常在什麼時候，在哪裡會使用你的App。如果是一個移動游戲，那麼用戶很可能在飛機上使用這個App。跟蹤地圖應用常在偏遠且網路覆蓋不佳的地方使用。移動旅遊向導常在一個國外的網路中訪問，往往需要支付漫遊和國際網路費用。這時，應用程序最好能夠為用戶提供離線服務，保證用戶在不接入網路的情況下，仍然能享受同等的服務。
現在支持HTML5的瀏覽器也能實現離線訪問功能，但對用戶來說可能不太明顯。隨著越來越多的瀏覽器都開始支持離線訪問，應用需要明確地告訴用戶網路連接中斷時，他們仍然可以訪問移動Web
Apps。
Native
Apps常常假設網路連接是可靠的。App通常只考慮了網路狀況良好的情景，想當然地認為網路是封閉的，並且網速足夠快。移動設備從網路良好的環境突然進入一個網路糟糕的環境並不少見。Native
Apps應該在網路狀況最差的情況下測試。比如用戶啟動任務時可能還是全信號覆蓋，而在任務結束時可能已經完全沒有網路信號了。
用戶在安裝Native
Apps時，根本不會考慮是在線訪問還是離線訪問——他們期望的是不管在任何狀況下，Native Apps都能正常工作。而這也是開發者的職責。
什麼時候應該選擇Web
App
只要你的應用程序不滿足之前提到的Native App條件之一，那麼你就沒有必要開發一個Native
App，而應該選擇開發一個Web App。正如文章之前提到的，我是一個Native App的擁護者，我認為Native
App有許多優秀的特質，並且具有很大的市場潛力，但是Web Apps是唯一一個經久不衰的移動內容、服務、應用開發平台。
Native
App並不能明顯地為用戶提供更好的服務；它反而會增加項目的成本，減少了應用發布的渠道，增加了App升級的復雜度，削弱了開發者對應用的控制和利潤，並且可能會給設備帶來麻煩。Native
App可以為開發者帶來短期的效益，但這是有一定風險的，甚至可能會影響到移動市場的可持久發展。
移動Web App的優勢在前文中已經提到過了。如果上一節提到的幾點功能是促成你選擇Native
App的唯一原因，那麼如果能夠在移動瀏覽器上屏蔽這些障礙，你是否還會堅持選擇Native
App呢？Palm的webOS已經著手解決了上述的部分問題。他們基於WebKit構建了一個全移動操作系統，將手機變成了一個Web瀏覽器。所謂的「Native
Apps」實際上就是一個Web Apps。
PhoneGap也是一個類似的項目，這個開源項目用於幫助開發者在iPhone、Android以及BlackBerry設備上開發Native
Apps，並且能夠模擬設備上的功能（如定位功能和文件系統）供Web
Apps調用。這些代碼可以在各個設備的應用商店中發布並且出售，但是他們使用的通用代碼和設計是可以共享的。由於開發的是一個Web
App，開發者可以為低端的移動瀏覽器開發一個簡化版的應用。只用開發一次，就可以部署在多個平台上了，
對於那些有著豐富的移動開發經驗的程序員來說，一提到「要開發一個功能豐富的應用」時，可能首先想到的就是Native
App。雖然在很多設備上，這一想法仍然適用，但是現在移動Web Apps上也提供了足夠豐富的功能介面供開發者調用。這使得Web App不僅可以像Native
App一樣被設計得功能豐富界面絢麗，而且還能在各個平台上遷移，甚至不用修改一行代碼。
現在在移動設備開發中，移動Web
Apps的創新進入了前所未有的高潮時期。但更重要的是，這是有史以來第一次，移動設備開發商決定共同制定一個移動Web開發的標准，就像是桌面Web上的標准一樣。不僅如此，那些支持移動Web
App創新功能的設備或是支持第三方瀏覽器的移動設備都受到消費者的歡迎。
㈥ Web App 和 Native App跟H5有什麼不同該如何選擇
移動互聯網的快速推進，APP應用得到了響應性的普及，增長較明顯的主要集中在創業型公司。同時，HTML（超文本標記語言）第五版的更新，也就是大家常說的H5，在移動端，由於其相對較低的開發成本及強大的跨平台運行能力，越來越多的信息型產品也開始選擇這樣輕量級的H5頁面進行快速迭代，同時借用微信等平台快速觸達用戶。早期APP紅利時期已過，使後面用戶數量增加變得困難，應用市場推廣APP的成本變得越來越高。對於還沒有大量融資的產品，在產品布局時我們如何去選擇尤為重要。Web App和 Native App跟H5我們應該如何選擇呢？下面就為大家分享Web App 和 Native App跟H5的區別：
我們就從web相對App的優勢\劣勢來分析。
優勢：
H5可跨平台使用，開發成本相對更低，一個產品經理+前端+設計+後台就能搞定；App則需適配iOS、安卓等不同平台進行設計和開發，至少需要iOS工程師+Android工程師+PM+前端+設計+後台，開發成本高出1/3甚至更多。
H5可隨時上線就更新版本，適合快速迭代，且試錯成本低。
一個功能做好了立馬就能上線，一天更新幾十次都毫無壓力；App則需要用戶主動下載更新，主流的就是iOS，Android、windows仨平台，不同平台運營推廣的玩法還不一樣，分發和運維成本很高。
而且一個版本的功能出來，雖然很快就能做出其中一部分讓內部人員體驗。但等我們全部做完了，可能已經過去一周了。然後提交給平台做審核，又要等一陣，再找個好日子發布，三周就過去了。同時，我們如果又做出了更多新的功能，優化了細節，再修復幾個bug等等，用戶卻也只能再等幾十天才能體驗到。
H5可以輕量的觸達用戶，提供更便捷的服務。
相比在桌面上下一大堆App，在微信的入口或者瀏覽器上，用戶只需點開鏈接就可以獲取我們所提供的服務。有更高的使用時長及導流能力，基於公眾號的運營和推廣可以快速的觸達用戶。
劣勢：
H5—>App的轉化強依賴於瀏覽器，要把用戶真正留存在自己的產品中需要進一步的轉化；而APP可以內嵌H5，直接在應用內即可打開並與H5進行轉化。
H5目前基本無法將數據存儲在本地，依賴實時性數據，網路狀態不好的時候卡到哭。
每當用戶需要上傳數據，比如輸入，選擇，傳照片等，頁面的延遲會影響使用的流暢性；而APP可以本地存儲，運行速度更快，更省流量，可離線操作或者訪問本地資源。
H5性能相對較低。
對於復雜的交互，比如3D特效，頻繁的輸入輸出等等，即使實現了，在用戶體驗上也要減分。比如在Native App上，一個類似頁面滑動切換的效果，基本不會感受到延遲，你手指只要開始滑動，頁面就無縫的跟著滑動，但在Web上，大家應該都經常看微信里的各種H5的花哨分享頁面吧，那滑動流暢嗎？
對於Web App 和 Native App跟H5這三者最終該如何選擇，我們還需要考慮，企業的具體產品需求，產品的核心功能，輔助功能，配合運營需求，應用場景等方面的影響。所有的產品都是有了場景才會有體驗，針對體驗才能有的放矢。再結合他們之間的的優劣情況，我們選擇起來就顯得比較簡單了。
但是，有很多的公司和團隊認為這兩種模式都比較適合目前產品的使用范圍，是否可以一起使用呢？微客達，一站式移動營銷服務，整合Web App、Native App、H5、微信公眾號等多種營銷渠道，幫助商家快速低成本建立自己的掌上營銷渠道，擴展生意輻射覆蓋范圍，沉澱新老顧客、促進二次銷售、實現可持續經營。讓您在移動互聯網高速發展的今天，更快速的佔領應用推廣市場，從同行中脫穎而出。
㈦ 輕應用，Web App，Native App三者有什麼區別
輕應用是什麼
LAPP (Light App) 即輕應用是一種無需下載、即搜即用的全功能 App，既有媲美甚至超越native app的用戶體驗，又具備webapp的可被檢索與智能分發的特性，將有效解決優質應用和服務與移動用戶需求對接的問題。2013年 8月22日，網路在2013年網路世界大會上宣布推出「輕應用」，可實現無需下載，即搜即用和通過移動搜索能。
輕應用運行平台
輕應用在Android/iOS/WP7平台上都可以運行。
輕應用的特點
第一，無需下載，即搜即用。
以往，開發者付出高昂成本拉動用戶下載應用，每隔十天半月還要推送更新版本，一不小心就遭用戶卸載。例如，一款名叫多趣的旅遊類應用，針對不同城市、不同景點有500多款應用，下載和更新成本成為橫亘在開發者和用戶間的高檻。通過輕應用，搜索「上海導覽」、「周庄導覽」的用戶需求都可以直接調起多趣，開發者後端的每一處更新在前端都自動呈現，無需騷擾用戶。
第二，破殼檢索，智能分發。
開發者開發的應用不再是信息孤島，裡面的內容都可以被索引，這跟原生應用形成明顯的差別。在應用商店裡，只有用戶輸入明確的App名稱，例如「嘀嘀打車」，這個應用才能夠被分發。而現在，移動搜索中自然表達的所有與打車有關的需求，比如「我要打車」、「從國貿到雍和宮」等，都將導向開發者開發的打車類應用，大大增加應用的曝光量和使用率，從源頭解決分發難題。
第三，功能強大，全能體驗。
輕應用能夠幫應用調起語音、攝像頭、定位、存儲等手機本地或雲端的多種能力，讓應用的功能更強大。以好大夫在線輕應用為例，開發者不僅可以設置語音交流模塊，還可以調起本地攝像頭幫助用戶拍攝化驗單或患處，從而提供和Native App相同甚至更好的體驗。
第四，訂閱推送，沉澱用戶。
輕應用不僅支持用戶搜索時實現調用，還支持用戶主動訂閱。如果用戶有訂閱需求並添加應用，相關開發者就能夠將用戶沉澱下來，並對用戶進行持續、精準的信息和服務推送。例如，很多視頻類應用的用戶有追劇的需求，網路支持用戶訂閱的功能，只要用戶訂閱了應用，每當有新劇更新，開發者都可以第一時間通知用戶，增強粘性，從而與用戶建立起更加穩固牢靠的關系
㈧ iOS APP與H5交互的三種方法
這種方法是利用攔截webView響應的url，對url進行處理，同時把需要執行的方法名和參數都放入url中，實現app和H5之前的方法交互：
這個屬性是WKWebView才有的屬性，主要是通過WKScriptMessageHandler的代理方法 - (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message 進行交互。
注意：
這兩個方法是成對出現的，每次調用了add就必須調用remove。
1.建立 WebViewJavaScriptBridge 和 WebView 之間的關系。
_jsBridge = [WebViewJavascriptBridge bridgeForWebView:_webView];
2.方法調用
1)oc調js方法（通過data可以傳值，通過 response可以接受js那邊的返回值 ）
2)js調oc方法（可以通過data給oc方法傳值，使用responseCallback將值再返回給js）
最後：iOS調用H5方法
UIWebView： NSString *result = [webView :@"javascript:add(3,5);"];
WKWebView: [self.webView evaluateJavaScript:@"show()" completionHandler:^(id _Nullable response, NSError * _Nullable error) { //TODO }];