iOS之WebKit源码调试与解析

前言

从目前移动互联网发展来看，网页依旧信息传递重要媒介，这为webKit发展做了基垫。在 iOS 平台下开发者们需要通过 WKWebView 框架来与 WebKit 打交道。下面列举一些其它的优势：
* 更多的支持HTML5的特性
* 官方宣称的高达60fps的滚动刷新率以及内置手势
* Safari相同的JavaScript引擎
* 将UIWebViewDelegate与UIWebView拆分成了14类与3个协议(官方文档说明)
* 另外用的比较多的，增加加载进度属性： estimatedProgress

心得体会

虽然苹果官方提供了关于 WKWebView 的 API 与使用说明，但这并不能满足开发者们的需求，各类复杂场景依旧让我们焦头烂额，而解决方案却不易寻找。此时，优秀的开发者们将目光移向苹果开源的 WebKit 内核代码，试图从中寻找解惑之道，却发现依旧困难重重，坎坷不断，主要问题如下：
1.内核源码复杂难懂：动辄几个 G 的源码，且缺乏关键代码注释与说明，跟踪分析工作量大；系统兼容分支较多，一块代码可能区分 iOS、Mac、嵌入式等分支；历史代码或实验功能较多，导致查看源码并不容易缕清逻辑。
2.无法结合业务代码分析：异常问题往往在复杂场景下才会出现，缺乏业务代码的结合，问题无法复现，我们也就无法定位问题，最终容易走上猜测原因、更换方案尝试修复的路子。

我们看下WKWebview一些常规用到的代理方法：

// --------------- WKNavigationDelegate -----------------
// 请求之间，决定是否跳转网页：一般用户在点击一个链接时跳转到下一个页面之间会调用这个方法
// 重点的代理方法，拦截webView 中url的方法
- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler;

// 获取响应数据之后，决定是否跳转
- (void)webView:(WKWebView *)webView decidePolicyForNavigationResponse:(WKNavigationResponse *)navigationResponse decisionHandler:(void (^)(WKNavigationResponsePolicy))decisionHandler;

// 开始加载页面时调用
- (void)webView:(WKWebView *)webView didStartProvisionalNavigation:(null_unspecified WKNavigation *)navigation;

// 主机地址被重定向时调用
- (void)webView:(WKWebView *)webView didReceiveServerRedirectForProvisionalNavigation:(null_unspecified WKNavigation *)navigation;

// 页面加载失败时调用
- (void)webView:(WKWebView *)webView didFailProvisionalNavigation:(null_unspecified WKNavigation *)navigation withError:(NSError *)error;

// 页面加载完毕时调用
- (void)webView:(WKWebView *)webView didFinishNavigation:(null_unspecified WKNavigation *)navigation;

// 跳转失败时调用
- (void)webView:(WKWebView *)webView didFinishNavigation:(null_unspecified WKNavigation *)navigation;

// 证书验证步骤：如果需要证书验证，与使用AFN进行HTTPS证书验证是一样的
- (void)webView:(WKWebView *)webView didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * _Nullable credential))completionHandler;

//  ------- WKUIDelegate方面一个比较重要的代理 ---------------
// 在webview中使用alert函数时，需要执行这个代理，否则将无法打开
// 坏处在于，需要我们硬性执行代理方法，好处在于，可以在我们原生iOS这边自定义弹出框
- (void)webView:(WKWebView *)webView runJavaScriptAlertPanelWithMessage:(NSString *)message initiatedByFrame:(WKFrameInfo *)frame completionHandler:(void (^)(void))completionHandler

最基础的iOS和js之间的通信方式，在WKWebview这边主要的方法：
- (void)evaluateJavaScript:(NSString *)javaScriptString completionHandler:(void (^ _Nullable)(_Nullable id, NSError * _Nullable error))completionHandler;

这里我们和UIWebview中执行通信代码的方法比较一下：

- (nullable NSString *)stringByEvaluatingJavaScriptFromString:(NSString *)script;

可以看到，WKWebview这边的通信方法相对而言比较的人性化，因为iOS传递给js代码之后，得到的结果不一定是NSString类型，在很多情况下我们会需要得到一个对象、数组等等数据。

WebKit探索之路

接下来，我们将按照源码下载、源码编译、创建调试工程、源码实战分析的步骤助力你深入浏览内核探索之路。
1.源码下载
github： https://github.com/WebKit/WebKit

官网：https://WebKit.org/
下载后的 WebKit 工程通过 Xcode（ Xcode 是苹果官方推荐的 iOS 应用开发工具）打开后目录如下图。

WebKit工程目录

其中gtest / MiniBrowser / MobblieMiniBrowser / TestWebKitAPI / WebKitTestRunner仓库为测试仓库。考虑到编译效率的问题，通常情况下不需要编译测试仓库。由于本文后面将描述如何有效利用这些测试仓库，我们此处选择进行全源码编译。

2.源码编译
获取到源码后，接下来我们介绍下命令行及 Xcode 的编译方式。

本文推荐先使用命令行编译一遍，再用 Xcode 编译。从实践来看，如果编译过程中出错，命令行编译方式更易追踪到具体异常信息。

Embedded Builds

下载的 WebKit 目录里面有一个Tools/Scripts 目录，这里面有各种脚本，包括使用命令行编译 WebKit 的脚本，其中一个重要的脚本就是 configure-Xcode-for-embedded-development，在 Mac 终端控制台运行如下命令:

sudo Tools/Scripts/configure-Xcode-for-embedded-development

之所以需要执行这个脚本，是因为 iOS 属于嵌入式平台，编译嵌入式平台的 WebKit 需要用到一些命令行工具，Xcode 正是利用该脚本构建这些命令行工具。否则，在编译诸如 JavaScriptCore 等工程的时候，就会报如下错误：‘com.apple.product-type.tool’, but there’s no such product type for the embedded platform，找不到对应的架构。

Xcode 编译，设置构建产物存储位置

选择 Xcode 的 File 菜单，选择Workspace Settings，然后打开 Workspace 设置窗口，如下图所示：

webkit

接下来我们选择 Advanced 按钮，打开如下窗口，按红框所示，将工程编译目录配置为 WebKitBuild，点击完成：

webkit

准备工作终于完成了，接下来开始编译了。

WebKit编译

首先选中 All Source 选项，配置 scheme 选择模拟器运行，然后点击 Xcode 的构建按钮开始构建。

WebKit编译

此处请耐心等待，首次编译耗时较长，本文测试是在 i5 处理器 8G 内存 Mac Pro 机器上测试的，测试全源码编译耗时1h。编译成功后会弹出 MiniBrowser 不可用 警告（属于 Mac 应用工程），我们忽视即可。此时内核编译工作结束，接下来我们继续进入下一步，创建调试工程，进行源码探索。

创建调试工程

本文按照两类调试需求进行区分介绍，分别使用官方Demo工程和自定义工程进行调试，具体如下所示。

使用官方Demo工程调试

编译完成后，在我们的工程产物 WebKitBuild 目录中会有一个 MobileMiniBrower APP。此时我们可以在工程 scheme 配置中选择 MobileMiniBrowser APP 进行工程构建，该 APP 是苹果官方的浏览器 Demo （如下图所示），可通过地址栏执行地址输入，前进/后退以及多 Tab 等功能，可在源码里进行断点测试。

webkit调试

使用自定义工程调试

我们需要按照如下步骤在工程中使用我们编译成功的 WebKit.framework 去替换系统的 WebKit.framework：
首先，用 Xcode 新建一个新的 Project，示例里面是 TestWKWebView，并将这个 Project 添加到 WebKit 的工程空间 WebKit.xcworkspace 中，编译产物按照 WebKit 编译所述，同样输出到 WebKitBuild 目录。
做好上面的设置之后，就可以编写测试程序，在测试程序中打上断点，这时你会发现系统 WebKit 库已经被替换，断点可跳转源码，即可愉快的进行源码探索了。

webkit调试

调试到这一步后，可以发现，WebKit 源码很庞大，哪怕代码 run 起来了，如何下断点分析问题依旧很难把控。因此我们需要进行一些知识点的补充与理解，本文将进入实战环节，用 Demo 工程进行分析说明，给大家提供源码分析的思路。

WebKit 的多进程机制

在 iOS 系统中，通常一个应用对应一个进程，但是在 WebKit 的发展过程中，基于稳定性与安全性考虑，引入了多进程的概念，避免单一页面的异常影响整体 app 运行，首先本文简单介绍下几个常见的 WebKit 进程,如下所示。

UIProcess —— 应用程序所在进程，WKWebView 代码和 WebKit 框架已加载到你的进程空间中；

WebContent —— 又称 WebProcess，JS 和 DOM 内存分配所在的位置，即网页内容渲染与 js 执行所处进程；

Network Process —— 负责发出与 Web 请求关联的基础网络请求；

Storage Process —— 用于数据库和服务工作者的存储。

我们先用两个 Demo 进行内核分析：

Demo1 —— 单 webview 模型：
我们在 Demo1 工程中简单使用一个 WKWebView 来进行网络加载，以百度首页为例，运行项目后，点击调试模式中的 show the debug navigator 选项，该功能是 debug 下的资源分析模块。
现在我们可以查看各进程的 CPU、内存、磁盘、网络使用情况，当然也可以进行 Instruments 分析。

webkit进程

webkit进程概述

Demo2 —— 多 webview 模型：
使用多个 WKWebView 进行网络加载，每加载一个网页，创建一个新的 WKWebView 实例。

webkit进程概述

webkit进程概述

结合以上Demo工程，我们可以有一个直观上的理解：

WebContent 进程对应的是每一个新开的网页，该进程视内存情况可进行复用，某一 WebContent 进程的异常并不会影响到主 app 进程，常见的异常现象为白屏。

UIProcess 进程为 app 所在进程，WKWebView 在该进程中提供了大量 API 供开发者与内核交互，也是开发者最熟悉的一部分。

NetWorking 进程，无论多 WKWebView 还是单 WKWebView 场景，都只有唯一的 NetWorking 进程，这种设计主要便于网络请求管理以及保证网络缓存、cookie 等管理的一致性。

苹果官方文档中描述：配置同一 WKProcessPool 的多个 WKWebView 共享同一 WebContent 进程，即可以配置 WebContent 进程唯一（ https://developer.apple.com/documentation/webkit/wkprocesspool ）。
但源码头文件中的注释与官方文档不一致，源码头文件描述配置同一 WKProcessPool 的多个 WKWebView 共享的是同一 WebContent 进程池，该配置未限制 WebContent 进程数量，而是共享进程池。从 Demo 实际测试看，官方文档描述并不准确，我们以源码注释为准。

有了上述理解，我们再去看 Xcode 下 WebKit 的文件目录，目录也按照进程职责进行了较为合理的划分。

webkit源码划分

因此，在调试过程中，除了根据已知关联 API 或代码堆栈进行全局搜索或单步断点调试外，我们还可以多结合三大进程的工作职责进行问题分析与查找。另外，既然可以查看各进程的 CPU、内存、磁盘、网络等状态了，对这方面有性能要求的，可以用来查看一个网页加载时各进程具体的资源消耗是多少。

TestWebKitAPI 工程

使用源码工程，除了代码分析外，苹果系统还提供了大量的系统 API 相关功能测试，这些测试基于 gtest 框架实现，集成在 TestWebKitAPI 工程里，实践中按照如下思路可利用 TestWebKitAPI 工程进行一些接口分析与测试：

了解各类 API（包括私有 API ）的测试用例，通过这类代码示范与说明，便于我们深入了解接口的使用规范，更好的理解 API 的设计思路。

利用该框架可进行 gtest 测试，gtest 是一个跨平台的 (Liunx、Mac OS X、Windows、Cygwin、Windows CE and Symbian) C++单元测试框架，由 google 公司发布，它能在不同平台上编写 C++ 测试代码。gtest 框架提供了丰富的断言、致命和非致命判断、参数化、”死亡测试”等。在 WebKit 内核源码中已有大量的基于gtest 框架的测试代码积累，当我们做了一些 trick 操作时，基于 TestWebKitAPI 工程做自动化测试，也是一种不错的选择。

Tips

WebKit 源码调试可能在一般情况下不会用到，但是对于 WebKit 复杂问题的分析与解决，结合业务对 WebKit 源码进行探索与分析，还是有一定意义的。

特殊场景下，开发者可能对一些 API 进行特殊使用，这个时候可断点调试的源码能更好帮助我们规避风险。

苹果官方禁止了在真机上替换 WebKit 内核，我们可以编译对应的真机库，但是无法进行安装调试，因此本文里的内容都是在模拟器进行的。

因webkit源码在不断更新，因此下载编译过程中可能会遇到一些不兼容问题，一般可通过注释相关不兼容代码解决。

结语
这篇文章详述 WebKit 内核关键技术分析，你也可以调试 WebKit 源码，或在运行 Web 应用程序时使用 Instruments 来分析 WebKit 进程。希望本文能带领你够更深入地了解使用 WKWebView 应用的堆栈细节。

青山不改，绿水长流，后会有期，感谢每一位佳人的支持！