㈠ H5 與Native的交互方案
App里基本都少不了H5頁面，因此js與Native之間的通信不可避免，最近留意了一些方案，做下總結。
iOS有兩種webview，ios8以上推出了WKWebView，低於ios8用的是UIWebView，WKWebView性能上優於UIWebView
Native調用Javascript語言，是通過UIWebView組件的方法來實現的，該方法返回js腳本的執行結果。
雙方只需要約定好JS端函數名稱及參數
JS調用Native，並沒有現成的API可以使用，需要藉助iframe來實現。原理是在UIWebView內發起的所有網路請求，都可以通過delegate函數在Native層得到通知。所以只需要劫持該UIWebView內的所有請求（通常是這樣的格式： jsbridge://methodName?param1=value1¶m2=value2 ），然後在UIWebView的delegate函數中，只要發現是jsbridge://開頭的地址，就不進行內容的載入，轉而執行相應的調用邏輯：
在android里是使用webview的loadUrl進行調用的
有兩種比較好的方式：
JS端可以直接調用：alert(AndroidJS.getUserData()) //UserDate
基於 callHandler 和 registerHandler的方式，比較干凈
1、 Web 與 App 數據交互原理和實現
2、 WK 與 JS 的那些事
3、 H5 與 Native 交互之 JSBridge 技術
4、 WebView 開車指南之最全實用案例
㈡ H5頁面與原生App（安卓，IOS）交互
在客戶端項目中，同一個app會開發成兩個版本，一個是安卓版本，一個IOS版本，公司必須有兩個開發團隊（一個安卓團隊，一個IOS團隊）來進行開發，這樣一來，開發成本非常之高。所以，往往在實際項目-中，會嵌套很多H5頁面，一個H5頁面同時兼容安卓和IOS兩個系統 ，這樣一來，大大減少了開發成本，前端開發頁面就必須和原生進行交互。
1. 頁面開發 —— 前端開發人員將所有的頁面按照移動webappp進行開發，做好不同屏幕的適配（寬度100%,視口為移動端視口 (快捷方式meta:vp tap），字體適配rem單位，設置html根標簽的font-size然後根據媒體查詢判斷設備屏幕大小進而設置html根標簽的不同fontsize，去除移動端高亮顯示；小圖標要善於使用字體圖標（常用的字體圖標庫有阿里巴巴矢量圖），改變input標簽的默認樣式可以採用隱藏input,然後通過字體圖標來控制前面的圖標，就可以做成自己想要的圖標效果）
2.前端頁面部署 —— 設置好入口文件（原生一進來就進入的頁面，命名為index.html），部署到對應的伺服器上，通過網址就能夠訪問到頁面，將網址給app客戶端開發人員，他們將app配置好環境後講頁面嵌套在app中。
3.進行數據對接：兩種對接方式（1）.前端頁面自己通過ajax去後台拉數據，然後自己在頁面上使用再提交給後台。前提是原生需要將對應的設備號，加密方式，請求數據所需要的各種參數通過回調函數傳遞給H5頁面，H5頁面拿到這些數據後直接調後台的借口、獲取到數據。（2）.前端頁面不用自己去後台拉取數據，而是通過回調函數，獲取到原生app拉取的數據，前端頁面將這些數據處理後又通過回調函數交給app，再又app發送給後台。兩種調用的優劣比較：如果H5頁面及數據不是很多，使用第二種方式比較合理，不用H5頁面請求數據（不用封裝請求，不用加密數據），不使用框架，大大減少了頁面的大小，提高性能及用戶體驗。如果涉及到的前端頁面非常多，數據交互比較復雜的話，就必須使用第一種對接方式了，app只需要將設備號，加密規則，參數傳遞給H5，H5根據頁面需求自己向後台拉去和請求數據，直接交互，不再通過app進行轉接，減小復雜程度。
㈢ h5與APP交互方式
舉個簡單的例子，有個需求是要和APP交互的，h5頁面裡面有個分享按鈕，點擊之後需要調用APP原生的分享功能
app那邊寫好了一個方法是onShare( )
第一步：就是點擊分享好友觸發
第二步：定義onShare方法調用APP方法
isAndroid_ios（）這個函數是判斷是否是安卓或者是ios
因為安卓和ios的調用方法不同
以onShare()方法為例：
安卓：window.AndroidFunction.onShare('1'); // android
IOS：window.webkit.messageHandlers.onShare.postMessage(』1『); //ios
裡面可以傳參給APP 的
這個h5這邊很簡單，只需要把方法掛載到window上，APP就能調用
具體為
㈣ H5必知必會之與App交互
奇技指南
2018年11月26日發表的「360 AI音箱H5開發實踐」一文中，曾簡單提到「與Native交互」。本文將就此主題深入探討H5與App交互的幾種常見模式。
本文內容如下：
H5，在中國被專門用來指代開發內嵌於手機應用中的網頁的技術，外國好像並沒有這個說法。從技術上講，H5是HTML5即Hyper Text Markup Language（超文本標記語言）第5版的簡稱。而HTML只是開發網頁要用到的多種技術之一。除了HTML，還要用CSS設計界面，用JavaScript實現交互，甚至要用Node.js實現服務端邏輯。為什麼H5會被用來籠統地指代這些技術呢？我猜一是因為它簡單，二是移動端網頁開發技術又恰好需要這么一個概念。
移動端網頁運行在手機應用內嵌的瀏覽器引擎中，這個沒有UI的內核容器統稱WebView，即iPhone的UIWebView（iOS 2.0–12.0）、WKWebView（iOS 8.0+，macOS 10.10+）和Android的WebView。總之，WebView就是在手機應用中運行和展示網頁的界面和介面（神奇的是，英文Interface，既可以翻譯成「界面」也可以翻譯成「介面」）。
H5與原生應用的交互都是通過原生應用中的WebView實現的。通過這個環境，H5可以調用原生應用注入其中的原生對象的方法，原生應用也可以調用H5暴露在這個環境中的JavaScript對象的方法，從而實現指令與數據的傳輸。
比如，在Android應用中，WebView類有一個公有方法addJavascriptInterface，簽名為：
調用這個方法可以向WebView中以指定的名稱name注入指定的Java對象object。這樣，WebView中的JavaScript就可以通過name調用object的方法。比如：
在iOS或macOS中，需要通過創建WKWebView類的實例在應用中嵌入網頁，交互過程類似。
所謂基礎介面，就是首先要規定原生應用和JS分別在WebView里注入/暴露一個什麼對象：
並約定在這兩個對象上分別可以調用什麼方法：
顧名思義，NativeBridge.callNative是由JS調用向Native傳遞指令或數據的方法，而JSBridge.callJS則是由Native調用向JS傳遞指令或數據的方法。方法簽名中的參數含義如下：
基礎介面只有兩個對象和兩個方法，JS與App間的互操作則通過action和params來擴展和定義。
對於JS而言，雖然這里只定義了一個對象一個方法，但實踐中，可以把action對應方法的實現附加到JSBridge上，只要把callJS實現為一個分發方法即可，比如：
這樣，所有對callJS的調用，都會轉化成對JSBridge上相應action方法的調用，優點是只需一行代碼。
另一種實現方式是通過switch...case語句實現調用分發，比如:
這樣實現的優點是所有方法一目瞭然，當然同樣也是把所有相關介面都附加到同一個JSBridge對象上。
以上兩種實現模式各有利弊。
由JS發起的單向調用App的操作，主要涉及載入URL和切換到原生界面，可對應如下action：
loadUrl調用的參考協議如下：
這里NativeBridge是App的原生對象，其callNative方法被調用時，會收到一個對象（字典/映射）參數。根據這個參數的action屬性的值，App可知需要執行的操作是載入URL。於是再取得params屬性中的url，發送請求即可。
loadContent調用的參考協議如下：
同上，這里通過params向App傳遞了必要參數，App負責切換到相應的原生界面。
由App發起的單向調用JS的操作，主要涉及用戶點擊後退按鈕（<），可對應如下action：
can_back調用的參考協議如下：
此調用返回的值示例如下：
顧名思義，can_back用於App詢問JS：在返回上一級界面前，是否彈窗提示用戶？
返回值中的can如果是true，則直接返回，不提示；如果是false，則彈出一個確認框，請用戶確認。另一個值target是與App約定的返回目標，比如prev表示返回上一級，top表示返回頂級，等等。
雙向調用是JS先調用App，然後App在完成操作後再調用JS，雙向通常都需要傳遞數據。雙向調用主要涉及JS調用App原生組件和用戶點擊右上角按鈕，可對應如下action：
loadComponent的參考協議如下：
在這個例子中，涉及JS調用App顯示其實現的城市選擇組件：type: 'location'，用戶選擇完城市之後，App再調用set_location，將用戶選擇的城市名稱傳給JS：
JS根據拿到的值更新界面，完成一次雙向調用。另一個例子是JS調用原生的日期選擇組件，與此類似。
為什麼叫displayNextButton？因為根據具體業務場景，可能存在如下三種情況：
displayNextButton協議的參考實現如下：
以上代碼示例表明，JS調用App，告訴App顯示「下一步」按鈕，但是要禁用變灰，因為enable: false。如果傳遞的是enable: true，那麼用戶就可以點擊「下一步」按鈕了。點擊之後，App再調用JS的save_form。最後，如果不想顯示按鈕，可以傳遞name: ''。
下面重點說一下用戶點擊「下一步」按鈕，App調用save_form的場景。此時也分兩種情況：
如果是JS通過App保存數據——可能因為App端實現了數據寫入必需的加密機制——那麼，JS可以在App調用save_form時將約定好的數據返回給App，由App去保存數據。
如果是JS直接保存數據，比如通過Ajax，那麼在保存完數據之後，則還需要調用前面所說的App暴露的loadUrl或loadComponent方法，以告知App切換界面。當然這種情況下會出現第三次調用，但仍然屬於雙向調用。
本文介紹了JS與App交互的幾種模式，而且只討論了JS端的實現。在開發實踐中，團隊各端總會面臨哪一端主導的問題。本文展示的參考實現就是H5端主導的一種實現形式。H5主導的特點是把主要業務邏輯都封裝到WebView中，App主要協同配合，而優點是業務邏輯的變更不會蔓延到App。畢竟相對於H5，App的安裝部署模式會造成多版本共存問題，需要盡可能控制新版本。假如由App端主導，將邏輯封裝在App端，勢必造成版本不受控，給整個項目或產品埋下隱患。
當然，事無絕對。具體情況還要具體分析。而且，哪方主導有時候也取決多方面因素。實踐中還是要因人、因時、因勢制宜。
㈤ H5與小程序數據交互
功能已通過原生+vue混合開發的方式實現了，現需要將這個功能原封不動的搬到微信小程序。綜合各方面評估，選擇了微信小程序套webview的方式實現（若時間允許，建議還是通過小程序實現）。
採用小程序webview的方式，可以復用大部分H5頁面，但H5調用的原生方法還是需要重新實現。實現方式主要分以下幾種情況（當然也可以通過jssdk的方式去實現 https://qydev.weixin.qq.com/wiki/index.php?title=%E5%BE%AE%E4%BF%A1JS-SDK%E6%8E%A5%E5%8F%A3 ，但不在本文討論范圍內）：
(1) 獲取照片，可通過html的input標簽實現；
(2) 獲取經緯度，可通過webview的url拼接參數實現；
(3) 人臉識別，可通過H5調起刷臉小程序的方式實現。
下面主要描述下第3種情況的實現方式。
H5與小程序交互所涉及的數據部分主要包括兩塊：
(1)H5如何將數據傳給小程序？
url參數拼接。
(2)小程序如何將數據傳給H5？
wx.setStorage及wx.getStorage。
詳細流程如圖所示。
webview小程序pageA調起人臉小程序pageB，pageB回退到pageA。因為pageA重新設置了webview的url，其所嵌套的H5與歷史H5頁面無法進行數據共享，導致業務功能無法繼續。解決辦法就是調起人臉小程序之前，在H5頁面先將必要的信息通過 localStorage.setItem 保存，人臉識別結束回到H5頁面時，再通過 localStorage. getItem 獲取所需要的業務數據。
㈥ h5與原生交互
app混合開發，嵌入h5頁面，應該是現在比較流行的一種開發方式。優點：開發速度快、app不用頻繁提交審核、發版；缺點：h5的交互畢竟不如原生，開發時的溝通成本較大。
開發的過程中，會遇到一些h5或原生自身解決不了的交互，舉例：在h5頁面點擊按鈕彈出原生做的彈窗。
這個時候就需要通過h5調用原生的方法展示彈窗，反之一樣。
其中 show 為ios定義的方法名， "顯示彈窗" 是傳過去的參數。
注意：參數不能為空！不然進去不方法。
也就是不可以postMessage()這樣調用，沒參數可以postMessage(null)
其中 supportJs 是android定義的js對象， show 為方法名， "顯示彈窗" 是傳過去的參數。
注意：定義的方法不接收參數的話，不能傳參！不然進去不方法。
也就是不定義參數的話，show()這樣調用
然後就可以在原生中調用方法名為Hybrid.show的js方法了，js接收一個參數，也可以根據實際業務定義多個參數。
㈦ 《H5匠人手冊》1：H5交互流程
H5交互流程矩陣圖 1、項目溝通 1.1 邀請參與者開會： 組織參與者碰頭會：參與者包括項目負責人、產品經理、設計人員、開發人員、利益相關部門人員等 項目相關者全部到場，確認基本工作量、技術設計邊界、項目工期安排、避免不不必要的返工 1.2 明確項目背景： 前期會議要明確項目背景、卻敵那個項目的整體規劃，整體包括： 1）項目背景：項目主題、目標受眾、決策方、是否有第三方參與、是否有商業合作等 2）商業目的：需要突出的商業元素、預期達到什麼樣的傳播效果 3）重要程度：判斷策劃的難易、交互邏輯、設計風格、開發資源 4）上線時間：確定開發周期 1.3 常見問題： 1）項目方想展示的文本內容過多 2）發起方對核心交互方式把握不夠精準 3）技術開發難度 4）需求文檔不清晰 2、策劃評估 2.1、動機——是否能在短時間內吸引用戶注意力並完成閱讀 、 影響用戶瀏覽的重要因素：目標&情感 目標指用戶的目的性,目的性的強弱在很大程度上決定了用戶瀏覽的耐心，用戶完成某個操作的目的性月強，他就越可以忍受過程中帶來的不愉快的體驗， 應用的目的性往往是由產品的屬性決定的。 用戶情感：決定了用戶可以接受影響的程度，一般主觀性越強用戶越容易受到情緒的影響進而改變行為。 1）利用心流理論控制節奏 進入心流狀態的用戶通常有兩個重要的表現：一是完全投入一項活動並從中感受到愉悅，二是關注體驗過程從而忽視時間。在H5中我們要做的就是通過心流把控影響用戶的主觀因素。 與心流關系密切的兩個要素：「挑戰」和「技能」 從高挑戰對應中技能的「激發」狀態，讓用戶不斷提高技能後進入高挑戰對應的高技能的「心流」狀態，隨著技能的不斷提高，原來的高挑變為了中挑戰，於是用戶就又進入了「激發」狀態；如此往復，才能讓用戶達到一個正向循環，促進心流的過程。所以在H5的設計過程中，如果我們能讓用戶達到這樣的過程，就能牢牢抓住用戶，讓他們有耐心，有興趣瀏覽完我們的H5。 2）利用HOOK理論引導用戶 引導用戶的行為需要4個步驟：觸發（誘因）—行為—多變的酬賞—投入①觸發與行為： 促進一個人的行為的有三個關鍵因素：觸發，動機、能力（福格行為模型） 通過觸發引導用戶進入到一個HOOK循環後，用戶在完成任務時，影響任務的難易程度有6個要素： 1、時間：完成這項任務所需要的時間 2、金錢：從事任務所需要的經濟投入 3、體力：完成任務所需要的體力 4、精力：從事任務需要消耗的腦力 5、社會偏差：他人對該項活動的接受度 6、非常規性：該項活動與常規活動之間的匹配程度或矛盾程度 在H5的設計范圍中，最常用到的是如何控制用戶花費的時間、精力。盡量讓用戶加快瀏覽速度，可以為用戶節省時間，不要設置過於復雜的操作，為用戶節省精力。 ②多變的酬賞： 在用戶行動後，一定要給用戶提供豐富的不可預知的獎勵。多變的酬賞並不是漫無目的的； 我們設置酬賞的時候要給出一個明確的目標范圍，而不是用戶無法預期的結果。 酬賞的三種表現形式： 社交酬賞：即社會認同感，人們通過社交產生獎勵，例如朋友圈中的點贊和評論。 獵物酬賞：即人們在使用中獲得直接物質獎勵，例如搶代金紅包。 自我酬賞：即人們在活動過程中獲得的操控感、成就感，例如堅持健身打卡獲得的勛章。 ③投入 ：在投入環節我們要讓用戶付出一些東西，例如時間、精力、金錢等，這些會讓用戶產生新的動機，讓用戶再次進入行為環節繼而進入下一個上癮循環。我們在策劃過程中，可以盡量讓用戶通過主動生產內容的方式參與到H5中，增加用戶在H5中的投入，用戶投入越多，越不會輕易離開。 2.2、框架—展現形式是否符號策劃主題 按照交互的復雜程度，將展現形式分為三類： 1）展示型： 涉及的交互非常少、多以展示內容為主 2）引導型： 通過一些交互引導用戶完成操作 3）操作型： 涉及大量的交互，吸引用戶完成操作 通過策劃創意、交互程度、閱讀體驗、視覺表現、技術能力5個維度對各展示類型評價 ①展示型：展示型按交互從弱到強分為：視頻類、幻燈片類、空間展示類。展示型H5，是指打開頁面僅通過幾個簡單常規操作甚至不操作，就能直觀看到展示內容。這類H5的優勢是易於流暢地呈現一個完整的故事或品牌形象，交互層級少，技術難度低。缺點也比較明顯，對內容要求非常高，得足夠吸引用戶看完整個內容，如果交互形式簡單乏味，也容易造成用戶流失。 視頻類： 視頻要足夠吸引人 視頻不要過長。如果過長，建議分段播放 視頻分段後，可用交互手勢連接 幻燈片類： 著重優化動效和視覺，頁數盡量控制在6-8頁 盡量在結構和頁面連接上創新，增加有趣的交互 空間展示類： 結構層級越少越好 交互盡量簡單清晰 ②引導型：互動視頻類和小場景類。引導型表現形式豐富，讓用戶在閱讀中始終保持沉浸感。不斷變化的交互方式或反饋獎勵能激勵用戶不斷的閱讀。但劣勢和展示類一樣，還需要強大的策劃能力，創意和情感因素才能支撐整個H5。 互動視頻類： 可以讓用戶引導故事走向，增加不確定性 可以利用交互點的精確把控，准確地配合故事結構，讓故事更生動。 小場景類： 場景之間有一定的關聯和過渡，讓場景更加連貫。 場景間的過渡盡量不要重復，盡量符合場景所在的劇情。 需要給用戶明確的提示和引導。 ③操作型：小游戲、做測試和技術類。操作型是指用戶更主動和深入地與H5交互，通過操作控制H5的走向和結果。 小游戲： 能夠快速的吸引用戶注意力，快速帶領用戶進入心流 游戲中可以穿插策劃需要突出的重點 小游戲可以給予用戶獨特的成就，以便增加分享幾率 要給予用戶操作上的引導 不要講H5的體量做的過大，導致載入問題。 做測試: 這類策劃最好和用戶的社交屬性相關聯 最終結果最好難以預料、調動用戶的好奇心 可以通過回答不同難度的問題，得到不同的結果 技術類： 以技術為向導、強調產品的特性 突出主題中的某些特點 2.4、交互—交互方式與策劃是否匹配 2.5、原則—是否符合移動端的交互原則 1）簡化層級，結構扁平化 移動端由於設備本身的限制，沒有足夠的空間來展示路徑，如果沒有清晰的層級關系，或者需要進入層級更深的頁面才能找到用戶想要的，這意味著用戶會迷失方向，這時更應該減少層級的深度。 2）降低閱讀門檻，減少認知成本 實現方法： 單頁面操作單一化 多頁面操作一致化 通過擬物化設計減少用戶認知成本 利用手機感測器，讓交互更自然 3）H5要注意分享屬性 促進分享的方法： 在結果中帶有一定的社交屬性 分享後直接獲得獎勵 產生心理共鳴、擊中用戶 用戶獲得成就感，要曬給大家看 如何增加迴流 ： 充分發揮社交屬性、打造個性化分享鏈接 善於利用熱點和流量點 3、產出 3.1、界面落實 交互設計師產出交互稿，跟進項目 完整的流程圖：表面載入點、提示點、動效點、操作點、跳轉邏輯等 交互文檔：交互頁面、頁面所需的交互手勢、點擊位置、跳轉邏輯、動效、載入位置等 3.2、完善細節 3.3、溝通跟進 1）載入與控制項文件的大小 一般H5的大小建議控制在5M以內，用戶在流暢的網路環境中可以1S之內載入完成。 減少H5大小的方法： 1）圖片壓縮：PNG格式的圖片，導出時建議使用PNG-8格式，顏色位數建議選擇256 2）文字處理：一般500個漢字所佔內存約1KB，而一張文字轉圖片至少10KB，因此，除非應用特殊字體，不建議將文案以圖片的形式輸出。 載入處理方案： 1）全局載入：在H5封面出來之前一次性載入全部內容。在查看H5過程中不會出現卡頓的現象，用戶體驗流暢，不過載入時間過程，當文件過大時，在載入時應提醒用戶注意流量。 2）優先載入：按照內容的重要程度，先將主要部分載入出來，再載入次要的部分。一般用於圖文混排，優先載入文字，再載入圖片。 3）分段載入：將H5分成若干段落，當用戶看到某一段落後再對下一段落進行載入。適合分章節策劃的H5。 3.4、測試上線與數據監測 常規的測試要點包括： 1）跳轉邏輯是否正常 2）頁面展示邏輯是否流暢 3）平台之間是否有交互沖突 4）H5的載入速度如何，能否再壓縮H5的大小。