UIWebView OC调用JS
1. stringByEvaluatingJavaScriptFromString:
最常用的方法，很简单，只要调用- (nullable NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script;就可以了，如：
|
1
|
self.navigationItem.title = [webView stringByEvaluatingJavaScriptFromString:@
"document.title"
];
|
虽然比较方便，但是缺点也有：
-
该方法不能判断调用了一个js方法之后，是否发生了错误。当错误发生时，返回值为nil，而当调用一个方法本身没有返回值时，返回值也为nil，所以无法判断是否调用成功了。
-
返回值类型为nullable NSString *，就意味着当调用的js方法有返回值时，都以字符串返回，不够灵活。当返回值是一个js的Array时，还需要解析字符串，比较麻烦。
对于上述缺点，可以通过使用JavaScriptCore（iOS 7.0 +）来解决。
2. JavaScriptCore（iOS 7.0 +）
想必大家不会陌生吧，前些日子弄的沸沸扬扬的JSPatch被禁事件中，最核心的就是它了。因为JavaScriptCore的JS到OC的映射，可以替换各种js方法成oc方法，所以其动态性（配合runtime的不安全性）也就成为了JSPatch被Apple禁掉的最主要原因。这里讲下UIWebView通过JavaScriptCore来实现OC->JS。
其实WebKit都有一个内嵌的js环境，一般我们在页面加载完成之后，获取js上下文，然后通过JSContext的evaluateScript:方法来获取返回值。因为该方法得到的是一个JSValue对象，所以支持JavaScript的Array、Number、String、对象等数据类型。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
- (void)webViewDidFinishLoad:(UIWebView *)webView
{
//更新标题，这是上面的讲过的方法
//self.navigationItem.title = [webView stringByEvaluatingJavaScriptFromString:@"document.title"];
//获取该UIWebView的javascript上下文
JSContext *jsContext = [self.webView valueForKeyPath:@
"documentView.webView.mainFrame.javaScriptContext"
];
//这也是一种获取标题的方法。
JSValue *value = [self.jsContext evaluateScript:@
"document.title"
];
//更新标题
self.navigationItem.title = value.toString;
}
|
该方法解决了stringByEvaluatingJavaScriptFromString:返回值只是NSString的问题。
那么如果我执行了一个不存在的方法，比如
|
1
|
[self.jsContext evaluateScript:@
"document.titlexxxx"
];
|
那么必然会报错，报错了，可以通过@property (copy) void(^exceptionHandler)(JSContext *context, JSValue *exception);，设置该block来获取异常。
|
1
2
3
4
5
6
|
//在调用前，设置异常回调
[self.jsContext setExceptionHandler:^(JSContext *context, JSValue *exception){
NSLog(@
"%@"
, exception);
}];
//执行方法
JSValue *value = [self.jsContext evaluateScript:@
"document.titlexxxx"
];
|
该方法，也很好的解决了stringByEvaluatingJavaScriptFromString:调用js方法后，出现错误却捕获不到的缺点。
UIWebView JS调用OC
1. Custom URL Scheme（拦截URL）
比如darkangel://。方法是在html或者js中，点击某个按钮触发事件时，跳转到自定义URL Scheme构成的链接，而Objective-C中捕获该链接，从中解析必要的参数，实现JS到OC的一次交互。比如页面中一个a标签，链接如下：
|
1
|
短信验证登录
|
而在Objective-C中，只要遵循了UIWebViewDelegate协议，那么每次打开一个链接之前，都会触发方法
|
1
|
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType；
|
在该方法中，捕获该链接，并且返回NO（阻止本次跳转），从而执行对应的OC方法。
|
1
2
3
4
5
6
7
8
9
10
11
12
|
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
//标准的URL包含scheme、host、port、path、query、fragment等
NSURL *URL = request.URL;
if
([URL.scheme isEqualToString:@
"darkangel"
]) {
if
([URL.host isEqualToString:@
"smsLogin"
]) {
NSLog(@
"短信验证码登录，参数为 %@"
, URL.query);
return
NO;
}
}
return
YES;
}
|
当用户点击短信验证登录时，控制台会输出短信验证码登录，参数为 username=12323123&code=892845。参数可以是一个json格式并且URLEncode过的字符串，这样就可以实现复杂参数的传递（比如WebViewJavascriptBridge）。
优点：泛用性强，可以配合h5实现页面动态化。比如页面中一个活动链接到活动详情页，当native尚未开发完毕时，链接可以是一个h5链接，等到native开发完毕时，可以通过该方法跳转到native页面，实现页面动态化。且该方案适用于Android和iOS，泛用性很强。
缺点：无法直接获取本次交互的返回值，比较适合单向传参，且不关心回调的情景，比如h5页面跳转到native页面等。
其实，WebViewJavascriptBridge使用的方案就是拦截URL，为了解决无法直接获取返回值的缺点，它采用了将一个名为callback的function作为参数，通过一些封装，传递到OC（js->oc 传递参数和callbackId），然后在OC端执行完毕，再通过block来回调callback（oc->js，传递返回值参数），实现异步获取返回值，比如在js端调用
|
1
2
3
4
5
|
//JS调用OC的分享方法（当然需要OC提前注册）share为方法名，shareData为参数，后面的为回调function
WebViewJavascriptBridge.callHandler(
'share'
, shareData,
function
(response) {
//OC端通过block回调分享成功或者失败的结果
alert(response);
});
|
具体的可以看下它的源码，还是很值得学习的。
2. JavaScriptCore（iOS 7.0 +）
除了拦截URL的方法，还可以利用上面提到的JavaScriptCore。它十分强大，强大在哪里呢？下面我们来一探究竟。
当然，还是需要在页面加载完成时，先获取js上下文。获取到之后，我们就可以进行强大的方法映射了。
比如js中我定义了一个分享的方法
|
1
2
3
|
function
share(title, imgUrl, link) {
//这里需要OC实现
}
|
在OC中实现如下
|
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
|
- (void)webViewDidFinishLoad:(UIWebView *)webView
{
//将js的function映射到OC的方法
[self convertJSFunctionsToOCMethods];
}
- (void)convertJSFunctionsToOCMethods
{
//获取该UIWebview的javascript上下文
//self持有jsContext
//@property (nonatomic, strong) JSContext *jsContext;
self.jsContext = [self.webView valueForKeyPath:@
"documentView.webView.mainFrame.javaScriptContext"
];
//js调用oc
//其中share就是js的方法名称，赋给是一个block 里面是oc代码
//此方法最终将打印出所有接收到的参数，js参数是不固定的
self.jsContext[@
"share"
] = ^() {
NSArray *args = [JSContext currentArguments];
//获取到share里的所有参数
//args中的元素是JSValue，需要转成OC的对象
NSMutableArray *messages = [NSMutableArray array];
for
(JSValue *obj
in
args) {
[messages addObject:[obj toObject]];
}
NSLog(@
"点击分享js传回的参数：\n%@"
, messages);
};
}
|
在html或者js的某处，点击a标签调用这个share方法，并传参，如
上面的代码实现了OC方法替换JS实现。它十分灵活，主要依赖这些Api。
|
1
2
3
4
5
6
7
8
9
10
11
12
|
@interface JSContext (SubscriptSupport)
/*!
@method
@abstract Get a particular property on the global object.
@result The JSValue for the global object's property.
*/
- (JSValue *)objectForKeyedSubscript:(id)key;
/*!
@method
@abstract Set a particular property on the global object.
*/
- (void)setObject:(id)object forKeyedSubscript:(NSObject*)key;
|
self.jsContext[@"yourMethodName"] = your block;这样写不仅可以在有yourMethodName方法时替换该JS方法为OC实现，还会在该方法没有时，添加方法。简而言之，有则替换，无则添加。
那如果我想写一个有两个参数，一个返回值的js方法，oc应该怎么替换呢？
js中
|
1
2
3
4
5
6
7
|
//该方法传入两个整数，求和，并返回结果
function
testAddMethod(a, b) {
//需要OC实现a+b，并返回
return
a + b;
}
//js调用
console.log(testAddMethod(1, 5));
//output 6
|
oc直接替换该方法
|
1
2
3
|
self.jsContext[@
"testAddMethod"
] = ^NSInteger(NSInteger a, NSInteger b) {
return
a + b;
};
|
那么当在js调用
|
1
2
|
//js调用
console.log(testAddMethod(1, 5));
//output 6， 方法为 a + b
|
如果oc替换该方法为两数相乘
|
1
2
3
|
self.jsContext[@
"testAddMethod"
] = ^NSInteger(NSInteger a, NSInteger b) {
return
a * b;
};
|
再次调用js
|
1
|
console.log(testAddMethod(1, 5));
//output 5，该方法变为了 a * b。
|
举一反三，调用方法原实现，并且在原结果上乘以10。
//调用方法的本来实现，给原结果乘以10
|
1
2
3
4
5
|
JSValue *value = self.jsContext[@
"testAddMethod"
];
self.jsContext[@
"testAddMethod"
] = ^NSInteger(NSInteger a, NSInteger b) {
JSValue *resultValue = [value callWithArguments:[JSContext currentArguments]];
return
resultValue.toInt32 * 10;
};
|
再次调用js
|
1
|
console.log(testAddMethod(1, 5));
//output 60，该方法变为了(a + b) * 10
|
上面的方法，都是同步函数，如果我想实现JS调用OC的方法，并且异步接收回调，那么该怎么做呢？比如h5中有一个分享按钮，用户点击之后，调用native分享（微信分享、微博分享等），在native分享成功或者失败时，回调h5页面，告诉其分享结果，h5页面刷新对应的UI，显示分享成功或者失败。
这个问题，需要对js有一定了解。下面上js代码。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
//声明
function
share(shareData) {
var
title = shareData.title;
var
imgUrl = shareData.imgUrl;
var
link = shareData.link;
var
result = shareData.result;
//do something
//这里模拟异步操作
setTimeout(
function
(){
//2s之后，回调true分享成功
result(
true
);
}, 2000);
}
//调用的时候需要这么写
share({
title:
"title"
,
link: location.href,
result:
function
(res) {
//函数作为参数
console.log(res ?
"success"
:
"failure"
);
}
});
|
从封装的角度上讲，js的share方法的参数是一个对象，该对象包含了几个必要的字段，以及一个回调函数，这个回调函数有点像oc的block，调用者把一个function传入一个function当作参数，在适当时候，方法内实现者调用该function，实现对调用者的异步回调。那么如果此时OC来实现share方法，该怎么做呢？其实大概是这样的：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
//异步回调
self.jsContext[@
"share"
] = ^(JSValue *shareData) {
//首先这里要注意，回调的参数不能直接写NSDictionary类型，为何呢？
//仔细看，打印出的确实是一个NSDictionary，但是result字段对应的不是block而是一个NSDictionary
NSLog(@
"%@"
, [shareData toObject]);
//获取shareData对象的result属性，这个JSValue对应的其实是一个javascript的function。
JSValue *resultFunction = [shareData valueForProperty:@
"result"
];
//回调block，将js的function转换为OC的block
void (^result)(BOOL) = ^(BOOL isSuccess) {
[resultFunction callWithArguments:@[@(isSuccess)]];
};
//模拟异步回调
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(3 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
NSLog(@
"回调分享成功"
);
result(YES);
});
};
|
其中一些坑，已经在代码的注释写的比较清楚了，这里要注意JavaScript的function和Objective-C的block的转换。
从上面的一些探讨和尝试来看，足以证明JavaScriptCore的强大，这里不再展开，小伙伴们可以自行探索。
UIWebView的Cookie管理
Cookie简介
说到Cookie，或许有些小伙伴会比较陌生，有些小伙伴会比较熟悉。如果项目中，所有页面都是纯原生来实现的话，一般Cookie这个东西或许我们永远也不会接触到。但是，这里还是要说一下Cookie，因为它真的很重要，由它产生的一些坑也很多。
Cookie在Web利用的最多的地方，是用来记录各种状态。比如你在Safari中打开百度，然后登陆自己的账号，之后打开所有百度相关的页面，都会是登陆状态，而且当你关了电脑，下次开机再次打开Safari打开百度，会发现还是登陆状态，其实这个就利用了Cookie。Cookie中记录了你百度账号的一些信息、有效期等，也维持了跨域请求时登录状态的统计性。
可以看到Cookie的域各不相同，有效期也各不相同，一般.baidu.com这样的域的Cookie就是为了跨域时，可以维持一些状态。
那么在App中，Cookie最常用的就是维持登录状态了。一般Native端都有自己的一套完整登录注册逻辑，一般大部分页面都是原生实现的。当然，也会有一些页面是h5来实现的，虽然h5页面在App中通过WebView加载或多或少都会有点性能问题，感觉不流畅或者体验不好，但是它的灵活性是Native App无法比拟的。那么由此，便产生了一种需求，当Native端用户是登录状态的，打开一个h5页面，h5也要维持用户的登录状态。
这个需求看似简单，如何实现呢？一般的解决方案是Native保存登录状态的Cookie，在打开h5页面中，把Cookie添加上，以此来维持登录状态。其实坑还是有很多的，比如用户登录或者退出了，h5页面的登录状态也变了，需要刷新，什么时候刷新？WKWebView中Cookie丢失问题？这里简单说下UIWebView的Cookie管理，后面的章节再介绍WKWebView。
Cookie管理
UIWebView的Cookie管理很简单，一般不需要我们手动操作Cookie，因为所有Cookie都会被[NSHTTPCookieStorage sharedHTTPCookieStorage]这个单例管理，而且UIWebView会自动同步CookieStorage中的Cookie，所以只要我们在Native端，正常登陆退出，h5在适当时候刷新，就可以正确的维持登录状态，不需要做多余的操作。
可能有一些情况下，我们需要在访问某个链接时，添加一个固定Cookie用来做区分，那么就可以通过header来实现
|
1
2
3
|
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:@
"http://www.baidu.com"
]];
[request addValue:@
"customCookieName=1314521;"
forHTTPHeaderField:@
"Set-Cookie"
];
[self.webView loadRequest:request];
|
也可以主动操作NSHTTPCookieStorage，添加一个自定义Cookie
|
1
2
3
4
5
6
7
|
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:@{
NSHTTPCookieName: @
"customCookieName"
,
NSHTTPCookieValue: @
"1314521"
,
NSHTTPCookieDomain: @
".baidu.com"
,
NSHTTPCookiePath: @
"/"
}];
[[NSHTTPCookieStorage sharedHTTPCookieStorage] setCookie:cookie];
//Cookie存在则覆盖，不存在添加
|
还有一些常用的方法，如读取所有Cookie
|
1
|
NSArray *cookies = [NSHTTPCookieStorage sharedHTTPCookieStorage].cookies;
|
Cookie转换成HTTPHeaderFields，并添加到request的header中
|
1
2
3
4
|
//Cookies数组转换为requestHeaderFields
NSDictionary *requestHeaderFields = [NSHTTPCookie requestHeaderFieldsWithCookies:cookies];
//设置请求头
request.allHTTPHeaderFields = requestHeaderFields;
|