WKWebView 相对webView来说加载网页来说速度不在一个层级，占用内存也比较少，在这里咱们不谈WK的加载网页使用问题，咱们来聊聊交互问题以及内存泄漏问题
交互：
1. 通过wk添加方法名
WKUserContentController *userCC =self.webView.configuration.userContentController;
[userCC addScriptMessageHandler:selfname:@"userLike"];
2 . WK在于H5交互的时候，手机端和后台需要统一方法名，后台通过js将需要的参数返回：
window.webkit.messageHandlers.userLike.postMessage(‘123456’) （后台操作）
userLike 统一的方法名（在下面的拦截方法中就是根据这个方法名进行的判断）
123456 所需要的参数
3. 实现代理方法, 通过方法名进行判断进行不同的交互操作
- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message{
if ([message.nameisEqualToString:@"userLike"]) {
// 用户点赞（再次进行需要的操作）
self.commentCid = message.body; // 获取需要的参数
}
}
到此为止，如果不出意外，交互已经实现，但此时delloc会发现，添加交互后出现了内存泄漏的问题，通过排查发现是第一步 添加方法名时出现循环引用，（猜测是添加时对self 进行了强引用，而wk又是self的属性），通过查看系统方法发现还有一个删除的方法：
定义如下
/*! @abstract Removes a script message handler.
@param name The name of the message handler to remove.
*/
- (void)removeScriptMessageHandlerForName:(NSString *)name;
4. 添加移除操作（既然不走delloc方法就在将要消失的时候删除），如下：
- (void)viewWillDisappear:(BOOL)animated
{
[superviewWillDisappear:animated];
WKUserContentController *userCC = self.webView.configuration.userContentController;
[userCC removeScriptMessageHandlerForName:@"userLike"];
}
此时发现内存泄漏问题解决，如果在第一步在添加的时候是在viewDidLoad中实现的，那么现在会出现一种情况：当从当前页面进入下一个页面在返回的时候，会发现所有的交互都已经失效，细心想一下就会知道，进入下一个页面时这个页面的所有的交互都已经被移除，而返回到当前页面时也没有添加交互，解决这个问题方法将添加的时候放在viewWillAppear中即可，这样反复添加、移除可能会造成性能的降低，如有好的方法请告知
注意点：
a. 交互方法名必须统一
b. 添加方法的位置，避免交互失效