Update date: 2021-7-17 不完整更新(待补充)
1.常规需求WKWebView简单封装 ✅
2.混合交互约定数据结构及标准 ✅
3.反射机制数据处理细节 ✅
4.WKWebView白屏问题
5.WKWebView相关ATS配置简述
6.重定向问题和url拦截
1.常规需求下简易封装
(1) 方案选择
考虑到对UIViewController
的侵入, 这里没有选择直接UIViewController
加extension
去实现WKWebView代码, 而是先实现一个加载WKWebView的基类BaseWKWebController
, 然后对需求的充分条件加以配置. 协议定义如下
1 | public protocol WKWebScriptMsgHandleAble: WKScriptMessageHandler { |
(2) 方法抽取
这里仅分离了本地和远端两种加载的情况, 当然可以考虑到更多的场景, 可以补充 缓存策略cachePolicy: NSURLRequest.CachePolicy
的设定, 以及超时等等.
1 | extension WKWebScriptMsgHandleAble { |
2.约定数据结构及标准
关于约定标识的问题, 先看下需要调用的监听方法
1 | public func addMethod(name: String) { |
再看下H5调用Native的方法
1 | // -> ios |
可以看到, 两端都要有同样的标识符; 不建议把 方法名当做标识符调用, 像
h5调用原生App的方法合集
1 | window.webkit.messageHandlers.ScanAction.postMessage(null); |
这种方式需要Native去多次设置监听, 而实质上把方法名放在postMessage里面一并给出, 由Native解析也能区分调用.
3.反射机制的数据处理
在标识符约定后, 方法及参数内容由postMessage传到Navite, 那么在解析message.body
后, 是一定得判断字符串再去区分调用吗?
答案是: 不一定, 这里引入iOS的反射调用机制, 代码如下
1 | override public func userContentController(_ userContentController: WKUserContentController, didReceive message: WKScriptMessage) { |
这里注意几个调用细节:
(1).注意执行方法有3个
1 | func perform(_ aSelector: Selector!) -> Unmanaged<AnyObject>! |
(2).那么方法名如何对应呢?
1 | // 对应方法名: "test" |
<未完待续>
- 本文作者: 醉疏狂
- 本文链接: https://hubin97.github.io/2021/07/17/混合开发梳理/
- 版权声明: 本博客所有文章除特别声明外,均采用 MIT 许可协议。转载请注明出处!