Chromium学习小结upload.pptxVIP

Chromium学习分享 张锴 从多进程的角度看Chromium 从多线程的角度看Chromium Chromium中线程的实现 Chromium中线程的实现 一个Thread只能有一个MessageLoop被实例化。例如，在BrowserMain函数(该函数是Browser进程的入口函数)中实例化一个局部变量MessageLoop main_message_loop(MessageLoop::TYPE_UI)，以后在该线程中任意位置可以通过调用MessageLoop::current()来获取该MessageLoop并调用MessageLoop::current()-Run()来执行该线程实体。 这其中的技术就是线程局部存储（ThreadLocalPointer），当构造一个MessageLoop时，构造函数会将这个MessageLoop指针设置到这个线程的ThreadLocalPointer 对象中，当MessageLoop对象析构时，会重置ThreadLocalPointer 对象。 线程中的自定义任务TASK 在多线程模型中最令人头疼的问题是“加锁”。为了极力避免锁的存在，Chromium的线程模型中加入了一种名为TASK的概念。当你期望你的一个逻辑（or函数）在某个线程中执行时，你可以在当前线程中创建一个Task对象，并将该逻辑放入到Task的Run方法中，最后通过调用“期望执行逻辑线程的PostTask方法”，就可以将该Task放入到期望线程的Task队列中了。 这样做的好处是避免了“加锁”操作，使得多线程与单线程编程模型很好的结合在了一起。 例如：MessageLoop::current()-PostTask(task),该操作可以方便客户端将TASK放入到当前线程的消息队列中去执行。也可以SomeThread-message_loop()-PostTask(task),将task放到其他线程中去执行。 多线程的同步异步操作 在一般的多线程模型中，同步模式下，一切看上去没什么区别，但也丧失了多线程的优势；如果采用异步模式，那么你必须注册回调函数，小心管理对象的生命周期。 在Chromium的多线程模型中，同步和异步的编程模型区别就不复存在了。例如：A线程需要B线程做一些事情，然后返回A线程继续做一些事情。在Chromium中可以这样做：生成一个Task,放到B线程的队列中，在该Task的Run方法最后，生成另一个Task’，将该Task’放回到A线程的队列中，由A来执行 Chromium中进程的实现 Chromium采用多进程的原因： 提高Browser的健壮性：包括单个Plugin、单个页面的崩溃导致整个Browser的崩溃问题； 提高Browser的安全性：基于多进程的安全模型（sandbox模型），Render进程默认是基于Sandbox模型的。 Chromium中的主要进程： Browser进程。主进程，负责浏览器界面的显示，各个页面的管理，是所有其他进程的祖先，负责它们的创建和销毁等工作，它又且仅有一个。 Render进程。渲染进程，负责网页的渲染工作，WebKit/Blink的渲染工作主要在该进程中完成，可以有多个。 GPU进程。有且只有一个，当且仅当GPU硬件加速打开的时候才会被创建，主要用于对3D图像加速调用的实现。 Pepper/NPAPI插件进程。 Chromium中进程的IPC机制 在Chromium中，IPC用的是“有名管道”（Named Pipe），它通过类IPC::Channel封装了具体实现细节。 Channel中有三个比较关键的角色 IPC::Sender IPC::Listener MessagePumpLibevent::Watcher 顾名思义，Sender就是发送消息的接口；Listener是处理接收到消息的具体实现；Watcher中是一些事件回调函数，即当注册到libevent中的Read、Write事件被触发时会调用到Wathcer中的回调函数。 Chromium中进程的IPC机制 在每个进程中，只能有一个线程来负责操作Channel，这个线程叫做IO线程，但是有些时候，我们需要从非IO线程与别的进程进行通信，这该如何是好呢？你一定会想到通过postTask将一个对Channel进行操作的Task放到IO线程队列中。这就是ChannelProxy类的作用。 从接口上看，ChannelProxy的接口与Channel没啥区别，你可以像使用Channel一样使用ChannelProxy来Send你的消息。不仅如此，ChannelProxy还提供了很多新的功能，例如发送同步消息，SyncChannel类。 WebKit中的网络资源申请过程 Chromium中的网络资源申请过程