iOS开发-------基于WKWebView的原生与JavaScript数据交互

WKWebView是iOS8.0之后用以替代UIWebView的网页浏览器,包含在WebKit中,可以通过 @import WebKit 导入。

如果工程需要适配iOS7,那么请在iOS7中使用UIWebView。

如果是iOS8.0以上,请果断的选择WKWebView吧,无论是从功能,加载速度还是性能上,它都是不二的选择。



毕业回公司有段时间了,与其说比较忙,不如说最近接触的东西有点小多,并且还是多数自己之前闻所未闻的,整个人就显得比较浮躁,所以就没有对见识到的东西进行整理,感觉挺对不住自己的,知错就改,之后会慢慢的将看到的、学到的比较好的东西进行整理,记录一下,希望能在帮助俺那不靠谱的记性同时,也能够帮助有同样困惑的小伙伴。

不过这里并不会非常具体的介绍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)



因为自己的Demo中的触发点在于导航栏中的Do按钮(开发中,这个触发点是由实际需求确定的):

//响应Do
@IBAction func doTap(sender: AnyObject)
{
    //调用的JS方法,执行
    let js = "callJavaScript()";
    webView.evaluateJavaScript(js) { (object, error) in
    }//与iOS8之前的UIWebView类似
}

It's OK? 总感觉还是还差一步的,既然有addXXX这句,是不是应该有removeXXX呢,还真有,也就差这么一步

deinit
{  
    //删除注入的JS
    webView.configuration.userContentController.removeAllUserScripts()
}



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的触发点>

最后看一下传值交互的效果,由客户端将字符串“RITL"传递给web,经由JS方法修改label标签的值:
<div align="center">

</img></div>


Web端 -> iOS客户端

这个传值方向是目前为止,我在项目中应用的比较广泛的一种,在WKWebView之前(UIWebView),想要获得JS中对客户端传的参数值,基本有方法有如下两种:

  1. web端通过重定向,将传递的参数拼接成自定义的格式,将参数作为url进行重新定向,客户端通过实现WebView的代理方法获取到重定向的url,通过解析字符串进而获得传出的参数(0.0 是不是觉得好low啊);

  2. 借助大神写好的第三方库,比如:JavaScriptWebView等完成WebView与JS间的传值。但这里也说一下自己的看法,这种情况多数是将WebView的代理以及控制权交给了三方中的某个管理类,能完成信息交互的同时也表示着我们失去了对WebView的信息交互控制权,个人觉得不是很爽。当然,除此之外还有什么办法呢T^T。

    相比UIWebView,WKWebView中就为我们提供了看起来更加高大上同时也让我们不失去对WebView控制权的交互方法,真所谓一举两得。

与第一种方向相同,同样操作webView的配置对象,在WKWebView的配置对象中对javaScript交互数据进行监听,方法如下:

//webView的配置对象对传出数据的名字进行监听,此时负责接收JS消息处理的对象不要忘记履行协议<WKScriptMessageHandler>
[self.webView.configuration.userContentController addScriptMessageHandler:self name:name];



<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..
    }
}

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;



预定javaScript处理结束了,也能完成各种交互动作,如果这个时候大家能想得到add必有remove的规则,我表示此时内心无比欣慰,突然感觉这篇博文真的没有白写,那么习惯性的在dealloc中进行监听注销吧:

/** 注销 */
[self.webView.configuration.userContentController removeScriptMessageHandlerForName:name];



<font size=15 color=orange >BUT!!!!!</font>


内存泄露

通常我们认为上面的做法已经很好的完成需求,如果是仔细或者对系统性能比较关注的开发者,相信肯定会在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

使用的时候转一下强引用对象就OK啦

//实例引用对象
CB_YZZBScriptMessageHandler * messageHandle = [CB_YZZBScriptMessageHandler scriptWithDelegate:self];

//注册JS信息处理
[self.webView.configuration.userContentController addScriptMessageHandler:messageHandle name:@"RITL"];


取消长按响应

- (void)webView:(WKWebView *)webView didFinishNavigation:(null_unspecified WKNavigation *)navigation
{
    //注入不响应的JS方法即可
    [webView evaluateJavaScript:@"document.documentElement.style.webkitTouchCallout='none';" completionHandler:^(id _Nullable result, NSError * _Nullable error) {}];
}
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,530评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,403评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,120评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,770评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,758评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,649评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,021评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,675评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,931评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,751评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,410评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,004评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,969评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,042评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,493评论 2 343

推荐阅读更多精彩内容

  • 跟原生开发相比,H5的开发相对来一个成熟的框架和团队来讲在开发速度和开发效率上有着比原生很大的优势,至少不用等待审...
    大冲哥阅读 1,827评论 0 7
  • 前言 关于UIWebView的介绍,相信看过上文的小伙伴们,已经大概清楚了吧,如果有问题,欢迎提问。 本文是本系列...
    CoderLF阅读 8,943评论 2 12
  • 前言 关于UIWebView的介绍,相信看过上文的小伙伴们,已经大概清楚了吧,如果有问题,欢迎提问。 本文是本系列...
    Dark_Angel阅读 28,783评论 67 291
  • 1、加载网页 WKWebView *webView = [[WKWebView alloc] initWithFr...
    LearningCoding阅读 3,091评论 0 2
  • 我们经常会遇到一些孩子:他们不是那么努力地做事情,不求上进,觉得是为父母活着;他们也挺自私,不替别人考虑,只...
    方策家族阅读 184评论 2 1