实现思路
我的最终方案主要参考了豆瓣的rexxar和广为大家使用的WebViewJavascriptBridge，之前也对后者有一点点研究。
源码实现
代码暂时没有考虑开源性，结合了部分公司的业务和个性化配置，不做提供了。
WKWebView一直有很多坑，而且苹果也没有要解决的意思。在性能和需求两者中，一定要权衡利弊，谨慎使用。
创建一个WKWebView，会配置一些基本信息，主要是WKWebViewConfiguration，其中比较关键的一个是userContentController，它可以用于注入javascript脚本、处理native和web交互(本文后续都简称交互)等。
1）为什么要注入javascript？
其实直接用WKWebView也能完成交互。客户端直接调用evaluateJavaScript: completionHandler:方法，web端先在userContentController中调用addScriptMessageHandler方法注册xxx事件，然后就可以用window.webkit.messageHandlers.xxx.postMessage(JSON.stringify(json))方法调用客户端的方法了。（注意：xxx是要一一对应的）
当然，更好的推荐是使用WebViewJavascriptBridge，我们只要处理好注册的事情就可以方便使用了，网上的教程也很多。
2）为什么不基于WebViewJavascriptBridge实现一个Hybrid容器？
最主要的目的：为了web端能用一份代码实现与Android和iOS端的交互。（本文只是一种思路）
3）实现思路是什么？
- a.使用WKWebView提供的交互方法，而不是用拦截URL Scheme的方式
- b.将多个注册事件统一为一个事件
第一点主要还是要结合Android端和iOS端的方案选择。我们的Android端不使用拦截方式，所以我选择了WKWebView的方法。
第二点是为了避免后期维护频繁的添加新的事件。假如这个H5容器是一个开源库，随着业务扩展扩展，交互的事件越来越多。我们可以选择把webView交付出去，让用户自身实现configuration的配置，注册新的事件；也可以选择提供API，让用户注册新事件。但是，感觉这样都不够方便。
能否让用户只是单纯的实现自己的业务方法，而不要考虑注册的事情？
最终，采用的办法是：只注册一个事件，两端的开发只需要商定交互的方法名，中间的事情都交给H5容器去做。具体的实现是：
- a.假设注册了一个
InteractiveEvent - b.web端统一调用
window.webkit.messageHandlers.InteractiveEvent.postMessage(msg)方法，参数msg中包含了需要调用方法的函数名、数据、回调等 - c.客户端拿到函数名，用
NSMethodSignature提供的API生成最终的函数签名 - d.客户端用一个哈希表存放了这些函数以及他们对应的组件功能，如果匹配上了则调用响应的功能。
小结
第一版做的比较简单，基本是照葫芦画瓢，大部分的时间都用在填WKWebView的坑了，还好前人总结的非常全面。不过，新东西采坑是件好事，收获很多。
网友评论