『壹』 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進行轉接，減小復雜程度。
『貳』 原生APP中js怎樣與Android和ios進行交互
Android的webview是基於webkit內核的,webview中集成了js與java互調的介面函數,通過addJavas criptInterface方法,可以將Java的類注冊進webkit,給網頁上的js進行調用,而且還可以通過loadUrl方法是給webkit傳遞一個URL,供瀏覽器來進行解析,實現Java和js交互。要想運行網頁上的js腳本,webview必須設置支持Javas cript。Java代碼1mWebview.getSettings().setJavas criptEnabled(true);然後是設置webview要載入的網頁:web的網頁:webView.loadUrl("http://www.google.com");本地的網頁:webView.loadUrl("file:///android_asset/XX.html"); //本地的存放在:assets文件夾中webview做完基本的初始化後咱們還要要給它,加進一個回調的代理類Javas criptInterface,並給它一個調用的名稱:ncpJava代碼1mWebView.addJavas criptInterface(new Javas criptInterface(),"ncp");Javas criptInterface可以是一個普通的Java類,類實現的方法,均可被js回調:Java代碼final class Javas criptInterface {public int callOnJs() {return 1000;}public void callOnJs2(String mode) {//TODO}}Java要調用js的方法,只需知道js的方法名稱即可:Java代碼1mWebView.loadUrl("javas cript:onSaveCallback()");js 這邊就更簡單:Js代碼window.onload = function(){document.getElementById('btn_1').addEventListener('click', onBtnClick, false);var _int_value = window.ncp.callOnJs();alert("get int from java:" + _int_value );}function onBtnClick() {window.ncp.callOnJs2("click");}
『叄』 iOS WKWebView JS 與 原生交互小結
目前iOS項目中 Webview 幾乎都會用到，iOS 8 之前使用UIWebView，iOS 8 之後 Apple 就不推薦使用了，目前已經放棄了，如果項目中存在就無法上架了，需要轉為WKWebView了，說實話 UIWebView 是有性能上的缺陷，內存優化不夠友好等，但是不得不說這是老的iOS開發人員用的最熟練熟悉的了，用起來得心應手。非迫不得已還真不願轉到WKWebView。好吧，既然已經這樣了，又何必苦苦單戀一支花呢？
看了網上教程很多，自己使用小結一下，簡單易用，本文適用於菜鳥級開發，廢話不說了，
最主要的方法：發送消息
注意：對象名和方法名jumpUserProtocol名字的一致，參數可以是常用的NSArray，NSDictionary等類型，先說下在這個Demo中其實沒用上，用的方法名判斷的。
注意： addScriptMessageHandler
name為方法名 ，和JS 中的保持一致，添加腳本，相當於給Webview添加一個監聽，有這個功能來處理JS。
在WKScriptMessageHandler代理方法中處理回調，實現自己的邏輯。
上面就是JS調用OC原生實現。
這個其實很簡單，就一個方法：
『肆』 H5與原生APP交互方式 (IOS及安卓)
判斷設備
JS與IOS交互方式一：WKScriptMessageHandler
WKWebView有一個內容交互控制器，該對象提供了通過JS向WKWebView發送消息的途徑。需要設置MessageHandler，大家把這個功能簡稱為MessageHandler。
IOS具體實現參考： 鏈接
這里只說js調用
JS與IOS交互方式二：WebViewJavascriptBridge交互 攔截url做事件處理，如果要傳參數，不建議用這種
Android端交互
冒號前面區分是什麼功能，冒號後面是接收的參數
『伍』 iOS 原生與JS交互 （webkit + js）
鑒於最近項目中需要用到原生與JS交互，以前做過交互，但是沒有總結一個demo，這次做的時候都忘記了，所以這次做了一個swift 和 OC 的demo。方便以後需要用交互功能的時候查看。
由於也沒有難的點，所以這里就不做技術上的講解了。直接上的地址： iOS webKit (swift + oc) 原生交互Demo . demo里包含了Swift 版和 OC版 ,由於UIWebView的性能相比webkit而言，相差甚遠，在加上現在的項目基本都支持8.0以上的系統，所以基本可以放棄UIWebview了。
『陸』 App與Js交互（一）iOS
Demo： https://github.com/gwpp/jsinterface
不論是在創業團隊中快速試錯，還是在成熟團隊中快速迭代復雜需求，還或者是其他原因，WebView在APP中的大量使用已經成為了一個明顯的趨勢，這也應該算是大前端融合的一個表象吧。筆者在工作中也遇到過很多App&Js交互的問題，粗淺的研究了一下，這里也分享給大家，如果有錯誤的地方還請下方留言指出，共同進步。
眾所周知，iOS有 UIWebView 、 WKWebView 兩個組件可以用來渲染嵌入頁面。前者使用甚廣，出生的也早，後者是iOS8推出的，優化了載入速度和內存，安全性上也有所提升。具體的兩者比較網路、上都很多，這里不做贅述。
前兩種方法到此就介紹完了，很簡單，但是在項目大了之後攔截跳轉的代理方法中會有非常多的判斷。冗餘、可維護性差，硬編碼重。所以我們會有下面的其他方法。
JSContext即JavaScriptContext，這個東西在UIWebView中可以拿到，但是在WKWebView中卻是取不到了，所以只能用在UIWebView中。除此以外Android里也有類似的一個東西，所以使用JSContext就有了在JS端多平台統一的可能，這里不多說，在《App與Js交互（三）》中會有詳細說明。
JSContext的原理就是iOS暴露出去一個遵守 <JSExport> 協議的對象給JS，JS可以直接調用該對象的public方法。
window.webkit.messagehandlers.<name>.postMessage 是apple推薦使用的WKWebView的JS交互方式，使用起來比較簡單，不支持callback回調。
『柒』 iOS - OC 與 JS 交互六種方式總結
在 APP 中，免不了與 H5頁面打交道，所以掌握 與 JS 交互就顯的至關重要，本文總結了常見的與 JS 交互方式。
注意事項
在 OC 原生中
在 html 文件中
早期的JS與原生交互的開源庫很多都是用得這種方式來實現的，例如：PhoneGap、 WebViewJavascriptBridge 。
效果圖
使用WKNavigationDelegate中的代理方法，攔截自定義的 URL 來實現 JS 調用 OC 方法。
注意點
關於如何區分執行不同的OC 方法，也與UIWebView的處理方式一樣,通過URL 的host 來區分執行不同的方法：
JS 調用OC 方法後，有的操作可能需要將結果返回給JS。這時候就是OC 調用JS 方法的場景。
WKWebView 提供了一個新的方法 evaluateJavaScript:completionHandler: ，實現OC 調用JS 等場景。
注意點
運行結果
在iOS 7之後，apple添加了一個新的庫JavaScriptCore，用來做JS交互，因此JS與原生OC交互也變得簡單了許多。
首先導入JavaScriptCore庫, 然後在OC中獲取JS的上下文。
再然後定義好JS需要調用的方法，例如JS要調用share方法：
則可以在UIWebView載入url完成後，在其代理方法中添加要調用的share方法：
OC 調用 JS 方法有多種，首先介紹使用JavaScriptCore框架的方式。
使用JSContext 的方法 -evaluateScript ，可以實現 OC 調用 JS 方法
效果圖
使用WKWebView的時候，如果想要實現JS調用OC方法，除了攔截URL之外，還有一種簡單的方式。那就是利用WKWebView的新特性MessageHandler來實現JS調用原生方法。
創建 WKWebViewConfiguration 對象，配置各個API對應的MessageHandler。
然後在界面即將顯示的時候添加MessageHandler
需要注意的是addScriptMessageHandler很容易引起循環引用，導致控制器無法被釋放，所以需要移除MessageHandler
這里實現了兩個協議 <WKUIDelegate,WKScriptMessageHandler> ， WKUIDelegate 是因為我在JS中彈出了alert 。 WKScriptMessageHandler 是因為我們要處理JS調用OC方法的請求。
WKScriptMessage 有兩個關鍵屬性 name 和 body 。
因為我們給每一個OC 方法取了一個name，那麼我們就可以根據name 來區分執行不同的方法。body 中存著JS 要給OC 傳的參數。
關於參數body 的解析，我就舉一個body中放字典的例子，其他的稍後可以看demo。
解析JS 調用OC 實現分享的參數：
message.boby 就是JS 里傳過來的參數。我們不同的方法先做一下容錯性判斷。然後正常取值就可以了。
下面只列舉一個shareClick()方法，其他看Demo
這里使用WKWebView 實現OC 調用JS方法與之前說的文章一樣，通過
- evaluateJavaScript:completionHandler:
效果圖如下圖所示
詳情看下面文章鏈接
iOS下 JS 與 OC 互相調用(五) - UIWebView+WebViewJavascriptBridge
詳情看下面文章鏈接
iOS下 JS 與 OC 互相調用(六) - WKWebView+WKWebViewJavascriptBridge
iOS下 JS 與OC 互相調用(一) - UIWebView 攔截 URL
iOS下 JS 與OC 互相調用(二) - JavaScriptCore
iOS 下 JS 與 OC 互相調用(三) - WKWebView 攔截 URL
iOS下JS與OC互相調用(四)-MessageHandler
iOS下 JS 與 OC 互相調用(五) - UIWebView+WebViewJavascriptBridge
iOS下 JS 與 OC 互相調用(六) - WKWebView+WKWebViewJavascriptBridge
『捌』 原生APP中js怎樣與Android和ios進行交互
一、對於Android和ios我們要執行不同的操作，下面是判斷系統的js代碼
// alert(ismobile(1)); 1表示Android，0表示ios
function ismobile(test){
var u = navigator.userAgent, app = navigator.appVersion;
if(/AppleWebKit.*Mobile/i.test(navigator.userAgent) || (/MIDP|SymbianOS|NOKIA|SAMSUNG|LG|NEC|TCL|Alcatel|BIRD|DBTEL|Dopod|PHILIPS|HAIER|LENOVO|MOT-|Nokia|SonyEricsson|SIE-|Amoi|ZTE/.test(navigator.userAgent))){
if(window.location.href.indexOf("?mobile")<0){
try{
if(/iPhone|mac|iPod|iPad/i.test(navigator.userAgent)){
return '0';
}else{
return '1';
}
}catch(e){}
}
}else if( u.indexOf('iPad') > -1){
return '0';
}else{
return '1';
}
}
二、js調用app端函數，下面是js代碼
if(ismobile(1)==1){
Android.setTypeActivity(id,type,href);
}else{
jsToios(id,type,href);
}
setTypeActivity是Android端定義的函數，jsToios是ios端定義的函數，括弧里是js端傳遞的參數。
三、至於js端怎樣獲取app端的數據，只需在js端提供給app端函數名字，在通知app端調用即可
四、還有一種方法可以不通過app的方法將數據傳遞給另一個頁面，那就是通過URL的方式
在本頁面將數據拼接在ip後面
在另外一個頁面通過下面方法獲取URL後的參數
function GetRequest() {
var url = location.search; //獲取url中"?"符後的字串
var theRequest = new Object();
if (url.indexOf("?") != -1) {
var str = url.substr(1);
strs = str.split("&");
for(var i = 0; i < strs.length; i ++) {
theRequest[strs[i].split("=")[0]]=decodeURIComponent(strs[i].split("=")[1]);
}
}
return theRequest;
}
// 獲取URL參數
var Request = new Object();
Request = GetRequest();
var name;
name = Request['name'];
『玖』 原生APP中js怎樣與Android和ios進行交互
從使用場景上，Web App用戶面臨比原生APP用戶更嚴峻的問題： 1、 頁面跳轉更加費力，不穩定感更強 思考點：如何減少跳轉(扁平結構、頁面布局技巧)，增加數據及展示的流暢流程及穩定性(技術) 2、 更小的頁面空間(由於瀏覽器的導航本身佔用一部分屏幕空間)，更大的信息記憶負擔 移動設備的屏幕要小得多。這種如同透過門縫進行的閱讀增加了認知的負擔。人腦的短期記憶是不穩定的，用戶在滾動屏幕的過程中需要臨時記憶的信息越多，他們的表現就會越差。——《貼心設計：打造高可用性的移動產品》 思考點：排版更清晰、信息更簡練 (可在原生APP基礎上去掉一些豐富、復雜的視覺表現) 3、 導航不明顯，原有底部導航消失，有效的導航遇到挑戰 思考點：如何有效的提供導航?有哪些形式? 4、 交互動態效果收到限制，影響一些頁面場景、邏輯的理解。 思考點：比如登錄注冊流程的彈出、完成及異常退出，做好文字提示。 針對以上困境，解決方法總結如下： 首先，從APP到WAP版，在產品上，最明顯且核心的： 1、 精簡功能，只將核心的任務實現，非核心的枝節可考慮刪減。 2、 做好新的Web App導航. 3、 補充從Web App 對 下載原生APP 的引導。 一、常見的幾種Web APP導航樣式 1.1頂部底部導航的設計： 1.2導航快捷鍵設計： 美團：頂部欄固定位置 淘寶：懸浮圓圈–可的按鈕 優酷：非首屏時頁面右側懸浮 二、有效的導航設計 1、 基本的快捷導航中包括 返回常用頁面(如 首頁 我的 等)的快捷方式 2、 出現深層架構時 及時補充返回重要層級頁面的快捷方式 3、 情境式導航，方便用戶快捷跳轉到ta想去的頁面，如購買結束時提供查看訂單詳情的按鈕。 PS：Web APP更加需要畫頁面跳轉的流程圖，摸清各個頁面的入口，尤其是頁面返回的流程;有些簡化的返回按鈕，可以特殊註明返回到的頁面 在哪裡出現引導？ 一般首頁、核心任務的頁面(如 電商Web APP的商品詳情頁 、視頻Web APP的視頻觀看頁) 二、引導下載APP有哪些形式? 頁面頂部放置下載條 頁面底部懸浮層引導 融合在頁面首屏中 下載按鈕形式 底部Foot里含客戶端下載入口 其次，在設計Web App時，有以下小技巧可以參考： 1、 從頁面布局上減少跳轉：使用交互技巧隱藏文字(eg 騰訊視頻) 利用收起按鈕 減少頁面跳轉。 2、 取消float浮層，增大展示空間(eg：大眾點評) 取消float浮層，同時在詳情尾部再次加上 “購買”按鈕。 浮層的轉換處理。 3、 頁面中對圖片進行縮小(因情況而異)的處理、精簡一些標簽導航的視覺展示。 視覺微調。 技術上注意點： 1)各手機瀏覽器的兼容測試 2)底層服務的調取(能調取，但只有當其是核心功能時才保留 eg：新浪、美團等皆去掉了頭像上傳功能) 3)注意離線數據存儲，減少數據請求頻率。 4)考慮保存用戶的哪些數據：設置、個人數據、閱讀錨點、跳出頁面等。 5)避免動效與瀏覽器的交互沖突 6)按順序 非同步載入 eg： 騰訊視頻 騰訊視頻非同步載入。 雖然Web App目前處於比較尷尬的地位，我們是由於原APP客戶端中一些頁面需要分享出去才開啟製作Web App版。 但是不得不承認，基於Web的輕APP 更新迭代起來更方便，隨著H5技術的成熟和發展，也許以後就是基於H5的Web App的天下了 0.0
『拾』 js怎麼跟Android和ios進行交互呢
Android和ios都是用語言編寫的app，那麼調用js的方法如下：
Native 調用 JS:
本質就一個方法,通過 ,都是同步。
1.通常方法：js修通過改doucument的loaction或者新建一個看不見的iFrame,修改它的 src,就會觸發回調 webView 的 shouldStartLoadWithRequest,參數 request 的 url 就是新賦值的 location 或者 url,上層截獲這個 url 的參數,對此分發即可。 這個都是非同步調用的。
如 JS function：
var messagingIframe;
messagingIframe = document.createElement('iframe');
messagingIframe.style.display = 'none';
document.documentElement.appendChild(messagingIframe);
function TestIOSJS(){
messagingIframe.src = "ios/test/click";
};
當觸發上面的JS時，webview會收到下面的回調：
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
NSString *url = request.URL.absoluteString;
if([url hasSuffix:@"ios/test/click"]){
//do something you want
return NO;
}
return YES;
}
通過截獲這個request的參數就可以做native需要做的事情。