https://blog.csdn.net/runintolove/article/details/52064268
WKWebView是iOS8.0之后用以替代UIWebView的网页浏览器,包含在WebKit中,可以通过 @import WebKit 导入。
如果工程需要适配iOS7,那么请在iOS7中使用UIWebView。
如果是iOS8.0以上,请果断的选择WKWebView吧,无论是从功能,加载速度还是性能上,它都是不二的选择。
- 1
- 2
- 3
- 4
- 5
毕业回公司有段时间了,与其说比较忙,不如说最近接触的东西有点小多,并且还是多数自己之前闻所未闻的,整个人就显得比较浮躁,所以就没有对见识到的东西进行整理,感觉挺对不住自己的,知错就改,之后会慢慢的将看到的、学到的比较好的东西进行整理,记录一下,希望能在帮助俺那不靠谱的记性同时,也能够帮助有同样困惑的小伙伴。
不过这里并不会非常具体的介绍WKWebView如何使用以及各种协议对象是什么作用,毕竟Google一下就会有很多介绍WKWebView的文章,并且他们都写得很好很详细,大家感兴趣的可以Google一下。给大家推荐一个WKWebView的新特性与使用
这里记录的交互仅仅的是进行一些数据的交互,对于其他的UI交互以及响应交互,请查看一下上面推荐的博文,写的真的很详细;如果大家有更好的交互方式,也麻烦大家告知一下3Q
iOS客户端 -> Web端
言归正传,我们用WKWebView加载一个HTML文件(加载网络网页其实是一个道理的),万一进行某个操作的时候需要原生给web传递一个数据(至于什么数据,需要根据具体的需求来确定),这里就以一个字符串进行举例:
在需要与Web进行复杂交互的时候,通常都需要在实例化WKWebView
的之前,先实例化一个WKWebView
的配置对象(WKWebViewConfiguration
类型),对javaScript的注入第一步就是需要处理一下这个配置对象:
//初始化webView的配置对象
let configuration = WKWebViewConfiguration()
//比如这就是需要传递给web的参数
let name = "RITL"
//声明一个WKUserScript对象
let script:WKUserScript = WKUserScript(source: "function callJavaScript() {ObjCToJavaScript('(name)');}", injectionTime: .AtDocumentStart, forMainFrameOnly: true)
//对Script对象进行添加
configuration.userContentController.addUserScript(script)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
因为自己的Demo中的触发点在于导航栏中的Do按钮(开发中,这个触发点是由实际需求确定的):
//响应Do
@IBAction func doTap(sender: AnyObject)
{
//调用的JS方法,执行
let js = "callJavaScript()";
webView.evaluateJavaScript(js) { (object, error) in
}//与iOS8之前的UIWebView类似
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
It’s OK? 总感觉还是还差一步的,既然有addXXX
这句,是不是应该有removeXXX
呢,还真有,也就差这么一步
deinit
{
//删除注入的JS
webView.configuration.userContentController.removeAllUserScripts()
}
- 1
- 2
- 3
- 4
- 5
Demo的HTML语句比较low,但仅仅的就是为了测试,所以就忍了吧0.0
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>我是HTML标题</title>
</head>
<script>
//原生调用该方法,并通过接收传入的参数进行下一步操作
function ObjCToJavaScript(name)
{
//修改label显示的title
document.getElementById("Text").innerText = name;
}
</script>
<body>
<label id ="Text" style = "margin-top: 100px ; display: block; font-size:100px;">Text</label>
</body>
</html>
<!-- 总结一下,其实从上面的描述也就看出来了,所谓的原生对JS进行传值的实质说白了就是修改了响应JS的触发点>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
最后看一下传值交互的效果,由客户端将字符串“RITL"
传递给web,经由JS方法修改label标签的值:
Web端 -> iOS客户端
这个传值方向是目前为止,我在项目中应用的比较广泛的一种,在WKWebView
之前(UIWebView
),想要获得JS中对客户端传的参数值,基本有方法有如下两种:
-
web端通过重定向,将传递的参数拼接成自定义的格式,将参数作为url进行重新定向,客户端通过实现WebView的代理方法获取到重定向的url,通过解析字符串进而获得传出的参数(0.0 是不是觉得好low啊);
-
借助大神写好的第三方库,比如:JavaScriptWebView等完成WebView与JS间的传值。但这里也说一下自己的看法,这种情况多数是将WebView的代理以及控制权交给了三方中的某个管理类,能完成信息交互的同时也表示着我们失去了对WebView的信息交互控制权,个人觉得不是很爽。当然,除此之外还有什么办法呢T^T。
相比UIWebView,WKWebView中就为我们提供了看起来更加高大上同时也让我们不失去对WebView控制权的交互方法,真所谓一举两得。
- 1
与第一种方向相同,同样操作webView的配置对象,在WKWebView的配置对象中对javaScript交互数据进行监听,方法如下:
//webView的配置对象对传出数据的名字进行监听,此时负责接收JS消息处理的对象不要忘记履行协议<WKScriptMessageHandler>
[self.webView.configuration.userContentController addScriptMessageHandler:self name:name];
- 1
- 2
<WKScriptMessageHandler>
协议也比较给力,只有一个协议方法:
#pragma mark - <WKScriptMessageHandler>
//通过接收JS传出消息的name进行捕捉的回调方法
- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message
{
if([message.name isEqualToString:name])//此处name为JS传出信息打包的标志<name>
{
//用message.body获得JS传出的参数体
//handle coding..
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
Web端在需要客户端配合的时候通过如下代码进行触发:
/* 一个抽象模型 */
window.webkit.messageHandlers.
<name>.postMessage(<messageBody>)
/* 具体实例 */
/*JS的传出语句如下,那么name = "RITL"*/
window.webKit.messagehandlers.RITL.postMessage("RITL-GOGOGO")
/*外部要想获得上面的信息则进行如下监听*/
[self.webView.configuration.userContentController addScriptMessageHandler:self name:@"RITL"];
/*获得传出的字符串参数,即"RITL-GOGOGO"*/
NSString * dataString = message.body;
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
预定javaScript处理结束了,也能完成各种交互动作,如果这个时候大家能想得到add必有remove的规则
,我表示此时内心无比欣慰,突然感觉这篇博文真的没有白写,那么习惯性的在dealloc
中进行监听注销吧:
/** 注销 */
[self.webView.configuration.userContentController removeScriptMessageHandlerForName:name];
- 1
- 2
BUT!!!!!
内存泄露
通常我们认为上面的做法已经很好的完成需求,如果是仔细或者对系统性能比较关注的开发者,相信肯定会在dealloc中打一个断点来求证一下,那么这个时候我们就会发现,Dealloc根本不走!没错,根本不走!
PS: (这一点让我想起来之前项目中NSTimer造成的内存泄露问题,跟上面的问题简直是异曲同工之理(额,原理可能不一样,但效果是一样的,就是当前的控制器不会释放,被强引用了,So? 自然也不会走dealloc方法))。
难不成-addScriptMessageHandler:name:
个方法会对Handler进行强引用?要不换成__weak
吧? No!!!! NSTimer造成内存泄露的时候换成归零弱引用好使么,不好使吧!那么解决方法就和解决NSTimer的方法类似了。
通过转移代理对象(额,其实就是引用对象)来完成强引用的转移,从而让当前控制器得以释放,进而remove掉messagehandler, 完成对转移代理对象释放,将内存泄露堵住:
下面是我解决响应方法的一个实现类:
/*CB_YZZBScriptMessageHandler.h*/
#import <Foundation/Foundation.h>
@import WebKit;
NS_ASSUME_NONNULL_BEGIN
@interface CB_YZZBScriptMessageHandler : NSObject<WKScriptMessageHandler>
@property (nullable, nonatomic, weak)id <WKScriptMessageHandler> delegate;
/** 创建方法 */
- (instancetype)initWithDelegate:(id <WKScriptMessageHandler>)delegate;
/** 便利构造器 */
+ (instancetype)scriptWithDelegate:(id <WKScriptMessageHandler>)delegate;;
@end
NS_ASSUME_NONNULL_END
/*CB_YZZBScriptMessageHandler.m*/
@implementation CB_YZZBScriptMessageHandler
-(instancetype)initWithDelegate:(id<WKScriptMessageHandler>)delegate
{
if (self = [super init])
{
_delegate = delegate;
}
return self;
}
+(instancetype)scriptWithDelegate:(id<WKScriptMessageHandler>)delegate
{
return [[CB_YZZBScriptMessageHandler alloc]initWithDelegate:delegate];
}
#pragma mark - <WKScriptMessageHandler>
- (void)userContentController:(WKUserContentController *)userContentController didReceiveScriptMessage:(WKScriptMessage *)message
{
[self.delegate userContentController:userContentController didReceiveScriptMessage:message];
}
@end
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
使用的时候转一下强引用对象就OK啦
//实例引用对象
CB_YZZBScriptMessageHandler * messageHandle = [CB_YZZBScriptMessageHandler scriptWithDelegate:self];
//注册JS信息处理
[self.webView.configuration.userContentController addScriptMessageHandler:messageHandle name:@"RITL"];
- 1
- 2
- 3
- 4
- 5
取消长按响应
- (void)webView:(WKWebView *)webView didFinishNavigation:(null_unspecified WKNavigation *)navigation
{
//注入不响应的JS方法即可
[webView evaluateJavaScript:@"document.documentElement.style.webkitTouchCallout='none';" completionHandler:^(id _Nullable result, NSError * _Nullable error) {}];
}