實現(xiàn)思路
我的最終方案主要參考了豆瓣的rexxar和廣為大家使用的WebViewJavascriptBridge幔虏，之前也對后者有一點點研究旨怠。
源碼實現(xiàn)
代碼暫時沒有考慮開源性，結(jié)合了部分公司的業(yè)務(wù)和個性化配置镣典，不做提供了兔毙。
WKWebView一直有很多坑，而且蘋果也沒有要解決的意思兄春。在性能和需求兩者中澎剥，一定要權(quán)衡利弊，謹慎使用赶舆。
創(chuàng)建一個WKWebView哑姚，會配置一些基本信息，主要是WKWebViewConfiguration芜茵，其中比較關(guān)鍵的一個是userContentController叙量，它可以用于注入javascript腳本、處理native和web交互(本文后續(xù)都簡稱交互)等九串。
1）為什么要注入javascript绞佩？
其實直接用WKWebView也能完成交互≈砼ィ客戶端直接調(diào)用evaluateJavaScript: completionHandler:方法品山，web端先在userContentController中調(diào)用addScriptMessageHandler方法注冊xxx事件，然后就可以用window.webkit.messageHandlers.xxx.postMessage(JSON.stringify(json))方法調(diào)用客戶端的方法了烤低。（注意：xxx是要一一對應(yīng)的）
當然肘交，更好的推薦是使用WebViewJavascriptBridge，我們只要處理好注冊的事情就可以方便使用了扑馁，網(wǎng)上的教程也很多涯呻。
2）為什么不基于WebViewJavascriptBridge實現(xiàn)一個Hybrid容器？
最主要的目的：為了web端能用一份代碼實現(xiàn)與Android和iOS端的交互腻要。（本文只是一種思路）
3）實現(xiàn)思路是什么复罐？
- a.使用WKWebView提供的交互方法，而不是用攔截URL Scheme的方式
- b.將多個注冊事件統(tǒng)一為一個事件
第一點主要還是要結(jié)合Android端和iOS端的方案選擇雄家。我們的Android端不使用攔截方式市栗，所以我選擇了WKWebView的方法。
第二點是為了避免后期維護頻繁的添加新的事件。假如這個H5容器是一個開源庫填帽，隨著業(yè)務(wù)擴展擴展，交互的事件越來越多咙好。我們可以選擇把webView交付出去篡腌，讓用戶自身實現(xiàn)configuration的配置，注冊新的事件勾效；也可以選擇提供API嘹悼，讓用戶注冊新事件。但是层宫，感覺這樣都不夠方便杨伙。
能否讓用戶只是單純的實現(xiàn)自己的業(yè)務(wù)方法，而不要考慮注冊的事情萌腿？
最終限匣，采用的辦法是：只注冊一個事件，兩端的開發(fā)只需要商定交互的方法名毁菱，中間的事情都交給H5容器去做米死。具體的實現(xiàn)是：
- a.假設(shè)注冊了一個
InteractiveEvent - b.web端統(tǒng)一調(diào)用
window.webkit.messageHandlers.InteractiveEvent.postMessage(msg)方法，參數(shù)msg中包含了需要調(diào)用方法的函數(shù)名贮庞、數(shù)據(jù)峦筒、回調(diào)等 - c.客戶端拿到函數(shù)名，用
NSMethodSignature提供的API生成最終的函數(shù)簽名 - d.客戶端用一個哈希表存放了這些函數(shù)以及他們對應(yīng)的組件功能窗慎，如果匹配上了則調(diào)用響應(yīng)的功能物喷。
小結(jié)
第一版做的比較簡單，基本是照葫蘆畫瓢遮斥，大部分的時間都用在填WKWebView的坑了峦失，還好前人總結(jié)的非常全面。不過伏伐，新東西采坑是件好事宠进，收獲很多。
