[WebKit]WebKit2多进程机制的解析

红太狼 2022-03-29 15:24 325阅读 0赞

在<<[WebKit模块化分析][WebKit]>>中说到WebKit2中的多进程模型。多进程模型已经是浏览器的基本架构要素，下面展开分析一下WebKit2中的多进程模型。

协作决定接口，确立责任分工后，对于模块或系统间最重要的事莫过于接口定义，而且是有着简洁明确的定义。对于WebKit2中三个进程中的交互也是相当频繁和多样，如果使用传统的查表法对应解析执行，就会面临巨大的维护成本。WebKit2使用了Encoder和Decoder的概念的很好地将消息解析的工作放到各个功能上。于是提供的公共接口主要关注于消息的分发，而不再是似乎拥有一切的解析执行功能。

WebKit2在多进程接口上Process Launcher、CoreIPC以及WorkQueue构成了核心控制功能 (进程本身的Run Loop自然也是，但非此处的关注点)，Encoder/Decoder/FunctionWrapper则是重要的工具类。下面就是对它们进行的学习和分析。

## **多线程模型的基本架构** ##

先从基本结构看起。多进程模型是在WebKit中实现的，由WebKit中的三个Process分别处理应用主进程，网页处理进程及插件进程。

它们在具体的实现上是基于Process Launcher(WebKit2/UIProcess/Launcher)进行进程管理，再通过Core IPC进行跨进程通讯(IPC)。

![1361803614_5019.png][]

CoreIPC做为一个公共，且由各个进程共享的模块，日后会被放置到WebCore或WTF中。放在WTF中较为合适，因为它在模块化的角色就是公共功能模块。

Process Launcher具体创建进程的代码需要平台适配，它使用了如下的方式:

![1361803630_9794.png][]

ProcessLauncher.h和ProcessLauncher.cpp有通用的定义和公共代码的实现。再为不同平台建立不同的单元文件来实现平台差异的部分。负责创建新进程的launchProcess就在其中。

Core IPC也是类似的实现方式。在不同的平台下使用不同的IPC技术。

![1361803654_8335.png][]

Mach Port是Mac OS下类似pipes技术的实现，而XPC则是新推出一种更为安全的IPC技术，目前国内相关的中文资料并不多，还是要花时研究官方文档([Creating XPC Services][])和示例代码([SandboxedFetch][])。[另外网友rainbird还推荐一个对XPC的封装][rainbird_XPC]。

## **多进程模型的交互机制** ##

WebKit2中使用来Proxy来与其它进程进行通讯。

![1361803700_1530.png][]

WebProcessProxy与PluginProcessProxy均会继承自ProcessLauncher::Client, 最后是通过CoreIPC::Connection来完成通讯。因为存在页面上的对应关系，所以消息传递时都会带一个Page ID来标识，这样在共享Web Process时就不会出现混淆的问题。

下图是一个进程通讯的架构, CoreIPC::Connection会通过与其它几个类一起完成进程间消息传递:

![1361892330_8605.png][]

流程也很容易理解，消息发送者通过Encoder对要发送的信息进行编码，再由Work Queue控制触发发送或接收操作，最后由Decoder进行解码，最后交由目标类解析执行。

消息发送者Sender Class会继承自CoreIPC::MessageSender,而接收者Target Class会继承自CoreIPC::MessageReceiver。

Encoder的实现与平台无关。 Work Queue自己会有队列管理机制触发发送操作，再由注册回调函数触发接收操作。无论发送和接收的函数都是由Connection通Function Wrapper提供的，Work Queue就是负责在适当的时机下触发。它在不同平台使用了不同的技术:

![1361803742_4845.png][]

关于GCD可以参考一下这篇文章:

[GCD介绍][GCD]

Windows下的Thread Pool的说明可以看这里:

[Thread Pool API(MSDN)][Thread Pool API_MSDN]

下面Work Queue的类图:

![1361803777_1168.png][]

>   
> 
> 
> .dispatch用于发送时，由Connection调用并传入负责发送的函数句柄。
> 
> .executeFunction则是用于执行指定的函数指针。
> 
> .invalidate则是用于清除当前排入的任务队列。
> 
> .platformXXX表示的是对应于各个平台的不同实现。其跨平台模式类似于ProcessLauncher。
> 
> .registerXXX与unregisterXXX用于注册和取消处理接收到新消息的回调函数，这个函数也是由Connection指定的( Mac OS下和Windows下的函数名不同)。

下面是Connection与WorkQueue交互示意的序列图:

![1361803806_2424.png][]

## **多进程模型中消息数据设计** ##

上面提到了消息在传递过程中外发的消息(outgoing message)和收到的消息(incoming message)都由CoreIPC::Connection类来管理，而且包含

一个编解码的过程。

### 1. 消息 ###

每一个消息都有一个特定的定义。如下所示，Arguement1和Argument2是两个模板。

![1361803916_3306.png][]

首先CoreIPC为不同数量参数的消息定义了一套模板,就是ArgumentX, X从1到8，就是最大表示8个参数的消息，模板数据类型指定的是各个参数的类型。

其中一部分使用了修饰模式。不同参数的模板都采用对前一个模板的实现来达到复用的目的。 这种定义方式和一般的查表法是不同的，目的在于消息本身就能表示自己，而不需要再做额外的对消息的映射。

下面是LoadURL消息的定义:

struct LoadURL : CoreIPC::Arguments2<constWTF::String&, constWebKit::SandboxExtension::Handle&> \{

static const Kind messageID = LoadURLID;

static CoreIPC::StringReference receiverName() \{ return messageReceiverName(); \}

staticCoreIPC::**StringReference** name() \{ returnCoreIPC::**StringReference**("LoadURL"); \}

staticconstbool isSync = false;

typedefCoreIPC::Arguments2<constWTF::String&, constWebKit::SandboxExtension::Handle&> DecodeType;

LoadURL(const WTF::**String**& url, const WebKit::**SandboxExtension**::**Handle**& sandboxExtensionHandle)

: CoreIPC::Arguments2<const WTF::String&, const WebKit::SandboxExtension::Handle&>(url, sandboxExtensionHandle)

\};

### 2. Encoder ###

所谓Encoder就是信息的各个参数组装到一个buffer中的操作。

Encode操作都是通过CoreIPC::MessageEncoder来完成的。它对Message的Message Name, Receiver Name, Destination ID(即Page ID)以及各个参数进行编码。

![1361803997_9686.png][]

\*encode方法有不同类型的副本。

\*m\_inlineBuffer是字符数组，会比m\_buffer动态分配的方式效率要高。

下面Encode的结果(以loadURL为例):

![1361804016_5946.png][]

实际发送时就是将这个buffer的内容发送出去。再由接收到使用对应的Decoder解析出来。

![Image 1][]

![1361804077_1423.png][]

通过ReceiverName可以创建一个MessageReceiver对象，即此消息的处理对象。就这样，这个消息就确定应当由谁来处理了。

bool MessageReceiverMap::dispatchMessage(Connection\* connection, MessageID messageID, MessageDecoder& decoder)

if (MessageReceiver\* messageReceiver = m\_globalMessageReceivers.get(decoder.messageReceiverName())) \{

**ASSERT**(!decoder.**destinationID**());

messageReceiver->didReceiveMessage(connection, messageID, decoder);

return true;

……

和传统的处理方式相比，是不是简洁很多。虽然Recevier Names还是要有表存在，但相对常常的switch/case或查表法，它的变动性已经被极大的缩小了，也就降低了日后的维护成本。如果要接受消息处理，只要调用MessageReceiverMap::addMessageReceiver()添加一项Receiver，而参数就是Receiver的名称和类的实例。

再到具体的Message处理对象中处理，对于要接受消息处理的类，会继承自MessageReceiver，使得它们都有一个消息处理的入口。如:

void WebPage::didReceiveWebPageMessage(CoreIPC::Connection\*, CoreIPC::MessageID, CoreIPC::MessageDecoder& decoder)

……

if (decoder.messageName() == Messages::WebPage::LoadURL::name()) \{

CoreIPC::handleMessage<Messages::WebPage::LoadURL>(decoder, this, &WebPage::loadURL);

return;

……

最终通过 callMemberFunction()来执行消息对应的函数，即上面代码指定的this和&WebPage::loadURL，decoder中则存储着参数。

### 3. Function Wrapper ###

Function Wrapper的功能就是将函数或者某个对象的成员封装成函数指针。在Work Queue与Connection的函数调用过程都是使用Function Wrapper来完成的。

![1361804109_5028.png][]

Function Wrapper也是一个模板类，用于达到多态以支持不同的函数类型。比如下面支持类成员函数的定义(Functional.h):

template<typename R, typename C>

class FunctionWrapper<R (C::\*)()> \{

public:

typedef R ResultType;

static const bool shouldRefFirstParameter = HasRefAndDeref<C>::value;

static const bool shouldValidateFirstParameter = true;

explicit FunctionWrapper(R (C::\*function)())

: m\_function(function)

R operator()(C\* c)

return (c->\*m\_function)();

private:

R (C::\*m\_function)();

\};

Function Wrapper对Work Queue要封装就是Connection::sendOutgoingMessage和Connection:: dispatchOneMessage()两个分别用于处理发送和收到的消息。

## **多进程模型的交互序列图示例** ##

以下是一个交互的序列图，方便更好地理解它的设计。

在UI上加载页面时，UIProcess中的WebPageProxy向WebProcess中的WebPage发起loadURL请求。首先会通过调用Connection增加一个message到自己的outgoing message queue中。然后将自身的发送函数(sendOutgoingMessages)发送给WorkQueue对象执行，而不是直接把消息发送到WorkQueue中执行。所以WorkQueue只是一个控件类，而不是接口类。

![1361804228_6256.png][]

WorkQueue会在适当的时机执行提交的任务，由executeFunction来执行相应的发送函数，将消息通过系统的机制发送出去。

![1361804257_2588.png][]

而在WebProcess中，它会先在WorkQueue(不同的实例对象)中注册一个事件处理函数，当事件进来后，它就会被执行到。进行触发Connection对新的消息进行解析并加入到自己的incoming message queue中。

![1361804294_6145.png][]

Web Process会在自己的Run Loop中要求Connection解析收到的消息，并在解析后调用对应的对象的处理函数。通过callMemberFunction()就最终调用到了WebPage::loadURL()函数。

![1361804321_8593.png][]

转载请注明出处:http://blog.csdn.net/horkychen

[WebKit]: http://blog.csdn.net/horkychen/article/details/8462574
[1361803614_5019.png]: https://img-my.csdn.net/uploads/201302/25/1361803614_5019.png
[1361803630_9794.png]: https://img-my.csdn.net/uploads/201302/25/1361803630_9794.png
[1361803654_8335.png]: https://img-my.csdn.net/uploads/201302/25/1361803654_8335.png
[Creating XPC Services]: http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html
[SandboxedFetch]: http://developer.apple.com/library/mac/#samplecode/SandboxedFetch/Introduction/Intro.html
[rainbird_XPC]: http://blog.cnrainbird.com/index.php/2012/07/22/guan_yu_mac_app_zai_sandbox_xia_yun_xing_shi_de_xpc_service/
[1361803700_1530.png]: https://img-my.csdn.net/uploads/201302/25/1361803700_1530.png
[1361892330_8605.png]: https://img-my.csdn.net/uploads/201302/26/1361892330_8605.png
[1361803742_4845.png]: https://img-my.csdn.net/uploads/201302/25/1361803742_4845.png
[GCD]: http://blog.csdn.net/lvziru/article/details/7579997
[Thread Pool API_MSDN]: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686766%28v=vs.85%29.aspx
[1361803777_1168.png]: https://img-my.csdn.net/uploads/201302/25/1361803777_1168.png
[1361803806_2424.png]: https://img-my.csdn.net/uploads/201302/25/1361803806_2424.png
[1361803916_3306.png]: https://img-my.csdn.net/uploads/201302/25/1361803916_3306.png
[1361803997_9686.png]: https://img-my.csdn.net/uploads/201302/25/1361803997_9686.png
[1361804016_5946.png]: https://img-my.csdn.net/uploads/201302/25/1361804016_5946.png
[Image 1]: 
[1361804077_1423.png]: https://img-my.csdn.net/uploads/201302/25/1361804077_1423.png
[1361804109_5028.png]: https://img-my.csdn.net/uploads/201302/25/1361804109_5028.png
[1361804228_6256.png]: https://img-my.csdn.net/uploads/201302/25/1361804228_6256.png
[1361804257_2588.png]: https://img-my.csdn.net/uploads/201302/25/1361804257_2588.png
[1361804294_6145.png]: https://img-my.csdn.net/uploads/201302/25/1361804294_6145.png
[1361804321_8593.png]: https://img-my.csdn.net/uploads/201302/25/1361804321_8593.png