iOS WKWebView学习

iOS WKWebView学习

最佳答案 53678位专家为你答疑解惑

iOS WKWebView学习

WKWebView是iOS8.0出来的，用于替代UIWebView的，苹果建议iOS8.0之后使用WKWebView。官方文档示例代码如下：

import UIKitimport WebKitclass ViewController: UIViewController, WKUIDelegate {        var webView: WKWebView!        override func loadView() {        let webConfiguration=WKWebViewConfiguration()        webView=WKWebView(frame: .zero, configuration: webConfiguration)        webView.uiDelegate=self        view=webView    }    override func viewDidLoad() {        super.viewDidLoad()                let myURL=URL(string:"https://www.apple.com")        let myRequest=URLRequest(url: myURL!)        webView.load(myRequest)    }}

使用非常简便，主要步骤为创建WKWebView对象，添加到View上，设置代理，创建请求对象，加载请求。WKWebView主要有两个代理，分别是navigationDelegate、UIDelegate。

@property(nonatomic, weak) id<WKNavigationDelegate> navigationDelegate;@property(nonatomic, weak) id<WKUIDelegate> UIDelegate;

WKNavigationDelegate代理协议如下：

//Initiating the Navigation//Called when the web view begins to receive web content.//开始接收web内容的时候调用该方法- (void)webView:(WKWebView *)webView didCommitNavigation:(WKNavigation *)navigation;//Called when web content begins to load in a web view.//webview开始加载web内容的时候调用该方法- (void)webView:(WKWebView *)webView didStartProvisionalNavigation:(WKNavigation *)navigation;//Responding to Server Actions//Called when the web view begins to receive web content.//开始接收web内容的时候调用该方法- (void)webView:(WKWebView *)webView didCommitNavigation:(WKNavigation *)navigation;//Called when a web view receives a server redirect.//当收到服务器重定向的时候调用该方法- (void)webView:(WKWebView *)webView didReceiveServerRedirectForProvisionalNavigation:(WKNavigation *)navigation;//Authentication Challenges//Called when the web view needs to respond to an authentication challenge.//当需要身份验证的时候调用该方法- (void)webView:(WKWebView *)webView didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential *credential))completionHandler;//Reacting to Errors//Called when an error occurs during navigation.//当导航过程中发生一个错误时调用该方法- (void)webView:(WKWebView *)webView didFailNavigation:(WKNavigation *)navigation withError:(NSError *)error;//Called when an error occurs while the web view is loading content.//当在加载内容的时候发生错误的时候会调用该方法- (void)webView:(WKWebView *)webView didFailProvisionalNavigation:(WKNavigation *)navigation withError:(NSError *)error;//Tracking Load Progress//Called when the navigation is complete.//当导航完成时调用该方法- (void)webView:(WKWebView *)webView didFinishNavigation:(WKNavigation *)navigation;//Called when the web view’s web content process is terminated.//当webview的内容加载程序终止时调用该方法- (void)webViewWebContentProcessDidTerminate:(WKWebView *)webView;//Permitting Navigation//Decides whether to allow or cancel a navigation.//决定是否允许或者取消跳转导航- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;//Decides whether to allow or cancel a navigation after its response is known.//在知道响应内容后决定是否允许或者取消跳转导航- (void)webView:(WKWebView *)webView decidePolicyForNavigationResponse:(WKNavigationResponse *)navigationResponse decisionHandler:(void (^)(WKNavigationResponsePolicy))decisionHandler;

更详细内容可以参考：https://www.jianshu.com/p/833448c30d70

跨平台桌面开发，Electron还是WebView2 （下篇）

好了，前面两篇铺垫了一些内容，这周终于进行这个话题的核心内容了，就是对于跨平台桌面来说，Electron与WebView2这两个非常类似的技术方案究竟哪个更合适？

后来者WebView2是否能取代Electron？

这是这个话题的最终篇，前两篇为：

跨平台桌面开发，Electron还是WebView2 （上篇）跨平台桌面开发，Electron还是WebView2 （中篇））

接下来，我会分别从这两个技术的相似之处以及不同之处来详细对比说明，这样大家就有一个比较系统性的了解了。

文末最后会给出我的观点。

相似之处

都是Chrome内核 + 前端技术的解决方案

无论是Electron还是WebView2，最大的相似之处在于它们都是基于Chrome内核+前端技术结合提供的解决方案。（严格的说，WebView2是基于Edge内核，但我们都知道Edge内核只是Chrome内核的fork版本而已）

这意味着你可以用你熟悉的React或是Vue，语言上可以选择JavaScript或TypeScript，构建工具上选择WebPack或Vite等，这一切都允许你自由搭配，随心所欲。

通过前端技术就能实现一个跨平台的桌面应用程序，在性价比上再无其它技术可比了。

当然，这种方式做出来的程序一定是有范围限制的，类似游戏或一些对性能要求非常高的当然不能用这样的解决方案。

性能差别不大

由于几乎都是一个模子搞出来的东西，都用的Chrome内核去解释JS来运行程序，理所当然的，这两个技术在性能上差别并不大。

所以，如果你期望新的WebView2在性能上更好，超越它的前辈Electron，这一点上可能会令你失望了。

相似的进程模型

由于都是源自于Chrome内核，所以它们的进程模型也是类似的。

这也是Chrome浏览器的进程模型。

一个应用是由一个Main Process与多个Render Process合作完成。Render Process负责渲染展现页面，而Main Process则负责初始化应用程序，应用窗体等。

而Render Process之间如果需要通信，则是通过Main Process中介来完成的。

直观点说，你在Chrome浏览器打开了很多个tab页，每个tab页就是一个Render Process，而Chrome本身还有个Main Process，负责初始化与管理各个tab等。

当然，它们都还有一个help process进程，负责处理一些额外的工作。

都是跨平台的（未来）

好吧，Electron是跨平台的，基本上，只要支持Chrome浏览器+NodeJS语言的系统，那Electron做出来的应用都能正常运行。

WebView2由于机制和Electron非常类似，也可以跨平台。

但这是未来，因为当下的WebView2只支持Windows，但是微软承诺未来会支持MacOS和Linux。

但是对于微软这么一个Windows的厂商，它的这个承诺多久能实现，我个人还是觉得有待观察的。

也许大家会很奇怪，为什么WebView2还没有真正跨平台，只是号称。不都是Chrome内核+前端技术的方案要么，不是天然支持的么。

这就是说到它们的不同之外了，因为它们与原生API打交道的语言并不一样。

都要自己负责应用的更新

无论是Electron或是WebView2，更新应用程序都是程序自己来负责的。

不同之处

Eelectron是一个整体单一的解决方案，WebView2是一个混合解决方案

我认为这是最大的不同之处。

Eelectron是一个独立的，整体的，单一的解决方案。

什么意思，就是你不需要其它框架，语言搭配来完成一个桌面应用程序开始。仅仅是前端技术就能完整的开发一个桌面应用。不管是页面上的React，TypeScript或是与原生系统打交道的NodeJS，它们通通是前端技术。

这意味着一个前端团队能够在不依赖其它团队的前提下，基于Electron开发一个完整的桌面应用。

但WebView2则并不是如此。

WebView2这个词可能后端开发人员听起来没有太多感觉，但只要是移动端或前端人员，一听就会知道这是个什么东西。

严格的来说，WebView2是一个组件或叫控件。无论是移动端，还是桌面原生开发中，都有非常多的组件或控件，比如按钮，图片或是网页，对吧。

iOS中有UIWebView以及WKWebView来负责展现网页，而Android中也有WebView来负责展现网页内容，是不是很相似。

当然的啊，因为WebView2是Windows原生开发中的一个组件，它的作用与iOS中的WKWebView或是Android的WebView是一样的，它都只是一个组件。当然，它是一个远比按钮图片要复杂的组件。

而且WebView2这名字还有个数字2，这个一想都知道，它是过往的WebView的改进版本，升级版本或替代版本。

组件或控件有个什么问题，就是它不能独立存在，你有听说过WKWebView能开发出一个iOS应用么？组件或控件一定是依赖于某种原生应用壳而存在的。

所以，WebView2的最大问题在于：

WebView2不是一个独立的，完整的，单一的解决方案，它依赖于另一个壳的应用程序而存在，在现在，可选的就是Win32 C/C++，WinUI 2.0/3.0，.NET 4.5/5/6等

看到没，都是Windows下原生开发的一些框架技术。

这意味着什么，意味着仅凭一个前端团队，是没法利用WebView2开发出一个独立的应用程序，还需要一个原生开发团队配合着来做一个壳的应用。

这和移动开发中的混合开发Hibrid模式是不是非常相似。

构建方式不同

Electron只支持一种构建方式，就是将Chrome内核一起打进你的最终程序中。所以，因为这一点它有一个问题，就是安装包非常大。当然，优势是你使用的一定是特定的Chrome版本，不会有版本混乱问题。

而WebView2则支持两种方式，一种是和Electron一样，将内核打进包中，另一个是共享系统的内核。

而从Windows 11开始，系统中就默认有一个这样的浏览器内核在系统中，如果你选用这种共享模式，则你的应用安装体积会非常小。

不过，在今天，安装包体积大似乎不是个非常值得看重的点。

与原生系统打交道的方式不同

Electron是通过NodeJS来与原生打交道，比如读写系统文件等。

NodeJS本来就是前端技术的后端框架，它是与Java可以相提并论的，当然能调用原生各种API。

而WebView2则是通过壳的语言来与原生API打交道，比如如果你用的Win32，那可能就是C或C++吧。

至于Windows上的原生语言是不是比NodeJS更快，这个的确是有可能的。但这个也不会相差太多了。

支持平台不同

好了，有点打脸了，前面才说都是跨平台的。

但就当下来说，支持平台并不一样。

Electron当下是实打实的跨平台方案，支持Windows,MacOS,Linux各种操作系统。

而WebView2当下只支持Windows，当然，微软承诺未来会加入对MacOS，Linux的支持。

未来，明白不，一年也是未来，十年也是未来，什么时候真正支持了再说吧。

Render Process安全沙盒机制不同

Render Process的安全沙盒机制是指在Render Process中能不能调用原生API做一些操作。如果能，这肯定不太安全。不能，这表明它是限制在沙盒中运行的。

Electron是支持两种不同的沙盒机制，一种是Render Prcoess不限制，可以通过NodeJS任意与原生API打交道，另一个是限制Render Process只能渲染展现网页，不能和原生系统打交道。

而WebView2只有一种模式，就是限制Render Process在沙盒中运行。

当然，这也是Chrome浏览器的模式，Chrome在渲染网页时，肯定网页是没办法和原生系统打交道的，这个做前端的都应该非常清楚。这样非常安全。

从这一点上来说，Electron似乎更灵活。

开源 VS 不开源

Electron是开源的框架与技术，源代码在github上能访问到。

而WebView2做为微软的东西，当下并没有开源，也找不到源代码。未来微软会不会开源，这个我也不知道，没有看到微软有这方面的任何承诺。

Electron还是WebView2

现在你应该非常清楚Electron和WebView2的相同及不同之处了吧。

那对于跨平台桌面开发，如果你想找到一个性价比非常之高的解决方案，是Electron还是WebView2，心中应该有自己的答案了吧。

如果你问我，我的观点就是：

Electron仍然是当下及未来一段时间内，跨平台桌面开发性价比最高的选择WebView2则是Windows原生程序开发团队或开发者应该关注的技术，基于它能做出类似移动端的Hibrid混合应用WebView2当下并不适合跨平台开发，因为它压根还没真正支持其它平台。而对于前端团队或开发人员来说，Electron仍然是他们为数不多的选择之一。有多少前端程序员还懂Win32开发？对于大多数公司来说，选用Electron的成本明显少于WebView2，因为这是一个团队还是两个团队配合开发的不同。（大公司，有钱，土豪请自觉将自己排除在外）

远方以及更远

当然，我在这篇文章中，主要还是围绕前端开发技术下的跨平台桌面开发。

而说到跨平台桌面开发，除了基于前端技术的这些解决方案之外，我们似乎还可以把目光放的更长远。

一些还没有成熟，但非常具有潜力的新技术已经崭露头角了。

React Native已经某种程度上支持Windows以及MacOS开发Flutter已经发布了对Windows的稳定版本支持，未来会加入对其它平台的支持Jetpack Compose基于Skia引擎的跨平台桌面开发还在也在持续完善中kotlin multiplatform除了支持移动跨平台以外，对桌面跨平台的支持也是未来的方向。

虽然这些技术最初都是着眼于移动端的跨平台开发，但它们也都是在孵化或开发对桌面跨平台的支持，而它们的解决方案与基于前端技术的解决方案又都有着自己独特的优势与不同。

你想知道它们又有何不同么，你可以持续关注我及我的微言码道，未来我会再来聊一些这些技术。

此话题以此为终。