深入理解 WKWebView (渲染篇) —— DOM 树的构建

全文12003字，预计阅读时间24分钟

当客户端 App 主进程创建 WKWebView 对象时，会创建另外两个子进程:渲染进程与网络进程。主进程 WKWebView 发起请求时，先将请求转发给渲染进程，渲染进程再转发给网络进程，网络进程请求服务器。如果请求的是一个网页，网络进程会将服务器的响应数据 HTML 文件字符流吐给渲染进程。渲染进程拿到 HTML 文件字符流，首先要进行解析，将 HTML 文件字符流转换成 DOM 树，然后在 DOM 树的基础上，进行渲染操作，也就是布局、绘制。最后渲染进程通知主进程 WKWebView 创建对应的 View 展现视图。整个流程如下图所示:

一、什么是DOM树

渲染进程获取到 HTML 文件字符流，会将HTML文件字符流转换成 DOM 树。下图中左侧是一个 HTML 文件，右边就是转换而成的 DOM 树。

可以看到 DOM 树的根节点是 HTMLDocument，代表整个文档。根节点下面的子节点与 HTML 文件中的标签是一一对应的，比如 HTML 中的 标签就对应 DOM 树中的 head 节点。同时 HTML 文件中的文本，也成为 DOM 树中的一个节点，比如文本 ‘Hello, World!’，在 DOM 树中就成为div节点的子节点。

在 DOM 树中每一个节点都是具有一定方法与属性的对象，这些对象由对应的类创建出来。比如 HTMLDocument 节点，它对应的类是 class HTMLDocument，下面是 HTMLDocument 的部分源码:

class HTMLDocument : public Document { // 继承自 Document
   ...
WEBCORE_EXPORT int width();
WEBCORE_EXPORT int height();
    ...
 }

从源码中可以看到，HTMLDocument 继承自类 Document，Document 类的部分源码如下:

class Document
    : public ContainerNode  // Document继承自 ContainerNode，ContainerNode继承自Node
    , public TreeScope
    , public ScriptExecutionContext
    , public FontSelectorClient
    , public FrameDestructionObserver
    , public Supplementable
    , public Logger::Observer
    , public CanvasObserver {
      WEBCORE_EXPORT ExceptionOr> createElementForBindings(const AtomString& tagName);  // 创建Element的方法
      WEBCORE_EXPORT Ref createTextNode(const String& data); // 创建文本节点的方法
      WEBCORE_EXPORT Ref createComment(const String& data); // 创建注释的方法
      WEBCORE_EXPORT Ref createElement(const QualifiedName&, bool createdByParser); // 创建Element方法
      ....
     }

上面源码可以看到 Document 继承自 Node，而且还可以看到前端十分熟悉的 createElement、createTextNode 等方法，JavaScript 对这些方法的调用，最后都转换为对应 C++ 方法的调用。

类 Document 有这些方法，并不是没有原因的，而是 W3C 组织给出的标准规定的，这个标准就是 DOM(Document Object Model，文档对象模型)。DOM 定义了 DOM 树中每个节点需要实现的接口和属性，下面是 HTMLDocument、Document、HTMLDivElement 的部分 IDL(Interactive Data Language，接口描述语言，与具体平台和语言无关)描述，完整的 IDL 可以参看 W3C 。

在 DOM 树中，每一个节点都继承自类 Node，同时 Node 还有一个子类 Element，有的节点直接继承自类 Node，比如文本节点，而有的节点继承自类 Element，比如 div 节点。因此针对上面图中的 DOM 树，执行下面的 JavaScript 语句返回的结果是不一样的:

document.childNodes; // 返回子Node集合，返回DocumentType与HTML节点，都继承自Node
document.children; // 返回子Element集合，只返回HTML节点，DocumentType不继承自Element

下图给出部分节点的继承关系图:

二、DOM树构建

DOM 树的构建流程可以分为4个步骤: 解码、分词、创建节点、添加节点。

2.1 解码

渲染进程从网络进程接收过来的是 HTML 字节流，而下一步分词是以字符为单位进行的。由于各种编码规范的存在，比如 ISO-8859-1、UTF-8 等，一个字符常常可能对应一个或者多个编码后的字节，解码的目的就是将 HTML 字节流转换成 HTML 字符流，或者换句话说，就是将原始的 HTML 字节流转换成字符串。

2.1.1 解码类图

从类图上看，类 HTMLDocumentParser 处于解码的核心位置，由这个类调用解码器将 HTML 字节流解码成字符流，存储到类 HTMLInputStream 中。

2.1.2 解码流程

整个解码流程当中，最关健的是如何找到正确的编码方式。只有找到了正确的编码方式，才能使用对应的解码器进行解码。解码发生的地方如下面源代码所示，这个方法在上图第3个栈帧被调用:

// HTMLDocumentParser是DecodedDataDocumentParser的子类
void DecodedDataDocumentParser::appendBytes(DocumentWriter& writer, const uint8_t* data, size_t length)
{
if (!length)
return;

    String decoded = writer.decoder().decode(data, length); // 真正解码发生在这里
if (decoded.isEmpty())
return;

    writer.reportDataReceived();
    append(decoded.releaseImpl());
}

上面代码第7行 writer.decoder() 返回一个 TextResourceDecoder 对象，解码操作由 TextResourceDecoder::decode 方法完成。下面逐步查看 TextResourceDecoder::decode 方法的源码:

// 只保留了最重要的部分
String TextResourceDecoder::decode(const char* data, size_t length)
{
    ...

    // 如果是HTML文件，就从head标签中寻找字符集
     if ((m_contentType == HTML || m_contentType == XML) && !m_checkedForHeadCharset) // HTML and XML
         if (!checkForHeadCharset(data, length, movedDataToBuffer))
             return emptyString();
             
      ...

     // m_encoding存储者从HTML文件中找到的编码名称
     if (!m_codec)
         m_codec = newTextCodec(m_encoding);  // 创建具体的编码器

     ...

    // 解码并返回
    String result = m_codec->decode(m_buffer.data() + lengthOfBOM, m_buffer.size() - lengthOfBOM, false, m_contentType == XML && !m_useLenientXMLDecoding, m_sawError);
     m_buffer.clear(); // 清空存储的原始未解码的HTML字节流
     return result;
}

从源码中可以看到，TextResourceDecoder 首先从 HTML 的 标签中去找编码方式，因为 标签可以包含 标签， 标签可以设置 HTML 文件的字符集:

如果能找到对应的字符集，TextResourceDeocder 将其存储在成员变量 m_encoding 当中，并且根据对应的编码创建真正的解码器存储在成员变量 m_codec 中，最终使用 m_codec 对字节流进行解码，并且返回解码后的字符串。如果带有字符集的 标签没有找到，TextResourceDeocder 的 m_encoding 有默认值 windows-1252(等同于ISO-8859-1)。

下面看一下 TextResourceDecoder 寻找 标签中字符集的流程，也就是上面源码中第8行对 checkForHeadCharset 函数的调用:

// 只保留了关健代码
bool TextResourceDecoder::checkForHeadCharset(const char* data, size_t len, bool& movedDataToBuffer)
{
    ...

// This is not completely efficient, since the function might go
// through the HTML head several times.

size_t oldSize = m_buffer.size();
    m_buffer.grow(oldSize + len);
memcpy(m_buffer.data() + oldSize, data, len); // 将字节流数据拷贝到自己的缓存m_buffer里面

    movedDataToBuffer = true;

// Continue with checking for an HTML meta tag if we were already doing so.
if (m_charsetParser)
return checkForMetaCharset(data, len);  // 如果已经存在了meta标签解析器，直接开始解析

     ....

    m_charsetParser = makeUnique(); // 创建meta标签解析器
return checkForMetaCharset(data, len);
}

上面源代码中第11行，类 TextResourceDecoder 内部存储了需要解码的 HTML 字节流，这一步骤很重要，后面会讲到。先看第17行、21行、22行，这3行主要是使用标签解析器解析字符集，使用了懒加载的方式。下面看下 checkForMetaCharset 这个函数的实现:

bool TextResourceDecoder::checkForMetaCharset(const char* data, size_t length)
{
if (!m_charsetParser->checkForMetaCharset(data, length))  // 解析meta标签字符集
return false;

    setEncoding(m_charsetParser->encoding(), EncodingFromMetaTag); // 找到后设置字符编码名称
    m_charsetParser = nullptr;
    m_checkedForHeadCharset = true;
return true;
}

上面源码第3行可以看到，整个解析 标签的任务在类 HTMLMetaCharsetParser::checkForMetaCharset 中完成。

// 只保留了关健代码
bool HTMLMetaCharsetParser::checkForMetaCharset(const char* data, size_t length)
{
if (m_doneChecking) // 标志位，避免重复解析
return true;


// We still don't have an encoding, and are in the head.
    // The following tags are allowed in :
// SCRIPT|STYLE|META|LINK|OBJECT|TITLE|BASE
//
// We stop scanning when a tag that is not permitted in 
// is seen, rather when  is seen, because that more closely
// matches behavior in other browsers; more details in
// .
//
// Additionally, we ignore things that looks like tags in