New Feature for WKWebView in iOS14
导览
- 更灵活的JS控制
- 解决native与web命名空间冲突
- 更灵活的JS参数传递
- web与native双向通讯
- 更好的渲染方式
- 多个新api
更灵活的JS控制
WKWebView中, 使用javaScriptEnabled可以disable所有webview试图去加载的js文件, 但是因为native很多时候其实都需要通过EvaluateJavaScript来进行数据交互. 直接禁用javaScriptEnabled实际上是非常粗粒度的行为. 因此这个属性将会被抛弃
取而代之的新属性allowsContentJavaScript, 使用这个属性可以禁用内联的JS, url方式加载的远端js, 以及本地路径的js文件, 但是native直接执行的js仍然有效
在decidePolicy代理方法中使用WKWebpagePreferences, 更可以对每个web页面进行更细致的配置, 来决定当前web页面是否加载js
以下图代码为例, 针对特定的url, 将allowContentJavaScript设为false, 可以使web页面更为灵活, 例如在某些特定的页面, 你只希望获得html的布局能力, 然后点击交互网络请求等细节交由native接管, 这样可以使页面加载更为迅速
解决native与web命名空间冲突
如上图所示, 例如native执行了js后将window.commentDetails设为null, 这样会导致js内的同名函数直接被置空, 这种native与web的命名空间冲突问题非常难以察觉, 甚至有恶意的web应用会故意覆盖同名函数来达到改变应用行为或者获取用户信息的能力.
要彻底解决, 就需要将native的js运行环境跟web的js运行环境进行隔离, 因此native需要一个自己的global object, WKContentWorld就是为此而生的
如上图所示, 使用方式是在native执行js的api里, 加上.defaultClient的参数
更灵活的JS参数传递
例如我们希望在native侧构建一个完整的dom节点并插入到html时, 我们需要hardcode很多js中数据结构的代码
例如下图中的maring: "0", 这里的0在native的其他地方其实是Int类型, 但因为让这段js代码能转string从而让webview调用, 因此需要hardcore成"0"
为了解决这个问题, 苹果引入了callAsyncJavaScript api
如上图, 在执行这段js时, 这段js的scope内使用到的变量, 可以直接通过arguments这个参数进行传递, 并且可以直接使用swift的字典数据类型
上图是一个更神奇的妙用
在这段js中return了一个promise对象, 因此native的completion会等待这个promise被resolve了, 才会执行, 并且可以在native获取到fetch成功后的数据
web与native双向通讯
New Feature for WKWebView in iOS14
导览
- 更灵活的JS控制
- 解决native与web命名空间冲突
- 更灵活的JS参数传递
- web与native双向通讯
- 更好的渲染方式
- 多个新api
更灵活的JS控制
WKWebView中, 使用javaScriptEnabled可以disable所有webview试图去加载的js文件, 但是因为native很多时候其实都需要通过EvaluateJavaScript来进行数据交互. 直接禁用javaScriptEnabled实际上是非常粗粒度的行为. 因此这个属性将会被抛弃
取而代之的新属性allowsContentJavaScript, 使用这个属性可以禁用内联的JS, url方式加载的远端js, 以及本地路径的js文件, 但是native直接执行的js仍然有效
在decidePolicy代理方法中使用WKWebpagePreferences, 更可以对每个web页面进行更细致的配置, 来决定当前web页面是否加载js
以下图代码为例, 针对特定的url, 将allowContentJavaScript设为false, 可以使web页面更为灵活, 例如在某些特定的页面, 你只希望获得html的布局能力, 然后点击交互网络请求等细节交由native接管, 这样可以使页面加载更为迅速
解决native与web命名空间冲突
如上图所示, 例如native执行了js后将window.commentDetails设为null, 这样会导致js内的同名函数直接被置空, 这种native与web的命名空间冲突问题非常难以察觉, 甚至有恶意的web应用会故意覆盖同名函数来达到改变应用行为或者获取用户信息的能力.
要彻底解决, 就需要将native的js运行环境跟web的js运行环境进行隔离, 因此native需要一个自己的global object, WKContentWorld就是为此而生的
如上图所示, 使用方式是在native执行js的api里, 加上.defaultClient的参数
更灵活的JS参数传递
例如我们希望在native侧构建一个完整的dom节点并插入到html时, 我们需要hardcode很多js中数据结构的代码
例如下图中的maring: "0", 这里的0在native的其他地方其实是Int类型, 但因为让这段js代码能转string从而让webview调用, 因此需要hardcore成"0"
为了解决这个问题, 苹果引入了callAsyncJavaScript api
如上图, 在执行这段js时, 这段js的scope内使用到的变量, 可以直接通过arguments这个参数进行传递, 并且可以直接使用swift的字典数据类型
上图是一个更神奇的妙用
在这段js中return了一个promise对象, 因此native的completion会等待这个promise被resolve了, 才会执行, 并且可以在native获取到fetch成功后的数据
web与native双向通讯
New Feature for WKWebView in iOS14
导览
- 更灵活的JS控制
- 解决native与web命名空间冲突
- 更灵活的JS参数传递
- web与native双向通讯
- 更好的渲染方式
- 多个新api
更灵活的JS控制
WKWebView中, 使用javaScriptEnabled可以disable所有webview试图去加载的js文件, 但是因为native很多时候其实都需要通过EvaluateJavaScript来进行数据交互. 直接禁用javaScriptEnabled实际上是非常粗粒度的行为. 因此这个属性将会被抛弃
取而代之的新属性allowsContentJavaScript, 使用这个属性可以禁用内联的JS, url方式加载的远端js, 以及本地路径的js文件, 但是native直接执行的js仍然有效
在decidePolicy代理方法中使用WKWebpagePreferences, 更可以对每个web页面进行更细致的配置, 来决定当前web页面是否加载js
以下图代码为例, 针对特定的url, 将allowContentJavaScript设为false, 可以使web页面更为灵活, 例如在某些特定的页面, 你只希望获得html的布局能力, 然后点击交互网络请求等细节交由native接管, 这样可以使页面加载更为迅速
解决native与web命名空间冲突
如上图所示, 例如native执行了js后将window.commentDetails设为null, 这样会导致js内的同名函数直接被置空, 这种native与web的命名空间冲突问题非常难以察觉, 甚至有恶意的web应用会故意覆盖同名函数来达到改变应用行为或者获取用户信息的能力.
要彻底解决, 就需要将native的js运行环境跟web的js运行环境进行隔离, 因此native需要一个自己的global object, WKContentWorld就是为此而生的
如上图所示, 使用方式是在native执行js的api里, 加上.defaultClient的参数
更灵活的JS参数传递
例如我们希望在native侧构建一个完整的dom节点并插入到html时, 我们需要hardcode很多js中数据结构的代码
例如下图中的maring: "0", 这里的0在native的其他地方其实是Int类型, 但因为让这段js代码能转string从而让webview调用, 因此需要hardcore成"0"
为了解决这个问题, 苹果引入了callAsyncJavaScript api
如上图, 在执行这段js时, 这段js的scope内使用到的变量, 可以直接通过arguments这个参数进行传递, 并且可以直接使用swift的字典数据类型
上图是一个更神奇的妙用
在这段js中return了一个promise对象, 因此native的completion会等待这个promise被resolve了, 才会执行, 并且可以在native获取到fetch成功后的数据
web与native双向通讯
