本节书摘来自华章出版社《深入理解Android》一书中的第3章，第3.6节，作者孟德国 王耀龙 周金利 黎欢，更多章节内容可以访问云栖社区“华章计算机”公众号查看
3.6 WebKit运行时线程结构
Android平台上的WTF库提供了线程结构的C++封装，本节要分析WebKit的运行时线程结构、单个线程的实现结构，以及WebKit运行时多个线程的同步及交互。
3.6.1 MessageQueue实现分析
WebKit线程的经典实现结构为：线程入口函数包含一个循环loop，loop 内部包含一个messageQueue.waitForMessage();操作，这样在没有等待处理的消息时，将线程挂起在messageQueue内部封装的一个ThreadCondition上，而在有消息时循环处理消息。MessageQueue运行原理如图3-3所示。
下述代码是MessageQueue的主要部分。
【→MessageQueue.h】
template<typename DataType>
class MessageQueue {
public:
MessageQueue() : m_killed(false) { }
~MessageQueue();
void append(PassOwnPtr<DataType>);
PassOwnPtr<DataType> waitForMessage();
template<typename Predicate>
PassOwnPtr<DataType>
waitForMessageFilteredWithTimeout(MessageQueueWaitResult&, Predicate&, double absoluteTime);
// isEmpty()函数的返回值，只有在其它线程不访问该MessageQueue对象时才有意义
bool isEmpty();
static double infiniteTime()
{
return std::numeric_limits<double>::max();
}
private:
mutable Mutex m_mutex;
ThreadCondition m_condition;
Deque<DataType*> m_queue;
bool m_killed;
};
浏览MessageQueue数据成员发现，内部包含一个Deque作为主要的存储结构。Mutex类型m_mutex成员为多线程访问Deque的互斥锁，这里Mutex是对phread_mutex_t类型的C++封装，配合MuexLocker类型的局部变量在局部作用域内的构造和自动析构实现自动加锁与解锁。ThreadCondition是对pthread_cond_t类型的C++封装，ThreadCondition类型的m_condition作为事件通知信号，同时提供了挂起线程的场所。MessageQueue可以看作是线程安全Deque的经典实现。
MessageQueue的核心函数是append与waitForMessageFilteredWithTimeout，这两个函数都比较简单，读者可自行分析。
3.6.2 Task传递
在WebKit运行过程中，有众多的操作必须交给主线程来做，比如回调JavaScript的接口。WebKit运行时，大量的到主线程的异步回调，向主线程传递Task 及参数时，必定直接或者间接调用函数callOnMainThread。当然主线程交给其他线程的任务函数及参数的传递，也是采用非常类似的实现，本节主要分析callOnMainThread及相关封装函数的实现。
首先看一下callOnMainThread的定义：
【→MainThread.cpp】
typedef void MainThreadFunction(void*);
void callOnMainThread(MainThreadFunction* function, void* context)
{
ASSERT(function);
bool needToSchedule = false;
{
MutexLocker locker(mainThreadFunctionQueueMutex());
needToSchedule = functionQueue().size() == 0;
functionQueue().append(FunctionWithContext(function, context));
}
if (needToSchedule)
scheduleDispatchFunctionsOnMainThread();
}
从上面的实现可以看出，callOnMainThread的实现较简单，其关联的主要内容在sched-uleDispatchFunctionsOnMainThread，该函数及其触发的后续内容会独立分析，此处我们只要知道callOnMainThread将一个MainThreadFunction的指针放入MainThread的调度队列中。
callOnMainThread函数参数决定了能够放到MainThread上执行的函数必须是单参数且无返回值的普通函数或类内部的static方法。但是，如何将类内部的普通成员方法投放到MainThread的执行队列呢？这种场景的实现方法有很多，本节主要分析chromium-base中使用的实现方式：
[→示例代码]
Static void RunTask(void * v){
OwnPtr<Task> task(static_cast<Task*> (v));
task->Run();
}
callOnMainThread(RunTask,NewRunableMethod(this,&CLASS::FUNCTION,para1,para2));
在上面的代码中，RunTask作为普通C函数，被投放到MainThead中执行，在其内部间接调用被Task封装了的类普通成员函数CLASS::FUNCTION。下面分析NewRunableMethod的使用与实现。
NewRunableMethod函数根据参数类型有很多的重载版本，但总体上可以分为两大类：第一类的第一个参数是函数指针，其余参数为该函数指针所指函数的参数；第二类的第一个参数是对象指针，第二个参数是函数指针，其余参数为函数指针所指函数的参数。上面示例代码中使用的是第二类并且函数指针所指函数（该场景中就是CLASS::FUNCTION）含有两个参数的情况。NewRunableMethod函数将这些信息封装到类RunableMethod中，并将生成的RunableMethod对象返回。细心的读者透过RunTask函数的定义一定猜到了RunableMethod直接或者间接继承自Task，并且提供了virtual的Run函数的实现。
我们看一下 RunableMethod::Run的实现。
【→external/chromium/base/task.h】
template <class Method, class Params>
class RunableMethod: public CancelableTask{
……
virtual void Run() {
if(obj_) {//承载了NewRunableMethod第一个对象参数
DispatchToMethod(obj_.get(), meth_, params_);
}
}
……
};
下面是DispatchToMethod的定义：
[→external/chromium/base/tuple.h]
template <class ObjT, calss Method, class A, class B>
inline void DispatchToMethod(ObjT * obj, Method method, const Tuple2<A,B>& arg){
(obj->*method)(arg.a,arg,b);
}
这样经过层层封装就实现了将类的成员函数放到MainThread执行。
在WebKit中还有一类常用的传递异步回调函数的方法，其核心是createCallbackTask函数，该函数也是将那些要被跨线程回调的函数封装成CrossThreadTaskX，这里的X对应于参数的个数。这一系列CrossThreadTaskX类实现了继承自ScriptExecutionContext::Task类的performTask方法，performTask内的动作也是调用被封装的回调函数。这样，在createCallbackTask产生的CrossThreadTaskX被放到某个线程的任务队列后，回调函数就会在恰当的时机被回调。
3.6.3 MainThread运行原理
WebKit运行时包含众多的线程，比如负责网络资源加载的线程、负责解析及页面布局的线程、负责绘制的线程、负责文件读写的线程、负责媒体资源编解码的线程、Worker线程等。其中，最重要的线程就是负责解析及页面布局的线程，它生成并触发其他线程的动作，作为WebKit运行的中枢驱动了WebKit的大多数动作。这个线程还有另外两个响亮的名字：WebCoreThread和MainThread。
Android平台的WebKit的framework部分提供了WebView接口，WebViewCore随着WebView的创建而创建，WebViewCore在UI线程中构造时创建了一个Java层线程，名字叫作“WebCoreThread”，随后在该线程初始化WebViewCore，创建BrowserFrame，而BrowserFrame调用函数nativeCreateFrame，正式进入WebKit的C++世界，并且初始化C++部分WebKit的运行环境。
WebCoreFrameBridge.cpp中的CreateFrame也就是Java层nativeCreateFrame对应的C++层函数，该函数一开始调用ScriptController::initializeThreading()，在其内部通过WTF::initializeMainThread，将当前线程的identifier赋给了mainThreadIdentifier，也就是说当前线程就是MainThread。mainThreadIdentifier的主要作用是通过与线程的标示符比较来确定被比较线程是否为主线程。据此可知，WebCoreThread也就是MainThread既有Java层的部分，也有C++部分。
C++层的WebKit拥有自己的循环内的MessageQueue调度队列，这个可以从###3.6.2节对callOnMainThread的分析中得知，由于MainThread创建自Java层，最终驱动该线程运行的消息循环也是在Java层。在3.6.2节分析callOnMainThread函数时，留下其内部调用的调度函数scheduleDispatchFunctionsOnMainThread()没有分析。跟踪这个函数的调用流程可以发现，最终被调用的Java层代码在JWebCoreJavaBridge.java中，该类处理了callOnMainThread触发的函数调度事件，以及timer事件等，也就是主线程Native层的函数调度及timer事件都从该类触发，并在恰当的时机回调Native层要处理的函数。
关于Android WebKit的Framework部分，将会在第8章来做更详尽的分析。
