Chromium学习之路(五)----Render进程启动过程分析

发表于 | 分类于 | 阅读次数 |

       有时候我也在想，学这个玩意儿有毛用～其实所学的不一定都能用在工作生活中，但是我们可以借鉴其中的精妙设计，来扩充自己的思维，为以后解决实际问题提供更多的选择。

Render进程概述

       Chrome强大的地方就在于对于对进程的合理应用，比如独特的标签页设计。在配置多进程的情况下，Chromium的网页渲染和JS执行在一个单独的进程中进行。这个进程称为Render进程，由Browser进程启动。在Android平台中，Browser进程就是Android应用程序的主进程，而Render进程就是Android应用程序的Service进程，它们通过UNIX Socket进行通信。

       Render进程启动完成之后，将与Browser进程建立以下的IPC通道，如下图所示：

Browser进程与Render进程的IPC通信过程

       在Browser进程中，一个RenderProcessHost对象用来描述它所启动的一个Render进程，而一个RenderViewHost对象用来描述运行在一个Render进程中的一个网页，我们可以将它理解为浏览器中的一个TAB。这两个对象在Render进程中都有一个对等体，它们分别是一个RenderProcess对象和一个RenderView对象。这里说的对等体，就是它们是Browser进程和Render进程进行IPC的两个端点，类似于TCP/IP网络堆栈中的层对层通信。例如，RenderViewHost和RenderView之间的IPC通信，就代表了Browser进程请求Render进程加载、更新和渲染一个网页。

       RenderViewHost和RenderView之间的IPC通信，实际上是通过一个UNIX Socket进行的。这个UNIX Socket的两端分别被封装为两个Channel对象，分别运行在Browser进程和Render进程各自的IO线程中。这样RenderViewHost和RenderView之间的IPC通信就要通过上述的两个Channel对象进行。

       在Browser进程中，由于RenderViewHost对象运行在主线程中，因此当它需要请求运行在IO线程中的Channel对象执行一次IPC时，就要通过IO线程的消息循环进行。这符合我们在前面Chromium多线程模型设计和实现分析一文中提到的Chromium的多线程设计哲学：每一个对象都只运行在一个线程中，对象之间需要通信时就通过消息循环进行。同样，在Render进程中，由于RenderView对象运行在Render线程中，因此当Render进程的Channel对象接收一个来自Browser进程的RenderViewHost对象的IPC消息时，需要通过Render线程的消息循环将IPC消息转发给RenderView进行处理。从RenderView对象到RenderViewHost对象的通信过程也是类似的。
我们分析Render进程的启动过程，目的就是为了能够理解Browser进程和Render进程是如何建立IPC通道的，因为以后Browser进程与Render进程的交互和协作，都是通过这个IPC通道进行的。为此，我们在分析Render进程的启动过程中，将着重分析涉及到的各个对象的初始过程。

相关类结构

       我们注意到，运行在Browser进程中的通信对象是以Host结尾的，而在运行在Render进程中的对等通信对象，则是没有Host结尾的，因此当我们Chromium的源代码中看到一个对象的类型时，就可以推断出该对象运行在哪个进程中。

       事实上，RenderProcessHost、RenderViewHost、RenderProcess和RenderView仅仅是定义了一个抽象接口，真正用来执行IPC通信的对象，是实现了上述抽象接口的一个实现者对象，这些实现者对象的类型以Impl结尾，因此，RenderProcessHost、RenderViewHost、RenderProcess和RenderView对应的实现者对象的类型就分别为RenderProcessHostImpl、RenderViewHostImpl、RenderProcessImpl和RenderViewImpl。

       为了更好地理解Render进程的启动过程，我们有必要了解上述Impl对象的类关系图。

       RenderViewHostImpl对象的类关系图如下所示：

RenderViewHostImpl

       RenderViewHostImpl类多重继承了RenderViewHost类和RenderWidgetHostImpl类，后面这两个类又有一个共同的虚基类RenderWidgetHost，该虚基类又实现了一个Sender接口，该接口定义了一个重要的成员函数Send，用来执行IPC通信。

       RenderWidgetHostImpl类还实现了一个Listener接口，该接口定义了两个重要的成员函数OnMessageReceived和OnChannelConnected。前者用来接收IPC消息并且进行分发，后者用来在IPC通道建立时执行一些初始化工作。

       实际上，当RenderViewHostImpl类需要发起一次IPC时，它是通过父类RenderWidgetHostImpl的成员变量process_指向的一个RenderProcessHost接口进行的。该RenderProcessHost接口指向的实际上是一个RenderProcessHostImpl对象，它的类关系图如图所示：

RenderProcessHostImpl

       RenderProcessHostImpl类实现了RenderProcessHost接口，后者又多重继承了Sender和Listener类。

       RenderProcessHostImpl类有一个成员变量channel_，它指向了一个ChannelProxy对象。ChannelProxy类实现了Sender接口，RenderProcessHostImpl类就是通过它来发送IPC消息的。

       ChannelProxy类有一个成员变量context_，它指向了一个ChannelProxy::Context对象。ChannelProxy::Context类实现了Listener接口，因此它可以用来接收IPC消息。ChannelProxy类就是通过ChannelProxy::Context类来发送和接收IPC消息的。

       ChannelProxy::Context类有一个类型为Channel的成员变量channel_，它指向的实际上是一个ChannelPosix对象。ChannelPosix类继承了Channel类，后者又实现了Sender接口。ChannelProxy::Context类就是通过ChannelPosix类发送IPC消息的。

       绕了一圈，总结来说，就是RenderProcessHostImpl类是分别通过ChannelPosix类和ChannelProxy::Context类来发送和接收IPC消息的。

       上面分析的RenderViewHostImpl对象和RenderProcessHostImpl对象都是运行在Browser进程的，接下来要分析的RenderViewImpl类和RenderProcessImpl类是运行在Render进程的。

       RenderViewImpl对象的类关系图如下所示：

RenderViewImpl

       RenderViewImpl类多重继承了RenderView类和RenderWidget类。RenderView类实现了Sender接口。RenderWidget类也实现了Sender接口，同时也实现了Listener接口，因此它可以用来发送和接收IPC消息。

       RenderWidget类实现了接口Sender的成员函数Send，RenderViewImpl类就是通过它来发送IPC消息的。RenderWidget类的成员函数Send又是通过一个用来描述Render线程的RenderThreadImpl对象来发送IPC类的。这个RenderThreadImpl对象可以通过调用RenderThread类的静态成员函数Get获得。

       RenderThreadImpl对象的类关系图如下所示：

RenderThreadImpl

       RenderThreadImpl类多重继承了RenderThread类和ChildThread类。RenderThread类实现了Sender接口。ChildThread类也实现Sender接口，同时也实现了Listener接口，因此它可以用来发送和接收IPC消息。

       ChildThread类有一个成员变量channel，它指向了一个SyncChannel对象。SyncChannel类继承了上面提到的ChannelProxy类，因此，ChildThread类通过其成员变量channel指向的SyncChannel对象可以发送IPC消息。

       从上面的分析又可以知道，ChannelProxy类最终是通过ChannelPosix类发送IPC消息的，因此总结来说，就是RenderThreadImpl是通过ChannelPosix类发送IPC消息的。

       接下来我们再来看RenderProcessImpl对象的类关系图，如下所示：

RenderProcessImpl

       RenderProcessImpl类继承了RenderProcess类，RenderProcess类又继承了ChildProcess类。ChildProcess类有一个成员变量iothread，它指向了一个Thread对象。该Thread对象描述的就是Render进程的IO线程。

Render进程启动过程

       有了上面的基础知识之后，接下来我们开始分析Render进程的启动过程。我们将Render进程的启动过程划分为两部分。第一部分是在Browser进程中执行的，它主要负责创建一个UNIX Socket，并且将该UNIX Socket的Client端描述符传递给接下来要创建的Render进程。第二部分是在Render进程中执行的，它负责执行一系列的初始化工作，其中之一就是将Browser进程传递过来的UNIX Socket的Client端描述符封装在一个Channel对象中，以便以后可以通过它来和Browser进程执行IPC。

Render进程启动过程的第一部分

       Render进程启动过程的第一部分子过程如下所示：

RenderStart_1

       图中列出的仅仅是一些核心过程，接下来我们通过代码来分析这些核心过程。

       我们首先了解什么情况下Browser进程会启动一个Render进程。当我们在Chromium的地址栏输入一个网址，然后进行加载的时候，Browser进程经过判断，发现需要在一个新的Render进程中渲染该网址的内容时，就会创建一个RenderViewHostImpl对象，并且调用它的成员函数CreateRenderView触发启动一个新的Render进程。后面我们分析WebView加载一个URL的时候，就会看到触发创建RenderViewHostImpl对象的流程。

       RenderViewHostImpl对象的创建过程，即RenderViewHostImpl类的构造函数的实现如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
RenderViewHostImpl::RenderViewHostImpl(
    SiteInstance* instance,
    RenderViewHostDelegate* delegate,
    RenderWidgetHostDelegate* widget_delegate,
    int routing_id,
    int main_frame_routing_id,
    bool swapped_out,
    bool hidden)
    : RenderWidgetHostImpl(widget_delegate,
                           instance->GetProcess(),
                           routing_id,
                           hidden),
      ...... {
 
  ......
}

       这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_view_host_impl.cc中。

       这里我们主要关注类型为SiteInstance的参数instance，它指向的实际上是一个SiteInstanceImpl对象，用来描述Chromium当前加载的一个网站实例。RenderViewHostImpl类的构造函数调用该SiteInstanceImpl对象的成员函数GetProcess获得一个RenderProcessHostImpl对象，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
RenderProcessHost* SiteInstanceImpl::GetProcess() {
  ......
 
  // Create a new process if ours went away or was reused.
  //如果process_为null表示没有为当前site创建一个render对象
  if (!process_) {
    BrowserContext* browser_context = browsing_instance_->browser_context();
 
    // If we should use process-per-site mode (either in general or for the
    // given site), then look for an existing RenderProcessHost for the site.
    //指定了同一个网站的所有网页都在同一个Render进程中加载，
    //检查之前是否已经为当前正在处理的SiteInstanceImpl对象描述的网站创建过Render进程，
    //如果已经创建过，那么就可以获得一个对应的RenderProcessHostImpl对象
    bool use_process_per_site = has_site_ &&
        RenderProcessHost::ShouldUseProcessPerSite(browser_context, site_);
    if (use_process_per_site) {
      process_ = RenderProcessHostImpl::GetProcessHostForSite(browser_context,
                                                              site_);
    }
 
    // If not (or if none found), see if we should reuse an existing process.
    //如果上面case不通过
    //由于当前创建的Render进程已经超出预设的最大数量了
    //就要服用已经创建过的render进程了
    if (!process_ && RenderProcessHostImpl::ShouldTryToUseExistingProcessHost(
            browser_context, site_)) {
      process_ = RenderProcessHostImpl::GetExistingProcessHost(browser_context,
                                                               site_);
    }
 
    // Otherwise (or if that fails), create a new one.
    //如果上面两种case都failed，就得自己创建一个render进程了
    if (!process_) {
      //如果该静态成员变量被设置了指向一个RenderProcessHostFactory对象，
      //那么就调用该RenderProcessHostFactory对象的成员函数CreateRenderProcessHost创建一个从RenderProcessHost类继承下来的子类对象
      if (g_render_process_host_factory_) {
        process_ = g_render_process_host_factory_->CreateRenderProcessHost(
            browser_context, this);
      } else {
        //否则的话，就直接创建一个RenderProcessHostImpl对象。
        StoragePartitionImpl* partition =
            static_cast<StoragePartitionImpl*>(
                BrowserContext::GetStoragePartition(browser_context, this));
        process_ = new RenderProcessHostImpl(browser_context,
                                             partition,
                                             site_.SchemeIs(kGuestScheme));
      }
    }
 
    ......
  }
  ......
 
  return process_;
}

       这个函数定义在文件external/chromium_org/content/browser/site_instance_impl.cc中。

       SiteInstanceImpl对象的成员变量process是一个RenderProcessHost指针，当它的值等于NULL的时候，就表示Chromium还没有为当前正在处理的一个SiteInstanceImpl对象创建过Render进程，这时候就需要创建一个RenderProcessHostImpl对象，并且保存在成员变量process中，以及返回给调用者，以便调用者接下来可以通过它启动一个Render进程。另一方面，如果SiteInstanceImpl对象的成员变量process_已经指向了一个RenderProcessHostImpl对象，那么就直接将该RenderProcessHostImpl对象返回给调用者即可。

       注意上述RenderProcessHostImpl对象的创建过程：

  1. 如果Chromium启动时，指定了同一个网站的所有网页都在同一个Render进程中加载，即本地变量use_process_per_site的值等于true，那么这时候SiteInstanceImpl类的成员函数GetProcess就会先调用RenderProcessHostImpl类的静态函数GetProcessHostForSite检查之前是否已经为当前正在处理的SiteInstanceImpl对象描述的网站创建过Render进程。如果已经创建过，那么就可以获得一个对应的RenderProcessHostImpl对象。

  2. 如果按照上面的方法找不到一个相应的RenderProcessHostImpl对象，本来就应该要创建一个新的Render进程了，也就是要创建一个新的RenderProcessHostImpl对象了。但是由于当前创建的Render进程已经超出预设的最大数量了，这时候就要复用前面已经启动的Render进程，即使这个Render进程加载的是另一个网站的内容。

  3. 如果通过前面两步仍然找不到一个对应的RenderProcessHostImpl对象，这时候就真的是需要创建一个RenderProcessHostImpl对象了。取决于SiteInstanceImpl类的静态成员变量g_render_process_hostfactory是否被设置，创建一个新的RenderProcessHostImpl对象的方式有所不同。如果该静态成员变量被设置了指向一个RenderProcessHostFactory对象，那么就调用该RenderProcessHostFactory对象的成员函数CreateRenderProcessHost创建一个从RenderProcessHost类继承下来的子类对象。否则的话，就直接创建一个RenderProcessHostImpl对象。

       这一步执行完成后，回到RenderViewHostImpl类的构造函数中，从这里返回的RenderProcessHostImpl对象用来初始化RenderViewHostImpl类的父类RenderWidgetHostImpl，如下所示：

1
2
3
4
5
6
7
8
9
RenderWidgetHostImpl::RenderWidgetHostImpl(RenderWidgetHostDelegate* delegate,
                                           RenderProcessHost* process,
                                           int routing_id,
                                           bool hidden)
    : ......,
      process_(process),
      ...... {
  ......
}

       这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_widget_host_impl.cc中。

       参数process指向的RenderProcessHostImpl对象保存在RenderWidgetHostImpl类的成员变量process_中，以后就可以通过RenderWidgetHostImpl类的成员函数GetProcess获得该RenderProcessHostImpl对象，如下所示：

1
2
3
RenderProcessHost* RenderWidgetHostImpl::GetProcess() const {
  return process_;
}

       这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_widget_host_impl.cc中。

       有了RenderProcessHostImpl之后，接下来我们就开始分析RenderViewHostImpl类的成员函数CreateRenderView创建一个新的Render进程的过程了，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
bool RenderViewHostImpl::CreateRenderView(
    const base::string16& frame_name,
    int opener_route_id,
    int proxy_route_id,
    int32 max_page_id,
    bool window_was_created_with_opener) {
  ......
 
  if (!GetProcess()->Init())
    return false;
 
  ......
 
}

       这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_view_host_impl.cc中。

       RenderViewHostImpl类的成员函数CreateRenderView首先调用从父类RenderWidgetHostImpl继承下来的成员函数GetProcess获得一个RenderProcessHostImpl对象，接着再调用该RenderProcessHostImpl对象的成员函数Init检查是否需要为当前加载的网页创建一个新的Render进程。

       RenderProcessHostImpl类的成员函数Init的实现如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
bool RenderProcessHostImpl::Init() {
  // calling Init() more than once does nothing, this makes it more convenient
  // for the view host which may not be sure in some cases
  //已经为当前要加载的网而创建过Render进程了
  if (channel_)
    return true;
 
  ......
 
  // Setup the IPC channel.
  //为IPC channel创建一个唯一id
  const std::string channel_id =
      IPC::Channel::GenerateVerifiedChannelID(std::string());
  //创建IPC Channel Server
  channel_ = IPC::ChannelProxy::Create(
      channel_id,
      IPC::Channel::MODE_SERVER,
      this,
      BrowserThread::GetMessageLoopProxyForThread(BrowserThread::IO).get());
 
  ......
  //创建一系列的Message Filter，用来过滤IPC消息。
  CreateMessageFilters();
 
  ......
  //如果所有网页都在Browser进程中加载，即不单独创建Render进程来加载网页
  if (run_renderer_in_process()) {
    ......
    in_process_renderer_.reset(g_renderer_main_thread_factory(channel_id));
 
    base::Thread::Options options;
    ......
    options.message_loop_type = base::MessageLoop::TYPE_DEFAULT;
    
    in_process_renderer_->StartWithOptions(options);
 
    g_in_process_thread = in_process_renderer_->message_loop();
 
    ......
  } else {//如果网页要单独的Render进程中加载，那么调用创建一个命令行
    ......
 
    CommandLine* cmd_line = new CommandLine(renderer_path);
    ......
    AppendRendererCommandLine(cmd_line);
    cmd_line->AppendSwitchASCII(switches::kProcessChannelID, channel_id);
 
    ......
    //ChildProcessLauncher对象在创建的过程，就会启动一个新的Render进程。
    child_process_launcher_.reset(new ChildProcessLauncher(
        new RendererSandboxedProcessLauncherDelegate(channel_.get()),
        cmd_line,
        GetID(),
        this));
 
    ......
  }
 
  return true;
}

       这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_process_host_impl.cc中。

       RenderProcessHostImpl类有一个类型为scopedptr成员变量channel，当它引用了一个IPC::ChannelProxy对象的时候，就表明已经为当前要加载的网而创建过Render进程了，因此在这种情况下，就无需要往前执行了。

       我们假设到目前为止，还没有为当前要加载的网页创建过Render进程。接下来RenderProcessHostImpl类的成员函数Init就会做以下四件事情：

  1. 先调用IPC::Channel类的静态成员函数GenerateVerifiedChannelID生成一个接下来用于创建UNIX Socket的名字，接着再以该名字为参数，调用IPC::ChannelProxy类的静态成员函数Create创建一个用于执行IPC的Channel，该Channel就保存在RenderProcessHostImpl类的成员变量channel_中。

  2. 调用RenderProcessHostImpl类的成员函数CreateMessageFilters创建一系列的Message Filter，用来过滤IPC消息。

  3. 如果所有网页都在Browser进程中加载，即不单独创建Render进程来加载网页，那么这时候调用父类RenderProcessHost的静态成员函数run_renderer_in_process的返回值就等于true。在这种情况下，就会通过在本进程（即Browser进程）创建一个新的线程来渲染网页。这个线程由RenderProcessHostImpl类的静态成员变量g_renderer_main_thread_factory描述的一个函数创建，它的类型为InProcessRendererThread。InProcessRendererThread类继承了base::Thread类，从前面Chromium多线程模型设计和实现分析一文可以知道，当调用它的成员函数StartWithOptions的时候，新的线程就会运行起来。这时候如果我们再调用它的成员函数message_loop，就可以获得它的Message Loop。有了这个Message Loop之后，以后就可以向它发送消息了。

  4. 如果网页要单独的Render进程中加载，那么调用创建一个命令行，并且以该命令行以及前面创建的IPC::ChannelProxy对象为参数，创建一个ChildProcessLauncher对象，而该ChildProcessLauncher对象在创建的过程，就会启动一个新的Render进程。

       接下来，我们主要分析第1、3和4件事情，第2件事情在接下来的一篇文章中分析IPC消息分发机制时再分析。

IPC Channel Server创建

       第一件事情涉及到IPC::Channel类的静态成员函数GenerateVerifiedChannelID和IPC::ChannelProxy类的静态成员函数Create。

       IPC::Channel类的静态成员函数GenerateVerifiedChannelID的实现如下所示：

1
2
3
4
5
6
7
8
9
10
std::string Channel::GenerateVerifiedChannelID(const std::string& prefix) {
  // A random name is sufficient validation on posix systems, so we don't need
  // an additional shared secret.
 
  std::string id = prefix;
  if (!id.empty())
    id.append(".");
 
  return id.append(GenerateUniqueRandomChannelID());
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_posix.cc中。

       IPC::Channel类的静态成员函数GenerateVerifiedChannelID实际上是调用另外一个静态成员函数GenerateUniqueRandomChannelID生成一个唯一的随机名字，后者的实现如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
base::StaticAtomicSequenceNumber g_last_id;
 
......
 
std::string Channel::GenerateUniqueRandomChannelID() {
  ......
 
  int process_id = base::GetCurrentProcId();
  return base::StringPrintf("%d.%u.%d",
      process_id,
      g_last_id.GetNext(),
      base::RandInt(0, std::numeric_limits<int32>::max()));
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel.cc中。

       从这里就可以看到，这个用来创建UNIX Socket的名字由当前进程的PID、一个顺序数和一个随机数通过”.”符号连接而成的。

       回到RenderProcessHostImpl类的成员函数Init中，有了用来创建UNIX Socket的名字之后，就可以调用IPC::ChannelProxy类的静态成员函数Create创建一个Channel了，如下所示：

1
2
3
4
5
6
7
8
9
scoped_ptr<ChannelProxy> ChannelProxy::Create(
    const IPC::ChannelHandle& channel_handle,
    Channel::Mode mode,
    Listener* listener,
    base::SingleThreadTaskRunner* ipc_task_runner) {
  scoped_ptr<ChannelProxy> channel(new ChannelProxy(listener, ipc_task_runner));
  channel->Init(channel_handle, mode, true);
  return channel.Pass();
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_proxy.cc中。

       IPC::ChannelProxy类的静态成员函数Create首先是创建了一个ChannelProxy对象，然后再调用该ChannelProxy对象的成员函数Init执行初始化工作，最后返回该ChannelProxy对象给调用者。

       ChannelProxy对象的创建过程如下所示：

1
2
3
4
ChannelProxy::ChannelProxy(Listener* listener,
                           base::SingleThreadTaskRunner* ipc_task_runner)
    : context_(new Context(listener, ipc_task_runner)), did_init_(false) {
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_proxy.cc。

       ChannelProxy类的构造函数主要是创建一个ChannelProxy::Context对象，并且将该ChannelProxy::Context对象保存在成员变量context_中。

       ChannelProxy::Context对象的创建过程如下所示：

1
2
3
4
5
6
7
8
9
10
ChannelProxy::Context::Context(Listener* listener,
                               base::SingleThreadTaskRunner* ipc_task_runner)
    : listener_task_runner_(base::ThreadTaskRunnerHandle::Get()),
      listener_(listener),
      ipc_task_runner_(ipc_task_runner),
      ......
      message_filter_router_(new MessageFilterRouter()),
      ...... {
  ......
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_proxy.cc中。

       ChannelProxy::Context类有三个成员变量是需要特别关注的，它们分别是：

  1. listenter_taskrunner。这个成员变量的类型为scoped_refptr< base::SingleThreadTaskRunner >，它指向的是一个SingleThreadTaskRunner对象。这个SingleThreadTaskRunner对象通过调用ThreadTaskRunnerHandle类的静态成员函数Get获得。从前面Chromium多线程模型设计和实现分析一文可以知道，ThreadTaskRunnerHandle类的静态成员函数Get返回的SingleThreadTaskRunner对象实际上是当前线程的一个MessageLoopProxy对象，通过该MessageLoopProxy对象可以向当前线程的消息队列发送消息。当前线程即为Browser进程的主线程。

  2. listener。这是一个IPC::Listener指针，它的值设置为参数listener的值。从前面的图3可以知道，RenderProcessHostImpl类实现了IPC::Listener接口，而且从前面的调用过程过程可以知道，参数listener指向的就是一个RenderProcessHostImpl对象。以后正在创建的ChannelProxy::Context对象在IO线程中接收到Render进程发送过来的IPC消息之后，就会转发给成员变量listener指向的RenderProcessHostImpl对象处理，但是并不是让后者直接在IO线程处理，而是让后者在成员变量listener_taskrunner描述的线程中处理，即Browser进程的主线程处理。也就是说，ChannelProxy::Context类的成员变量listener_taskrunner和listener_是配合在一起使用的，后面我们分析IPC消息的分发机制时就可以看到这一点。

  3. ipc_taskrunner。这个成员变量与前面分析的成员变量listener_task_runner一样，类型都为scoped_refptr< base::SingleThreadTaskRunner >，指向的者是一个SingleThreadTaskRunner对象。不过，这个SingleThreadTaskRunner对象由参数ipc_task_runner指定。从前面的调用过程可以知道，这个SingleThreadTaskRunner对象实际上是与Browser进程的IO线程关联的一个MessageLoopProxy对象。这个MessageLoopProxy对象用来接收Render进程发送过来的IPC消息。也就是说，Browser进程在IO线程中接收IPC消息。

       ChannelProxy::Context类还有一个重要的成员变量message_filterrouter，它指向一个MessageFilterRouter对象，用来过滤IPC消息，后面我们分析IPC消息的分发机制时再详细分析。

       回到ChannelProxy类的静态成员函数Create中，创建了一个ChannelProxy对象之后，接下来就调用它的成员函数Init进行初始化，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
void ChannelProxy::Init(const IPC::ChannelHandle& channel_handle,
                        Channel::Mode mode,
                        bool create_pipe_now) {
  ......
 
  if (create_pipe_now) {//true，在当前线程中创建
    ......
    context_->CreateChannel(channel_handle, mode);
  } else {//而是在IO线程中创建
    context_->ipc_task_runner()->PostTask(
        FROM_HERE, base::Bind(&Context::CreateChannel, context_.get(),
                              channel_handle, mode));
  }
 
  // complete initialization on the background thread
  //往IO线程中发送一个OnChannelOpened消息函数
  context_->ipc_task_runner()->PostTask(
      FROM_HERE, base::Bind(&Context::OnChannelOpened, context_.get()));
 
  ......
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_proxy.cc中。

       从前面的调用过程知道，参数channel_handle描述的是一个UNIX Socket名称，参数mode的值为IPC::Channel::MODE_SERVER，参数create_pipe_now的值为true。这样，ChannelProxy类的成员函数Init就会马上调用前面创建的ChannelProxy::Context对象的成员函数CreateChannel创建一个IPC通信通道，也就是在当前线程中创建一个IPC通信通道 。

       另一个方面，如果参数create_pipe_now的值等于false，那么ChannelProxy类的成员函数Init就不是在当前线程创建IPC通信通道，而是在IO线程中创建。因为它先通过前面创建的ChannelProxy::Context对象的成员函数ipc_task_runner获得其成员变量ipc_taskrunner描述的SingleThreadTaskRunner对象，然后再将创建IPC通信通道的任务发送到该SingleThreadTaskRunner对象描述的IO线程的消息队列去。当该任务被处理时，就会调用ChannelProxy::Context类的成员函数CreateChannel。

       当调用ChannelProxy::Context类的成员函数CreateChannel创建好一个IPC通信通道之后，ChannelProxy类的成员函数Init还会向当前进程的IO线程的消息队列发送一个消息，该消息绑定的是ChannelProxy::Context类的成员函数OnChannelOpened。因此，接下来我们就分别分析ChannelProxy::Context类的成员函数CreateChannel和OnChannelOpened。

       ChannelProxy::Context类的成员函数CreateChannel的实现如下所示：

1
2
3
4
5
void ChannelProxy::Context::CreateChannel(const IPC::ChannelHandle& handle,
                                          const Channel::Mode& mode) {
  ......
  channel_ = Channel::Create(handle, mode, this);
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_proxy.cc中。

       ChannelProxy::Context类的成员函数CreateChannel调用Channel类的成员函数Create创建了一个IPC通信通道，如下所示：

1
2
3
4
5
scoped_ptr<Channel> Channel::Create(
    const IPC::ChannelHandle &channel_handle, Mode mode, Listener* listener) {
  return make_scoped_ptr(new ChannelPosix(
      channel_handle, mode, listener)).PassAs<Channel>();
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_posix.cc中。

       从这里可以看到，对于Android平台来说，IPC通信通道通过一个ChannelPosix对象描述，该ChannelPosix对象的创建过程如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
ChannelPosix::ChannelPosix(const IPC::ChannelHandle& channel_handle,//UNIX Socket名称
                           Mode mode, Listener* listener)
    : ChannelReader(listener),
      mode_(mode),//IPC::Channel::MODE_SERVER
      ......
      pipe_(-1),//server端文件描述符
      client_pipe_(-1),//client文件描述符
#if defined(IPC_USES_READWRITE)//如果发送的消息包含文件描述符
      fd_pipe_(-1),//server
      remote_fd_pipe_(-1),//clent
#endif  // IPC_USES_READWRITE 使用专用UNIX Socket传输
      pipe_name_(channel_handle.name),
      ...... {
  ......
  if (!CreatePipe(channel_handle)) {
    ......
  }
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_posix.cc中。

       从前面的调用过程可以知道，参数channel_handle描述的是一个UNIX Socket名称，参数mode的值等于IPC::Channel::MODE_SERVER，参数listener指向的是前面创建的ChannelProxy::Context对象。

       ChannelPosix类继承了ChannelReader类，后者用来读取从Render进程发送过来的IPC消息，并且将读取到的IPC消息发送给参数listener描述的ChannelProxy::Context对象，因此这里会将参数listener描述的ChannelProxy::Context对象传递给ChannelReader的构造函数。

       ChannelPosix类通过UNIX Socket来描述IPC通信通道，这个UNIX Socket的Server端和Client文件描述符分别保存在成员变量pipe_和clientpipe中。如果定义了宏IPC_USES_READWRITE，那么当发送的消息包含有文件描述时，就会使用另外一个专用的UNIX Socket来传输文件描述符给对方。这个专用的UNIX Socket的Server端和Client端文件描述符保存在成员变量fdpipe和remote_fdpipe中。后面分析IPC消息的分发过程时，我们再详细分析这一点。

       ChannelPosix类的构造函数最后调用了另外一个成员函数CreatePipe开始创建IPC通信通道，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
bool ChannelPosix::CreatePipe(
    const IPC::ChannelHandle& channel_handle) {
  ......
 
  int local_pipe = -1;
  if (channel_handle.socket.fd != -1) {//仅仅保存了即将要创建的UNIX Socket的名称
    ......
  } else if (mode_ & MODE_NAMED_FLAG) {//IPC::Channel::MODE_SERVER，它的MODE_NAMED_FLAG位等于0
    ......
  } else {
    //Pipe Map中检查是否存在一个UNIX Socket文件描述符与成员变量pipe_name_对应
    local_pipe = PipeMap::GetInstance()->Lookup(pipe_name_);
    if (mode_ & MODE_CLIENT_FLAG) {//client端
      if (local_pipe != -1) {//如果存在
        ......
        local_pipe = HANDLE_EINTR(dup(local_pipe));//就是用这个fd
        ......
      } else {//如果不存在
        ......
        //那么再到Global Descriptors中检查是否存在一个UNIX Socket文件描述符与常量kPrimaryIPCChannel对应
        local_pipe =
            base::GlobalDescriptors::GetInstance()->Get(kPrimaryIPCChannel);
      }
    } else if (mode_ & MODE_SERVER_FLAG) {//server端
      ......
      base::AutoLock lock(client_pipe_lock_);
      if (!SocketPair(&local_pipe, &client_pipe_))//创建了一个UNIX Socket
        return false;
      //保存在一个Pipe Map中  
      PipeMap::GetInstance()->Insert(pipe_name_, client_pipe_);
    } 
    ......
  }
 
#if defined(IPC_USES_READWRITE)//创建一个专门用来在进程间传递文件描述的UNIX Socket
  // Create a dedicated socketpair() for exchanging file descriptors.
  // See comments for IPC_USES_READWRITE for details.
  if (mode_ & MODE_CLIENT_FLAG) {
    if (!SocketPair(&fd_pipe_, &remote_fd_pipe_)) {
      return false;
    }
  }
#endif  // IPC_USES_READWRITE
 
  ......
 
  pipe_ = local_pipe;
  return true;
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_posix.cc中。

       ChannelHandle类除了用来保存UNIX Socket的名称之外，还可以用来保存与该名称对应的UNIX Socket的文件描述符。在我们这个情景中，参数channel_handle仅仅保存了即将要创建的UNIX Socket的名称。

       ChannelPosix类的成员变量mode_的值等于IPC::Channel::MODE_SERVER，它的MODE_NAMEDFLAG位等于0。Render进程启动之后，也会调用到ChannelPosix类的成员函数CreatePipe创建一个Client端的IPC通信通道，那时候用来描述Client端IPC通信通道的ChannelPosix对象的成员变量mode的值IPC::Channel::MODE_CLIENT，它的MODE_NAMED_FLAG位同样等于0。因此，无论是在Browser进程中创建的Server端IPC通信通道，还是在Render进程中创建的Client端IPC通信通道，在调用ChannelPosix类的成员函数CreatePipe时，都按照以下逻辑进行。

       对于Client端的IPC通信通道，即ChannelPosix类的成员变量mode_的MODE_CLIENT_FLAG位等于1的情况，首先是在一个Pipe Map中检查是否存在一个UNIX Socket文件描述符与成员变量pipename对应。如果存在，那么就使用该文件描述符进行IPC通信。如果不存在，那么再到Global Descriptors中检查是否存在一个UNIX Socket文件描述符与常量kPrimaryIPCChannel对应。如果存在，那么就使用该文件描述符进行IPC通信。实际上，当网页不是在独立的Render进程中加载时，执行的是前一个逻辑，而当网页是在独立的Render进程中加载时，执行的是后一个逻辑。

       Chromium为了能够统一地处理网页在独立Render进程和不在独立Render进程加载两种情况，会对后者进行一个抽象，即会假设后者也是在独立的Render进程中加载一样。这样，Browser进程在加载该网页时，同样会创建一个图1所示的RenderProcess对象，不过该RenderProcess对象没有对应的一个真正的进程，对应的仅仅是Browser进程中的一个线程。也就是这时候，图1所示的RenderPocessHost对象和RenderProcess对象执行的仅仅是进程内通信而已，不过它们仍然是按照进程间的通信规则进行，也就是通过IO线程来间接进行。不过，在进程内建立IPC通信通道和在进程间建立IPC通信通道的方式是不一样的。具体来说，就是在进程间建立IPC通信通道，需要将描述该通道的UNIX Socket的Client端文件描述符从Browser进程传递到Render进程，Render进程接收到该文件描述符之后，就会以kPrimaryIPCChannel为键值保存在Global Descriptors中。而在进程内建立IPC通信通道时，描述IPC通信通道的UNIX Socket的Client端文件描述符直接以UNIX Socket名称为键值，保存在一个Pipe Map中即可。后面我们分析在进程内在进程间创建Client端IPC通信通道时，会继续看到这些相关的区别。

       对于Server端的IPC通信通道，即ChannelPosix类的成员变量mode_的MODE_SERVERFLAG位等于1的情况，ChannelPosix类的成员函数CreatePipe调用函数SocketPair创建了一个UNIX Socket，其中，Server端文件描述符保存在成员变量pipe中，而Client端文件描述符保存在成员变量clientpipe中，并且Client端文件描述符还会以与前面创建的UNIX Socket对应的名称为键值，保存在一个Pipe Map中，这就是为建立进程内IPC通信通道而准备的。

       最后，如果定义了IPC_USES_READWRITE宏，如前面提到的，那么还会继续创建一个专门用来在进程间传递文件描述的UNIX Socket，该UNIX Socket的Server端和Client端文件描述符分别保存在成员变量fdpipe和remote_fdpipe中。

       这一步执行完成之后，一个Server端IPC通信通道就创建完成了。回到ChannelProxy类的成员函数Init中，它接下来是发送一个消息到Browser进程的IO线程的消息队列中，该消息绑定的是ChannelProxy::Context类的成员函数OnChannelOpened，它的实现如下所示：

1
2
3
4
5
6
7
8
9
10
void ChannelProxy::Context::OnChannelOpened() {
  ......
 
  if (!channel_->Connect()) {
    OnChannelError();
    return;
  }
 
  ......
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_proxy.cc中。

       从前面的分析可以知道，ChannelProxy::Context类的成员变量channel_指向的是一个ChannelPosix对象，这里调用它的成员函数Connect将它描述的IPC通信通道交给当前进程的IO线程进行监控。

       ChannelPosix类的成员函数Connect的实现如下所示：

1
2
3
4
5
6
7
8
9
10
11
bool ChannelPosix::Connect() {
  ......
 
  bool did_connect = true;
  if (server_listen_pipe_ != -1) {
    ......
  } else {
    did_connect = AcceptConnection();
  }
  return did_connect;
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_posix.cc中。

       当ChannelPosix类的成员变量server_listenpipe的值不等于-1时，表示它描述的是一个用来负责监听IPC通信通道连接消息的Socket中，也就是这个Socket不是真正用来执行Browser进程和Render进程之间的通信的，而是Browser进程首先对ChannelPosix类的成员变量server_listenpipe描述的Socket进行listen，接着Render进程通过connect连接到该Socket，使得Browser进程accepet到一个新的Socket，然后再通过这个新的Socket与Render进程执行IPC。

       在我们这个情景中，ChannelPosix类的成员变量server_listenpipe的值等于-1，因此接下来ChannelPosix类的成员函数Connect调用了另外一个成员函数AcceptConnection，它的实现如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
bool ChannelPosix::AcceptConnection() {
  //对fd进行监控
  base::MessageLoopForIO::current()->WatchFileDescriptor(
      pipe_, true, base::MessageLoopForIO::WATCH_READ, &read_watcher_, this);
  //创建一个Hello Message，并且将该Message添加到内部的一个IPC消息队列去等待发送给对方进程
  QueueHelloMessage();
 
  if (mode_ & MODE_CLIENT_FLAG) {//client端通信通道
    // If we are a client we want to send a hello message out immediately.
    // In server mode we will send a hello message when we receive one from a
    // client.
    waiting_connect_ = false;
    return ProcessOutgoingMessages();//把Hello Message发送给Server端
  } else if (mode_ & MODE_SERVER_FLAG) {//server端通信通道
    waiting_connect_ = true;//等待Client端发送一个Hello Message过来
    return true;
  } else {
    NOTREACHED();
    return false;
  }
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_proxy.cc中。

       ChannelPosix类的成员函数AcceptConnection首先是获得与当前进程的IO线程关联的一个MessageLoopForIO对象，接着再调用该MessageLoopForIO对象的成员函数WatchFileDescriptor对成员变量pipe_ 描述的一个UNIX Socket进行监控。MessageLoopForIO类的成员函数WatchFileDescriptor最终会调用到在前面Chromium多线程模型设计和实现分析一文中提到的MessagePumpLibevent对该UNIX Socket进行监控。这意味着当该UNIX Socket有新的IPC消息需要接收时，当前正在处理的ChannelPosix对象的成员函数OnFileCanReadWithoutBlocking就会被调用。这一点需要理解Chromium的多线程机制，具体可以参考Chromium多线程模型设计和实现分析一文。

       接下来，ChannelPosix类的成员函数AcceptConnection还会调用另外一个成员函数QueueHelloMessage创建一个Hello Message，并且将该Message添加到内部的一个IPC消息队列去等待发送给对方进程。执行IPC的双方，就是通过这个Hello Message进行握手的。具体来说，就是Server端和Client端进程建立好连接之后，由Client端发送一个Hello Message给Server端，Server端接收到该Hello Message之后，就认为双方已经准备就绪，可以进行IPC了。

       因此，如果当前正在处理的ChannelPosix对象描述的是Client端的通信通道，即它的成员变量mode_的MODE_CLIENT_FLAG位等于1，那么ChannelPosix类的成员函数AcceptConnection就会马上调用另外一个成员函数ProcessOutgoingMessages前面创建的Hello Message发送给Server端。

       另一方面，如果当前正在处理的ChannelPosix对象描述的是Server端的通信通道，那么ChannelPosix类的成员函数AcceptConnection就仅仅是将成员变量waitingconnect的值设置为true，表示正在等待Client端发送一个Hello Message过来。

       关于Hello Message的发送和接收，我们在接下来的一篇文章分析IPC消息分发机制时再详细分析。

       这一步执行完成之后，Server端的IPC通信通道就创建完成了，也就是Browser进程已经创建好了一个Server端的IPC通信通道。回到RenderProcessHostImpl类的成员函数Init中，它接下来要做的事情就是启动Render进程。

非独立进程Render

       我们首先考虑网页不是在独立的Render进程加载的情况，即在Browser进程加载的情况，这时候并没有真的启动了一个Render进程，而仅仅是在Browser进程中创建了一个RenderProcess对象而已，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
bool RenderProcessHostImpl::Init() {
  ......
 
  // Setup the IPC channel.
  const std::string channel_id =
      IPC::Channel::GenerateVerifiedChannelID(std::string());
  channel_ = IPC::ChannelProxy::Create(
      channel_id,
      IPC::Channel::MODE_SERVER,
      this,
      BrowserThread::GetMessageLoopProxyForThread(BrowserThread::IO).get());
 
  ......
 
  if (run_renderer_in_process()) {//非独立进程启动render进程
    ......
    in_process_renderer_.reset(g_renderer_main_thread_factory(channel_id));
 
    base::Thread::Options options;
    ......
    options.message_loop_type = base::MessageLoop::TYPE_DEFAULT;
    
    in_process_renderer_->StartWithOptions(options);
 
    g_in_process_thread = in_process_renderer_->message_loop();
 
    OnProcessLaunched();  // Fake a callback that the process is ready.
  } else {
    ......
  }
 
  return true;
}

       这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_process_host_impl.cc中。

       前面在分析RenderProcessHostImpl类的成员函数Init时提到，RenderProcessHostImpl类的静态成员变量g_renderer_main_thread_factory描述的是一个函数，通过它可以创建一个类型为InProcessRendererThread的线程。

       一个类型为InProcessRendererThread的线程的创建过程如下所示：

1
2
3
InProcessRendererThread::InProcessRendererThread(const std::string& channel_id)
    : Thread("Chrome_InProcRendererThread"), channel_id_(channel_id) {
}

       这个函数定义在文件external/chromium_org/content/renderer/in_process_renderer_thread.cc中。

       从这里就可以看到，InProcessRendererThread类是从Thread类继承下来的，因此这里调用了Thread类的构造函数。

       此外，InProcessRendererThread类的构造函数还会将参数channel_id描述的一个UNIX Socket名称保存在成员变量channelid中。从前面的分析可以知道，该名称对应的UNIX Socket已经创建出来了，并且它的Client端文件描述符以该名称为键值，保存在一个Pipe Map中。

       回到RenderProcessHostImpl类的成员函数Init中，接下来它会调用前面创建的InProcessRendererThread对象的成员函数StartWithOptions启动一个线程。从前面Chromium多线程模型设计和实现分析一文可以知道，当该线程启动起来之后，并且在进入消息循环之前，会被调用InProcessRendererThread类的成员函数Init执行初始化工作。

       InProcessRendererThread类的成员函数Init的实现如下所示：

1
2
3
4
void InProcessRendererThread::Init() {
  render_process_.reset(new RenderProcessImpl());
  new RenderThreadImpl(channel_id_);
}

       这个函数定义在文件external/chromium_org/content/renderer/in_process_renderer_thread.cc中。

       InProcessRendererThread类的成员函数Init首先在当前进程，即Browser进程，创建了一个RenderProcessImpl对象，保存在成员变量renderprocess中，描述一个假的Render进程，接着再创建了一个RenderThreadImpl对象描述当前线程，即当前正在处理的InProcessRendererThread对象描述的线程。

       在RenderProcessImpl对象的创建中，会创建一个IO线程，该IO线程负责与Browser进程启动时就创建的一个IO线程执行IPC通信。从图6可以知道，RenderProcessImpl类继承了RenderProcess类，RenderProcess类又继承了ChildProcess类，创建IO线程的工作是从ChildProcess类的构造函数中进行的，如下所示：

1
2
3
4
5
6
7
8
9
10
ChildProcess::ChildProcess()
    : ...... {
  ......
 
  // We can't recover from failing to start the IO thread.
  CHECK(io_thread_.StartWithOptions(
      base::Thread::Options(base::MessageLoop::TYPE_IO, 0)));
 
  ......
}

       这个函数定义在文件external/chromium_org/content/child/child_process.cc中。

       从这里就可以看到，ChildProcess类的构造函数调用了成员变量iothread描述的一个Thread对象的成员函数StartWithOptions创建了一个IO线程。

       回到InProcessRendererThread类的成员函数Init中，在RenderThreadImpl对象的创建过程，会创建一个Client端的IPC通信通道，如下所示：

1
2
3
4
RenderThreadImpl::RenderThreadImpl(const std::string& channel_name)
    : ChildThread(channel_name) {
  ......
}

       这个函数定义在文件external/chromium_org/content/renderer/render_thread_impl.cc中。

       从这里可以看到，RenderThreadImpl类继承了ChildThread类，创建Client端IPC通信通道的过程是在ChildThread类的构造函数中进行的，如下所示：

1
2
3
4
5
ChildThread::ChildThread(const std::string& channel_name)
    : channel_name_(channel_name),
      ..... {
  Init();
}

       这个函数定义在文件external/chromium_org/content/child/child_thread.cc中。

IPC Channel Client创建

       ChildThread类的构造函数将参数channel_name描述的一个UNIX Socket的名称保存在成员变量channelname之后，就调用了另外一个成员函数Init执行创建Client端IPC通信通道的工作，如下所示： 

1
2
3
4
5
6
7
8
9
10
11
12
13
void ChildThread::Init() {
  ......
 
  channel_ =
      IPC::SyncChannel::Create(channel_name_,
                               IPC::Channel::MODE_CLIENT,
                               this,
                               ChildProcess::current()->io_message_loop_proxy(),
                               true,
                               ChildProcess::current()->GetShutDownEvent());
 
  ......
}

       这个函数定义在文件external/chromium_org/content/child/child_thread.cc中。

       Client端IPC通信通道通过IPC::SyncChannel类的静态成员函数Create进行创建，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
scoped_ptr<SyncChannel> SyncChannel::Create(
    const IPC::ChannelHandle& channel_handle,
    Channel::Mode mode,
    Listener* listener,
    base::SingleThreadTaskRunner* ipc_task_runner,
    bool create_pipe_now,
    base::WaitableEvent* shutdown_event) {
  scoped_ptr<SyncChannel> channel =
      Create(listener, ipc_task_runner, shutdown_event);
  channel->Init(channel_handle, mode, create_pipe_now);
  return channel.Pass();
}

       这个函数定义在文件external/chromium_org/ipc/ipc_sync_channel.cc中。

       IPC::SyncChannel类的静态成员函数Create首先调用另外一个重载版本的静态成员函数Create创建一个SyncChannel对象，接着再调用该SyncChannel的成员函数Init执行初始化工作。

       IPC::SyncChannel类是从IPC::ChannelProxy类继承下来的，它与IPC::ChannelProxy的区别在于，前者既可以用来发送同步的IPC消息，也可以用来发送异步的IPC消息，而后者只可以用来发送异步消息。所谓同步IPC消息，就是发送者发送它给对端之后，会一直等待对方发送一个回复，而对于异步IPC消息，发送者把它发送给对端之后，不会进行等待，而是直接返回。后面分析IPC消息的分发机制时我们再详细分析这一点。

       IPC::SyncChannel类的成员函数Init是从父类IPC::ChannelProxy类继承下来的，后者我们前面已经分析过了，主要区别在于这里传递第二个参数mode的值等于IPC::Channel::MODE_CLIENT，表示要创建的是一个Client端的IPC通信通道。

       接下来，我们就主要分析IPC::SyncChannel类三个参数版本的静态成员函数Create创建SyncChannel对象的过程，如下所示：

1
2
3
4
5
6
7
scoped_ptr<SyncChannel> SyncChannel::Create(
    Listener* listener,
    base::SingleThreadTaskRunner* ipc_task_runner,
    WaitableEvent* shutdown_event) {
  return make_scoped_ptr(
      new SyncChannel(listener, ipc_task_runner, shutdown_event));
}

       这个函数定义在文件external/chromium_org/ipc/ipc_sync_channel.cc中。

       IPC::SyncChannel类三个参数版本的静态成员函数Create创建了一个SyncChannel对象，并且将该SyncChannel对象返回给调用者。

       SyncChannel对象的创建过程如下所示：

1
2
3
4
5
6
7
8
SyncChannel::SyncChannel(
    Listener* listener,
    base::SingleThreadTaskRunner* ipc_task_runner,
    WaitableEvent* shutdown_event)
    : ChannelProxy(new SyncContext(listener, ipc_task_runner, shutdown_event)) {
  ......
  StartWatching();
}

       这个函数定义在文件external/chromium_org/ipc/ipc_sync_channel.cc中。

       从前面的调用过程可以知道，参数listener描述的是一个ChildThread对象，参数ipc_task_runner描述的是与前面在ChildProcess类的构造函数中创建的IO线程关联的一个MessageLoopProxy对象，参数shutdown_event描述的是一个ChildProcess关闭事件。

       对于第三个参数shutdown_event的作用，我们这里做一个简单的介绍，在接下来一篇文章中分析IPC消息的分发机制时再详细分析。前面提到，SyncChannel可以用来发送同步消息，这意味着发送线程需要进行等待。这个等待过程是通过我们在前面Chromium多线程模型设计和实现分析一文中提到的WaitableEvent类实现的。也就是说，每一个同步消息都有一个关联的WaitableEvent对象。此外，还有一些异常情况需要处理。例如，SyncChannel在等待一个同步消息的过程中，有可能对方已经退出了，这相当于是发生了一个ChildProcess关闭事件。在这种情况下，继续等待是没有意义的。因此，当SyncChannel监控到ChildProcess关闭事件时，就可以执行一些清理工作了。此外，SyncChannel在等待一个同步消息的过程中，也有可能收到对方发送过来的非回复消息。在这种情况下，SyncChannel需要获得通知，以便可以对这些非回复消息进行处理。SyncChannel获得此类非回复消息的事件通知是通过另外一个称为Dispatch Event的WaitableEvent对象获得的。这意味着SyncChannel在发送一个同步消息的过程中，需要同时监控多个WaitableEvent对象。

       了解了各个参数的含义之后，我们就开始分析SyncChannel类的构造函数。它首先是创建了一个SyncChannel::SyncContext对象，并且以该SyncChannel::SyncContext对象为参数，调用父类ChannelProxy的构造函数，以便可以对父类ChannelProxy进行初始化。

       SyncChannel::SyncContext对象的创建过程如下所示：

1
2
3
4
5
6
7
8
9
SyncChannel::SyncContext::SyncContext(
    Listener* listener,
    base::SingleThreadTaskRunner* ipc_task_runner,
    WaitableEvent* shutdown_event)
    : ChannelProxy::Context(listener, ipc_task_runner),
      ......,
      shutdown_event_(shutdown_event),
      ...... {
}

        这个函数定义在文件external/chromium_org/ipc/ipc_sync_channel.cc中。

       从这里可以看到，SyncChannel::SyncContext类是从ChannelProxy::Context类继承下来的，因此这里会调用ChannelProxy::Context类的构造函数进行初始化。此外，SyncChannel::SyncContext类的构造函数还会将参数shutdown_event描述的一个ChildProcess关闭事件保存在成员变量shutdownevent中。

       回到SyncChannel类的构造函数中，当它创建了一个SyncChannel::SyncContext对象之后，就使用该SyncChannel::SyncContext对象来初始化父类ChannelProxy，如下所示：

1
2
3
4
ChannelProxy::ChannelProxy(Context* context)
    : context_(context), 
      did_init_(false) {
}

       这个函数定义在文件external/chromium_org/ipc/ipc_channel_proxy.cc。

       注意，参数context的类型虽然为一个ChannelProxy::Context指针，但是它实际上指向的是一个SyncChannel::SyncContext对象，该SyncChannel::SyncContext对象保存在成员变量context_中。

       继续回到SyncChannel类的构造函数中，它用一个SyncChannel::SyncContext对象初始化了父类ChannelProxy之后，继续调用另外一个成员函数StartWatching监控我们在前面提到的一个Dispatch Event，如下所示：

1
2
3
4
5
6
7
8
void SyncChannel::StartWatching() {
  ......
  dispatch_watcher_callback_ =
      base::Bind(&SyncChannel::OnWaitableEventSignaled,
                  base::Unretained(this));
  dispatch_watcher_.StartWatching(sync_context()->GetDispatchEvent(),
                                  dispatch_watcher_callback_);
}

       这个函数定义在文件external/chromium_org/ipc/ipc_sync_channel.cc中。

       SyncChannel类的成员函数StartWatching调用成员变量dispatchwatcher描述的一个WaitableEventWatcher对象的成员函数StartWatching对Dispatch Event进行监控，从这里就可以看到，Dispatch Event可以通过前面创建的SyncChannel::SyncContext对象的成员函数sync_context获得，并且当该Display Event发生时，SyncChannel类的成员函数OnWaitableEventSignaled就会被调用。

       前面在分析ChannelProxy类的成员函数Init时，我们提到，当它调用另外一个成员函数CreateChannel创建了一个IPC通信通道之后，会调用其成员变量context描述的一个ChannelProxy::Context对象的成员函数OnChannelOpened将已经创建好的的IPC通信通道增加到IO线程的消息队列中去监控。由于在我们这个情景中，ChannelProxy类的成员变量context指向的是一个SyncChannel::SyncContext对象，因此，当ChannelProxy类的成员函数Init创建了一个IPC通信通道之后，它接下来调用的是SyncChannel::SyncContext类的成员函数OnChanneIOpened将已经创建好的IPC通信通道增加到IO线程的消息队列中去监控。

       SyncChannel::SyncContext类的成员函数OnChanneIOpened的实现如下所示：

1
2
3
4
5
6
7
void SyncChannel::SyncContext::OnChannelOpened() {
  shutdown_watcher_.StartWatching(
      shutdown_event_,
      base::Bind(&SyncChannel::SyncContext::OnWaitableEventSignaled,
                 base::Unretained(this)));
  Context::OnChannelOpened();
}

       这个函数定义在文件external/chromium_org/ipc/ipc_sync_channel.cc中。

       SyncChannel::SyncContext类的成员函数OnChanneIOpened首先是调用成员变量shutdownwatcher描述的一个WaitableEventWatcher对象的成员函数StartWatching监控成员变量shutdownevent描述的一个ChildProcess关闭事件。从这里就可以看到，当ChildProcess关闭事件发生时，SyncChannel::SyncContext类的成员函数OnWaitableEventSignaled就会被调用。

       最后，SyncChannel::SyncContext类的成员函数OnChanneIOpened调用了父类ChannelProxy的成员函数OnChannelOpened将IPC通信通道增加到IO线程的的消息队列中去监控。

       这一步执行完成之后，一个Client端的IPC通信通道就创建完成了。这里我们描述的Client端IPC通信通道的创建过程虽然是发生在Browser进程中的，不过这个过程与在独立的Render进程中创建的Client端IPC通信通道的过程是一样的。这一点在接下来的分析中就可以看到。

独立进程Render启动

       回到前面分析的RenderProcessHostImpl类的成员函数Init中，对于需要在独立的Render进程加载网页的情况，它就会启动一个Render进程，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
bool RenderProcessHostImpl::Init() {
  ......
 
  // Setup the IPC channel.
  const std::string channel_id =
      IPC::Channel::GenerateVerifiedChannelID(std::string());
  channel_ = IPC::ChannelProxy::Create(
      channel_id,
      IPC::Channel::MODE_SERVER,
      this,
      BrowserThread::GetMessageLoopProxyForThread(BrowserThread::IO).get());
 
  ......
 
  if (run_renderer_in_process()) {
    ......
  } else {//独立进程render启动
    ......
 
    CommandLine* cmd_line = new CommandLine(renderer_path);
    ......
    AppendRendererCommandLine(cmd_line);
    cmd_line->AppendSwitchASCII(switches::kProcessChannelID, channel_id);
 
    ......
 
    child_process_launcher_.reset(new ChildProcessLauncher(
        new RendererSandboxedProcessLauncherDelegate(channel_.get()),
        cmd_line,
        GetID(),
        this));
 
    ......
  }
 
  return true;
}

       这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_process_host_impl.cc中。

       RenderProcessHostImpl类的成员函数Init创建了一个Server端的IPC通信通道之后，就会通过一个ChildProcessLauncher对象来启动一个Render进程。不过在启动该Render进程之前，首先要构造好它的启动参数，也就是命令行参数。

       Render进程的启动命令行参数通过一个CommandLine对象来描述，它包含有很多选项，不过现在我们只关心两个。一个是switches::kProcessType，另外一个是switches::kProcessChannelID。其中，switches::kProcessChannelID选项对应的值设置为本地变量channel_id描述的值，即前面调用IPC::Channel类的静态成员函数GenerateVerifiedChannelID生成的一个UNIX Socket名称。

       选项switches::kProcessType的值是通过RenderProcessHostImpl类的成员函数AppendRendererCommandLine设置的，如下所示：

1
2
3
4
5
6
7
8
void RenderProcessHostImpl::AppendRendererCommandLine(
    CommandLine* command_line) const {
  // Pass the process type first, so it shows first in process listings.
  command_line->AppendSwitchASCII(switches::kProcessType,
                                  switches::kRendererProcess);
  
    ......
}

       这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_process_host_impl.cc中。

       从这里就可以看到，选项switches::kProcessType的值设置为kRendererProcess，这表示接下来我们通过ChildProcessLauncher类启动的进程是一个Render进程。

       回到RenderProcessHostImpl类的成员函数Init中，当要启动的Render进程的命令行参数准备好之后，接下来就通过ChildProcessLauncher类的构造函数启动一个Render进程，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
ChildProcessLauncher::ChildProcessLauncher(
    SandboxedProcessLauncherDelegate* delegate,
    CommandLine* cmd_line,
    int child_process_id,
    Client* client) {
  context_ = new Context();
  context_->Launch(
      delegate,
      cmd_line,
      child_process_id,
      client);
}

       这个函数定义在文件external/chromium_org/content/browser/child_process_launcher.cc中。

       ChildProcessLauncher类的构造函数首先创建了一个ChildProcessLauncher::Context对象，保存在成员变量context_中，并且调用该ChildProcessLauncher::Context对象的成员函数Launch启动一个Render进程。

       ChildProcessLauncher::Context类的成员函数Launch的实现如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class ChildProcessLauncher::Context
    : public base::RefCountedThreadSafe<ChildProcessLauncher::Context> {
 public:
  ......
 
  void Launch(
      SandboxedProcessLauncherDelegate* delegate,
      CommandLine* cmd_line,
      int child_process_id,
      Client* client) {
    client_ = client;
 
    ......
 
    BrowserThread::PostTask(
        BrowserThread::PROCESS_LAUNCHER, FROM_HERE,
        base::Bind(
            &Context::LaunchInternal,
            make_scoped_refptr(this),
            client_thread_id_,
            child_process_id,
            delegate,
            cmd_line));
  }
 
  ......
};

       这个函数定义在文件external/chromium_org/content/browser/child_process_launcher.cc中。

       ChildProcessLauncher::Context类的成员函数Launch通过调用BrowserThread类的静态成员函数PostTask向Browser进程的一个专门用来启动子进程的BrowserThread::PROCESS_LAUNCHER线程的消息队列发送一个任务，该任务绑定了ChildProcessLauncher::Context类的成员函数LaunchInternal。因此，接下来ChildProcessLauncher::Context类的成员函数LaunchInternal就会在BrowserThread::PROCESS_LAUNCHER线程中执行，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
static void LaunchInternal(
      // |this_object| is NOT thread safe. Only use it to post a task back.
      scoped_refptr<Context> this_object,
      BrowserThread::ID client_thread_id,
      int child_process_id,
      SandboxedProcessLauncherDelegate* delegate,
      CommandLine* cmd_line) {
    scoped_ptr<SandboxedProcessLauncherDelegate> delegate_deleter(delegate);
#if defined(OS_WIN)
...
#elif defined(OS_ANDROID)
    int ipcfd = delegate->GetIpcFd();
#elif defined(OS_MACOSX)
...   
#elif defined(OS_POSIX)
...
#endif
    scoped_ptr<CommandLine> cmd_line_deleter(cmd_line);
    base::TimeTicks begin_launch_time = base::TimeTicks::Now();

#if defined(OS_WIN)
   ...
#elif defined(OS_POSIX)
    //renderer
    std::string process_type =
        cmd_line->GetSwitchValueASCII(switches::kProcessType);
    std::vector<FileDescriptorInfo> files_to_register;
    //ipc fd
    files_to_register.push_back(
        FileDescriptorInfo(kPrimaryIPCChannel,
                           base::FileDescriptor(ipcfd, false)));
    base::StatsTable* stats_table = base::StatsTable::current();
    if (stats_table &&
        base::SharedMemory::IsHandleValid(
            stats_table->GetSharedMemoryHandle())) {
      files_to_register.push_back(
          FileDescriptorInfo(kStatsTableSharedMemFd,
                             stats_table->GetSharedMemoryHandle()));
    }
#endif

#if defined(OS_ANDROID)
    // Android WebView runs in single process, ensure that we never get here
    // when running in single process mode.
    CHECK(!cmd_line->HasSwitch(switches::kSingleProcess));
    //ContentBrowserClient，browser进程创建的对象，以后分析browser进程会讲到
    //添加额外的映射文件描述符给files_to_register
    GetContentClient()->browser()->
        GetAdditionalMappedFilesForChildProcess(*cmd_line, child_process_id,
                                                &files_to_register);
    //启动render进程
    StartChildProcess(cmd_line->argv(), child_process_id, files_to_register,
        base::Bind(&ChildProcessLauncher::Context::OnChildProcessStarted,
                   this_object, client_thread_id, begin_launch_time));

#elif defined(OS_POSIX)
 ...
#if !defined(OS_MACOSX)
  ...
#if !defined(OS_MACOSX)
     ...
#endif  // defined(OS_MACOSX)

    ...
#if defined(OS_MACOSX)
     ...
#endif  // defined(OS_MACOSX)

     ...
#endif  // defined(OS_MACOSX)
    ...
#endif  // else defined(OS_POSIX)
#if !defined(OS_ANDROID)
 ...
#if defined(OS_POSIX) && !defined(OS_MACOSX)
        ...
#endif
        ...
#endif  // !defined(OS_ANDROID)
  }

       这个函数定义在文件external/chromium_org/content/browser/child_process_launcher.cc中。

       上面有很多宏定义，但是我们只看Android的，核心就是StartChildProcess用来启动Render进程，参数有启动命令行，封装的文件描述符，创建的唯一子进程id，还有OnChildProcessStarted这个回调函数。

       StartChildProcess实现位于external/chromium_org/content/browser/android/child_process_launcher_android.cc中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
void StartChildProcess(
    const CommandLine::StringVector& argv,
    int child_process_id,
    const std::vector<content::FileDescriptorInfo>& files_to_register,
    const StartChildProcessCallback& callback) {
  JNIEnv* env = AttachCurrentThread();
  DCHECK(env);

  // Create the Command line String[]
  ScopedJavaLocalRef<jobjectArray> j_argv = ToJavaArrayOfStrings(env, argv);

  size_t file_count = files_to_register.size();
  DCHECK(file_count > 0);

  ScopedJavaLocalRef<jintArray> j_file_ids(env, env->NewIntArray(file_count));
  base::android::CheckException(env);
  jint* file_ids = env->GetIntArrayElements(j_file_ids.obj(), NULL);
  base::android::CheckException(env);
  ScopedJavaLocalRef<jintArray> j_file_fds(env, env->NewIntArray(file_count));
  base::android::CheckException(env);
  jint* file_fds = env->GetIntArrayElements(j_file_fds.obj(), NULL);
  base::android::CheckException(env);
  ScopedJavaLocalRef<jbooleanArray> j_file_auto_close(
      env, env->NewBooleanArray(file_count));
  base::android::CheckException(env);
  jboolean* file_auto_close =
      env->GetBooleanArrayElements(j_file_auto_close.obj(), NULL);
  base::android::CheckException(env);
  for (size_t i = 0; i < file_count; ++i) {
    const content::FileDescriptorInfo& fd_info = files_to_register[i];
    file_ids[i] = fd_info.id;
    file_fds[i] = fd_info.fd.fd;
    file_auto_close[i] = fd_info.fd.auto_close;
  }
  env->ReleaseIntArrayElements(j_file_ids.obj(), file_ids, 0);
  env->ReleaseIntArrayElements(j_file_fds.obj(), file_fds, 0);
  env->ReleaseBooleanArrayElements(j_file_auto_close.obj(), file_auto_close, 0);

  Java_ChildProcessLauncher_start(env,
      base::android::GetApplicationContext(),
      j_argv.obj(),
      child_process_id,
      j_file_ids.obj(),
      j_file_fds.obj(),
      j_file_auto_close.obj(),
      reinterpret_cast<intptr_t>(new StartChildProcessCallback(callback)));
}

       其实就是将参数封装成jni类型的对象，然后反调Java层对应的方法。依然是启动命令行，封装的文件描述符，创建的唯一子进程id，还有OnChildProcessStarted这个回调函数。

       反调Java层实现位于external/chromium_org/content/public/android/java/src/org/chromium/content/browser/ChildProcessLauncher.java中，调用它的start方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
/**
     * Spawns and connects to a child process. May be called on any thread. It will not block, but
     * will instead callback to {@link #nativeOnChildProcessStarted} when the connection is
     * established. Note this callback will not necessarily be from the same thread (currently it
     * always comes from the main thread).
     *
     * @param context Context used to obtain the application context.
     * @param commandLine The child process command line argv.
     * @param fileIds The ID that should be used when mapping files in the created process.
     * @param fileFds The file descriptors that should be mapped in the created process.
     * @param fileAutoClose Whether the file descriptors should be closed once they were passed to
     * the created process.
     * @param clientContext Arbitrary parameter used by the client to distinguish this connection.
     */
    @CalledByNative
    static void start(
            Context context,
            final String[] commandLine,
            int childProcessId,
            int[] fileIds,
            int[] fileFds,
            boolean[] fileAutoClose,
            long clientContext) {
        TraceEvent.begin();
        assert fileIds.length == fileFds.length && fileFds.length == fileAutoClose.length;
        //将UNIX Socket的Client端描述符取出来封装
        FileDescriptorInfo[] filesToBeMapped = new FileDescriptorInfo[fileFds.length];
        for (int i = 0; i < fileFds.length; i++) {
            filesToBeMapped[i] =
                    new FileDescriptorInfo(fileIds[i], fileFds[i], fileAutoClose[i]);
        }
        assert clientContext != 0;

        int callbackType = CALLBACK_FOR_UNKNOWN_PROCESS;
        boolean inSandbox = true;
        String processType = getSwitchValue(commandLine, SWITCH_PROCESS_TYPE);
        if (SWITCH_RENDERER_PROCESS.equals(processType)) {//我们创建的是render进程
            callbackType = CALLBACK_FOR_RENDERER_PROCESS;
        } else if (SWITCH_GPU_PROCESS.equals(processType)) {
            callbackType = CALLBACK_FOR_GPU_PROCESS;
        } else if (SWITCH_PPAPI_BROKER_PROCESS.equals(processType)) {
            inSandbox = false;
        }

        ChildProcessConnection allocatedConnection = null;
        synchronized (ChildProcessLauncher.class) {
            if (inSandbox) {//true
                allocatedConnection = sSpareSandboxedConnection;
                sSpareSandboxedConnection = null;
            }
        }
        if (allocatedConnection == null) {//会创建一个ChildProcessConnection对象
            allocatedConnection = allocateBoundConnection(context, commandLine, inSandbox);
            if (allocatedConnection == null) {
                // Notify the native code so it can free the heap allocated callback.
                nativeOnChildProcessStarted(clientContext, 0);
                Log.e(TAG, "Allocation of new service failed.");
                TraceEvent.end();
                return;
            }
        }

        Log.d(TAG, "Setting up connection to process: slot=" +
                allocatedConnection.getServiceNumber());
        //出发连接browser进程和render进程，就是利用socket
        triggerConnectionSetup(allocatedConnection, commandLine, childProcessId, filesToBeMapped,
                callbackType, clientContext);
        TraceEvent.end();
    }

       1）将UNIX Socket的Client端描述符取出来封装成FileDescriptorInfo，塞进filesToBeMapped数组；
       2）processType类型为renderer，因此inSandbox为true。
       3）调用allocateBoundConnection方法创建一个ChildProcessConnection对象。这一步其实就创建了ChildProcessService这个沙箱进程，是一个Service进程，我们接下来分析；
       4）triggerConnectionSetup会把将UNIX Socket的Client端fd送给render进程保存，这样就可以和browser进程通信了。

       我们先看第三部allocateBoundConnection实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
private static ChildProcessConnection allocateBoundConnection(Context context,
            String[] commandLine, boolean inSandbox) {
        ChromiumLinkerParams chromiumLinkerParams = getLinkerParamsForNewConnection();
        ChildProcessConnection connection =
                allocateConnection(context, inSandbox, chromiumLinkerParams);
        if (connection != null) {
            connection.start(commandLine);
        }
        return connection;
    }
private static ChromiumLinkerParams getLinkerParamsForNewConnection() {
        if (!sLinkerInitialized) {
            if (Linker.isUsed()) {
                sLinkerLoadAddress = Linker.getBaseLoadAddress();
                if (sLinkerLoadAddress == 0) {
                    Log.i(TAG, "Shared RELRO support disabled!");
                }
            }
            sLinkerInitialized = true;
        }

        if (sLinkerLoadAddress == 0)
            return null;

        // Always wait for the shared RELROs in service processes.
        final boolean waitForSharedRelros = true;
        return new ChromiumLinkerParams(sLinkerLoadAddress,
                                waitForSharedRelros,
                                Linker.getTestRunnerClassName());
    }

       首先调用getLinkerParamsForNewConnection获取动态链接的参数，这里使用的是RELRO(Relocation Read Only)技术。

       在Linux系统安全领域数据可以写的存储区就会是攻击的目标,尤其是存储函数指针的区域. 所以在安全防护的角度来说尽量减少可写的存储区域对安全会有极大的好处.
       GCC, GNU linker以及Glibc-dynamic linker一起配合实现了一种叫做relro的技术: read only relocation.大概实现就是由linker指定binary的一块经过dynamic linker处理过 relocation之后的区域为只读.
       relro是一种比较古老的技术,至少2008年之前就已经进入了upstream.所以本文涉及到的GNU toolchains源代码版本来说选择非常自由,我使用的是我熟悉的版本: GCC-4.8.2 & binutils/ld-2.26 & eglibc-2.19

       就不仔细看代码，里面无非就是和RELRO相关的so库的加载。

       接着调用allocateConnection创建一个ChildProcessConnection对象：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// Service class for child process. As the default value it uses SandboxedProcessService0 and
    // PrivilegedProcessService0.
    private static final ChildConnectionAllocator sSandboxedChildConnectionAllocator =
            new ChildConnectionAllocator(true);
    private static final ChildConnectionAllocator sPrivilegedChildConnectionAllocator =
            new ChildConnectionAllocator(false);

    private static boolean sConnectionAllocated = false;
    
private static ChildProcessConnection allocateConnection(Context context,
            boolean inSandbox, ChromiumLinkerParams chromiumLinkerParams) {
        ChildProcessConnection.DeathCallback deathCallback =
            new ChildProcessConnection.DeathCallback() {
                @Override
                public void onChildProcessDied(ChildProcessConnection connection) {
                    if (connection.getPid() != 0) {
                        stop(connection.getPid());
                    } else {
                        freeConnection(connection);
                    }
                }
            };
        sConnectionAllocated = true;
        //其实是创建一个ChildConnectionAllocator对象，构造函数的参数为true
        //然后调用ChildConnectionAllocator的allocate方法创建一个ChildProcessConnection对象
        return getConnectionAllocator(inSandbox).allocate(context, deathCallback,
                chromiumLinkerParams);
    }

       其实是创建一个ChildConnectionAllocator对象，构造函数的参数为true，然后调用ChildConnectionAllocator的allocate方法创建一个ChildProcessConnection对象。

       ChildConnectionAllocator的构造函数和allocate方法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

    // The upper limit on the number of simultaneous sandboxed and privileged child service process
    // instances supported. Each limit must not exceed total number of SandboxedProcessServiceX
    // classes and PrivilegedProcessServiceX classes declared in this package and defined as
    // services in the embedding application's manifest file.
    // (See {@link ChildProcessService} for more details on defining the services.)
    /* package */ static final int MAX_REGISTERED_SANDBOXED_SERVICES = 13;
    /* package */ static final int MAX_REGISTERED_PRIVILEGED_SERVICES = 3;
    
public ChildConnectionAllocator(boolean inSandbox) {
            //13
            int numChildServices = inSandbox ?
                    MAX_REGISTERED_SANDBOXED_SERVICES : MAX_REGISTERED_PRIVILEGED_SERVICES;
            mChildProcessConnections = new ChildProcessConnectionImpl[numChildServices];
            //创建一个mFreeConnectionIndices对象池，最大容量为13
            mFreeConnectionIndices = new ArrayList<Integer>(numChildServices);
            for (int i = 0; i < numChildServices; i++) {
                mFreeConnectionIndices.add(i);
            }
            //inSandbox为true，所以mChildClass为SandboxedProcessService.class
            setServiceClass(inSandbox ?
                    SandboxedProcessService.class : PrivilegedProcessService.class);
            mInSandbox = inSandbox;
        }

        public void setServiceClass(Class<? extends ChildProcessService> childClass) {
            mChildClass = childClass;
        }

        public ChildProcessConnection allocate(
                Context context, ChildProcessConnection.DeathCallback deathCallback,
                ChromiumLinkerParams chromiumLinkerParams) {
            synchronized (mConnectionLock) {
                if (mFreeConnectionIndices.isEmpty()) {
                    Log.w(TAG, "Ran out of service.");
                    return null;
                }
                //从池中取出一个对象
                int slot = mFreeConnectionIndices.remove(0);
                assert mChildProcessConnections[slot] == null;
                //然后创建一个ChildProcessConnectionImpl对象，并返回
                mChildProcessConnections[slot] = new ChildProcessConnectionImpl(context, slot,
                        mInSandbox, deathCallback, mChildClass, chromiumLinkerParams);
                return mChildProcessConnections[slot];
            }
        }

       可以看到ChildConnectionAllocator构造方法中创建一个mFreeConnectionIndices对象池，因为参数inSandbox为true，所以我们创建的是一个沙箱进程，最大容量为13，所以最多可以有13个render进程。由于inSandbox为true，所以mChildClass为SandboxedProcessService.class，接下来启动的Service对象进程的class就是SandboxedProcessService。

       allocate方法就是从池中取出一个对象，然后创建一个ChildProcessConnectionImpl对象，然后将对应slot标记的变量赋值，并返回。

       回到allocateBoundConnection方法中，接着调用刚才返回的ChildProcessConnectionImpl对象的start方法，位于external/chromium_org/content/public/android/java/src/org/chromium/content/browser/ChildProcessConnectionImpl.java：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
ChildProcessConnectionImpl(Context context, int number, boolean inSandbox,
            ChildProcessConnection.DeathCallback deathCallback,
            Class<? extends ChildProcessService> serviceClass,
            ChromiumLinkerParams chromiumLinkerParams) {
        mContext = context;
        mServiceNumber = number;
        mInSandbox = inSandbox;
        mDeathCallback = deathCallback;
        mServiceClass = serviceClass;
        mLinkerParams = chromiumLinkerParams;
        mInitialBinding = new ChildServiceConnection(Context.BIND_AUTO_CREATE);
        mStrongBinding = new ChildServiceConnection(
                Context.BIND_AUTO_CREATE | Context.BIND_IMPORTANT);
        mWaivedBinding = new ChildServiceConnection(
                Context.BIND_AUTO_CREATE | Context.BIND_WAIVE_PRIORITY);
    }

 @Override
    public void start(String[] commandLine) {
        synchronized (mLock) {
            TraceEvent.begin();
            assert !ThreadUtils.runningOnUiThread();
            assert mConnectionParams == null :
                    "setupConnection() called before start() in ChildProcessConnectionImpl.";
            //mInitialBinding.bind在构造函数中初始化过了，为ChildServiceConnection对象
            //调用ChildServiceConnection的bind方法
            if (!mInitialBinding.bind(commandLine)) {
                Log.e(TAG, "Failed to establish the service connection.");
                // We have to notify the caller so that they can free-up associated resources.
                // TODO(ppi): Can we hard-fail here?
                mDeathCallback.onChildProcessDied(ChildProcessConnectionImpl.this);
            } else {
                mWaivedBinding.bind(null);
            }
            TraceEvent.end();
        }
    }

       ChildProcessConnectionImpl的构造方法对mInitialBinding进行初始化，是一个ChildServiceConnection对象。接着start方法中调用mInitialBinding的bind方法。我们继续看ChildServiceConnection的bind方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
private Intent createServiceBindIntent() {
            Intent intent = new Intent();
            //mServiceClass类型为SandboxedProcessService，上面提过
            intent.setClassName(mContext, mServiceClass.getName() + mServiceNumber);
            intent.setPackage(mContext.getPackageName());
            return intent;
        }

        public ChildServiceConnection(int bindFlags) {
            mBindFlags = bindFlags;
        }

        boolean bind(String[] commandLine) {
            if (!mBound) {
                TraceEvent.begin();
                final Intent intent = createServiceBindIntent();
                if (commandLine != null) {//将命令行放入intent的extras
                    intent.putExtra(EXTRA_COMMAND_LINE, commandLine);
                }
                if (mLinkerParams != null)//将链接参数也放进去
                    mLinkerParams.addIntentExtras(intent);
                //然后启动SandboxedProcessService这个render进程
                mBound = mContext.bindService(intent, this, mBindFlags);
                TraceEvent.end();
            }
            return mBound;
        }

       bind函数首先创建Service进程的Intent，我们上面知道他的类型为SandboxedProcessService.class，然后将命令行放入intent的extras，再将链接参数也放进去。最后调用Context的bindService函数启动SandboxedProcessService。

       还有第四步，triggerConnectionSetup会把将UNIX Socket的Client端fd送给render进程保存，这样就可以和browser进程通信了。我们放到Render进程启动的第二部分再讲。

       这样我们Render进程启动过程的第一部分就分析完了。

Render进程启动的第二部分

       如果是正常启动一个网页，load一个url，流程是这样的：

loadurl

       render进程是应用程序的子进程，以service的形式提供给应用程序。需要在应用程序的AndroidMenifest.xml中声明render进程中运行的service。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<!-- The following service entries exist in order to allow us to
             start more than one sandboxed process. -->

        <!-- NOTE: If you change the values of "android:process" for any of the below services,
             you also need to update kHelperProcessExecutableName in chrome_constants.cc. -->
        <service android:name="org.chromium.content.app.SandboxedProcessService0"
                 android:process=":sandboxed_process0"
                 android:permission="org.chromium.content_shell.permission.SANDBOX"
                 android:isolatedProcess="true"
                 android:exported="false" />
        <service android:name="org.chromium.content.app.SandboxedProcessService1"
                 android:process=":sandboxed_process1"
                 android:permission="org.chromium.content_shell.permission.SANDBOX"
                 android:isolatedProcess="true"
                 android:exported="false" />
        <service android:name="org.chromium.content.app.SandboxedProcessService2"
                 android:process=":sandboxed_process2"
                 
                 ...

        <service android:name="org.chromium.content.app.SandboxedProcessService12"
                 android:process=":sandboxed_process12"
                 android:permission="org.chromium.content_shell.permission.SANDBOX"
                 android:isolatedProcess="true"
                 android:exported="false" />

       可以看出一共有13个沙箱Service，分别从0～12。那么我们再看看它的继承结构：

ChildProcessService

插个嘴：第一个tab页面

       这里我们插个嘴（后面会讲为什么）：不过有一点我们提前注意，SandboxedProcessService0的创建过程是由ChildProcessLauncher的warmUp方法触发的，并非start方法。warmUp方法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/**
 * Should be called early in startup so the work needed to spawn the child process can be done
 * in parallel to other startup work. Must not be called on the UI thread. Spare connection is
 * created in sandboxed child process.
 * @param context the application context used for the connection.
 */
public static void warmUp(Context context) {
    synchronized (ChildProcessLauncher.class) {
        assert !ThreadUtils.runningOnUiThread();
        if (sSpareSandboxedConnection == null) {
            sSpareSandboxedConnection = allocateBoundConnection(context, null, true);
        }
    }
}

       应用程序调用warmUp触发的ChildProcessService的创建过程：

warmUp

       再次插个嘴（后面会讲为什么）：并且SandboxedProcessService0创建时候，ChildProcessService的onCreate方法中并没有触发到底层process的创建，即ChildProcessService的onCreate()没有执行到ContentMain.initApplicationContext，就被阻塞了。

       创建第一个tab时候，render进程的更通用的创建方式是由native层的ChildProcessLauncher(定义在child_process_launcher.cc中)回调java层的ChildProcessLauncher的Start方法触发的。

       第三次插个嘴（后面会讲为什么）ChildProcessLauncher.start函数在第一次调用时，由于SandboxedProcessService0已经创建，并阻塞在ChildProcessService的onCreate方法中，所以ChildProcessLauncher.start使ChildProcessService的onCreate方法在上次warmUp调用时序阻塞的地方notify了，即阻塞接触了，完成了render进程的创建。

第二个tab页

       在创建第二个Tab时，SandboxedProcessService1的创建是由以下调用触发的：

  1. ChildProcessLauncher.start函数调用allocateBoundConnection，
  2. allocateBoundConnection调用allocateConnection生成一个ChildProcessConnection实例。
  3. allocateBoundConnection调用新生成的ChildProcessConnection的bind方法，
  4. ChildProcessConnection的bind调用Context::bindService()，
  5. bindService触发SandboxedProcessService1的onCreate方法。
  6. SandboxedProcessService1是ChildProcessService的基类，从ChildProcessService继承onCreate方法。
  7. 所以实际执行的是ChildProcessService::onCreate。

       由于第一个tab页流程有些乱，所以我们选第二个tab页流程分析，也正好解答第一个tab页插嘴不明白的地方。

       从render进程启动第一部分得知，使用Context的bindService启动的ChildProcessService，因此会触发ServiceConnection的onServiceConnected方法。对应的是ChildServiceConnection类对象，依然位于external/chromium_org/content/public/android/java/src/org/chromium/content/browser/ChildProcessConnectionImpl.java：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

private class ChildServiceConnection implements ServiceConnection {
   

    @Override
    public void onServiceConnected(ComponentName className, IBinder service) {
        synchronized (mLock) {//这个同步锁是为了保证和第一部分第4步骤的triggerConnectionSetup排队执行
            // A flag from the parent class ensures we run the post-connection logic only once
            // (instead of once per each ChildServiceConnection).
            if (mServiceConnectComplete) {
                return;
            }
            TraceEvent.begin();
            //bindService之后将mServiceConnectComplete置为true
            mServiceConnectComplete = true;
            //拿到远端Serivice的ChildProcessService的binder代理
            mService = IChildProcessService.Stub.asInterface(service);
            // Run the setup if the connection parameters have already been provided. If not,
            // doConnectionSetupLocked() will be called from setupConnection().
            //此时可能第一部分第4步骤的triggerConnectionSetup 会调用setupConnection还没有调用
            //triggerConnectionSetup里面会给mConnectionParams赋值
            //但如果没有调用，就不会继续调用doConnectionSetupLocked了
            if (mConnectionParams != null) {
                doConnectionSetupLocked();
            }
            TraceEvent.end();
        }
    }

}

       1）onServiceConnected方法里首先将mServiceConnectComplete置为true；
       2）拿到远端Serivice的ChildProcessService的binder代理，赋值给mService变量；
       3）由于synchronized (mLock)同步锁，锁住了代码块，而第一部分第4步骤的triggerConnectionSetup 同样用mLock这个同步锁，所以可能第一部分第4步骤的triggerConnectionSetup 会调用setupConnection还没有调用，triggerConnectionSetup里面会给mConnectionParams赋值，但如果没有调用，就不会继续调用doConnectionSetupLocked了。

       我们把doConnectionSetupLocked放到triggerConnectionSetup流程。好的，我们继续分析第一部分第4步骤的triggerConnectionSetup的实现，回到ChildProcessLauncher中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
@VisibleForTesting
    static void triggerConnectionSetup(
            final ChildProcessConnection connection,
            String[] commandLine,
            int childProcessId,
            FileDescriptorInfo[] filesToBeMapped,
            int callbackType,
            final long clientContext) {
        //创建一个ConnectionCallback
        ChildProcessConnection.ConnectionCallback connectionCallback =
                new ChildProcessConnection.ConnectionCallback() {
                    @Override
                    public void onConnected(int pid) {
                        Log.d(TAG, "on connect callback, pid=" + pid + " context=" + clientContext);
                        if (pid != NULL_PROCESS_HANDLE) {
                            sBindingManager.addNewConnection(pid, connection);
                            sServiceMap.put(pid, connection);
                        }
                        // If the connection fails and pid == 0, the Java-side cleanup was already
                        // handled by DeathCallback. We still have to call back to native for
                        // cleanup there.
                        if (clientContext != 0) {  // Will be 0 in Java instrumentation tests.
                            nativeOnChildProcessStarted(clientContext, pid);
                        }
                    }
                };

        // TODO(sievers): Revisit this as it doesn't correctly handle the utility process
        // assert callbackType != CALLBACK_FOR_UNKNOWN_PROCESS;
        //然后调用ChildProcessConnectionImpl的setupConnection方法
        connection.setupConnection(commandLine,
                                   filesToBeMapped,
                                   createCallback(childProcessId, callbackType),
                                   connectionCallback,
                                   Linker.getSharedRelros());
    }

       先创建一个ConnectionCallback，然后调用ChildProcessConnectionImpl的setupConnection方法，并把filesToBeMapped代表的IPC Socket client端的fd，connectionCallback作为参数穿进去。

       ChildProcessConnectionImpl的setupConnection方法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
@Override
    public void setupConnection(
            String[] commandLine,
            FileDescriptorInfo[] filesToBeMapped,
            IChildProcessCallback processCallback,
            ConnectionCallback connectionCallback,
            Bundle sharedRelros) {
        synchronized (mLock) {
            assert mConnectionParams == null;//null
            if (mServiceDisconnected) {
                Log.w(TAG, "Tried to setup a connection that already disconnected.");
                connectionCallback.onConnected(0);
                return;
            }

            TraceEvent.begin();
            //将上一步创建的ConnectionCallback赋给mConnectionCallback
            mConnectionCallback = connectionCallback;
            //创建一个ConnectionParams赋给mConnectionParams
            mConnectionParams = new ConnectionParams(
                    commandLine, filesToBeMapped, processCallback, sharedRelros);
            // Run the setup if the service is already connected. If not, doConnectionSetupLocked()
            // will be called from onServiceConnected().
            //true 就会调用doConnectionSetupLocked
            if (mServiceConnectComplete) {
                doConnectionSetupLocked();
            }
            TraceEvent.end();
        }
    }

       1）我们看到setupConnection和上一步的onServiceConnected持有的是同一把锁mLock。
       2）接着就是将上一步创建的ConnectionCallback赋给mConnectionCallback；
       3）然后创建一个ConnectionParams赋给mConnectionParams。这个很重要，我们之前说ChildProcessLauncher的warmUp方法启动ChildProcessService会在onCreate中阻塞，就是因为mConnectionParams为null，先提前告你，等会儿分析。
       4）如果mServiceConnectComplete为true，表示onServiceConnected先抢到了同步锁，因此这里执行doConnectionSetupLocked方法。

       我们接着看doConnectionSetupLocked方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
/**
     * Called after the connection parameters have been set (in setupConnection()) *and* a
     * connection has been established (as signaled by onServiceConnected()). These two events can
     * happen in any order. Has to be called with mLock.
     */
    private void doConnectionSetupLocked() {
        TraceEvent.begin();
        assert mServiceConnectComplete && mService != null;
        assert mConnectionParams != null;

        Bundle bundle = new Bundle();
        //塞进启动命令行
        bundle.putStringArray(EXTRA_COMMAND_LINE, mConnectionParams.mCommandLine);

        //下面是塞进IPC Socket 文件描述符相关
        FileDescriptorInfo[] fileInfos = mConnectionParams.mFilesToBeMapped;
        ParcelFileDescriptor[] parcelFiles = new ParcelFileDescriptor[fileInfos.length];
        for (int i = 0; i < fileInfos.length; i++) {
            if (fileInfos[i].mFd == -1) {
                // If someone provided an invalid FD, they are doing something wrong.
                Log.e(TAG, "Invalid FD (id=" + fileInfos[i].mId + ") for process connection, "
                      + "aborting connection.");
                return;
            }
            String idName = EXTRA_FILES_PREFIX + i + EXTRA_FILES_ID_SUFFIX;
            String fdName = EXTRA_FILES_PREFIX + i + EXTRA_FILES_FD_SUFFIX;
            if (fileInfos[i].mAutoClose) {
                // Adopt the FD, it will be closed when we close the ParcelFileDescriptor.
                parcelFiles[i] = ParcelFileDescriptor.adoptFd(fileInfos[i].mFd);
            } else {
                try {
                    parcelFiles[i] = ParcelFileDescriptor.fromFd(fileInfos[i].mFd);
                } catch (IOException e) {
                    Log.e(TAG,
                          "Invalid FD provided for process connection, aborting connection.",
                          e);
                    return;
                }

            }
            bundle.putParcelable(fdName, parcelFiles[i]);
            bundle.putInt(idName, fileInfos[i].mId);
        }
        // Add the CPU properties now.
        //塞进cpu属性相关
        bundle.putInt(EXTRA_CPU_COUNT, CpuFeatures.getCount());
        bundle.putLong(EXTRA_CPU_FEATURES, CpuFeatures.getMask());
        //塞进RELROS技术相关内容
        bundle.putBundle(Linker.EXTRA_LINKER_SHARED_RELROS,
                         mConnectionParams.mSharedRelros);

        try {
            //通过这个ChildProcessService的Binder代理，调用远程服务的setupConnection方法，并把刚才塞进bundle的相关内容传递到render进程
            //返回的是render进程的pid
            mPid = mService.setupConnection(bundle, mConnectionParams.mCallback);
            assert mPid != 0 : "Child service claims to be run by a process of pid=0.";
        } catch (android.os.RemoteException re) {
            Log.e(TAG, "Failed to setup connection.", re);
        }
        // We proactively close the FDs rather than wait for GC & finalizer.
        try {
            for (ParcelFileDescriptor parcelFile : parcelFiles) {
                if (parcelFile != null) parcelFile.close();
            }
        } catch (IOException ioe) {
            Log.w(TAG, "Failed to close FD.", ioe);
        }
        mConnectionParams = null;
        
        //mConnectionCallback就是刚才triggerConnectionSetup中创建的connectionCallback
        if (mConnectionCallback != null) {//然后执行connectionCallback的onConnected方法，参数为render进程的pid
            mConnectionCallback.onConnected(mPid);
        }
        mConnectionCallback = null;
        TraceEvent.end();
    }

       Browser进程和Render进程需要IPC通信，所以需要把相关参数塞进Bundle中，然后传给Render进程。

       因此先创建一个Bundle对象，然后塞进启动命令行，塞进IPC Socket 文件描述符相关，在塞进其他，最后通过全局变量mServicce这个ChildProcessService的Binder代理，调用远程服务的setupConnection方法，并把刚才塞进bundle的相关内容传递到render进程，返回render进程的pid。最后执行connectionCallback的onConnected方法，参数为render进程的pid。

       1）我们先看看通过全局变量mServicce这个ChildProcessService的Binder代理，调用远程服务的setupConnection方法，位于external/chromium_org/content/public/android/java/src/org/chromium/content/app/ChildProcessService.java：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
// Binder object used by clients for this service.
    private final IChildProcessService.Stub mBinder = new IChildProcessService.Stub() {
        // NOTE: Implement any IChildProcessService methods here.
        @Override
        public int setupConnection(Bundle args, IChildProcessCallback callback) {
            mCallback = callback;
            synchronized (mMainThread) {
                // Allow the command line to be set via bind() intent or setupConnection, but
                // the FD can only be transferred here.
                //获取命令行参数
                if (mCommandLineParams == null) {
                    mCommandLineParams = args.getStringArray(
                            ChildProcessConnection.EXTRA_COMMAND_LINE);
                }
                // We must have received the command line by now
                assert mCommandLineParams != null;
                //cpu count
                mCpuCount = args.getInt(ChildProcessConnection.EXTRA_CPU_COUNT);
                // cpu features
                mCpuFeatures = args.getLong(ChildProcessConnection.EXTRA_CPU_FEATURES);
                assert mCpuCount > 0;
                mFileIds = new ArrayList<Integer>();
                mFileFds = new ArrayList<ParcelFileDescriptor>();
                //获取IPC Socket Client相关文件描述符
                for (int i = 0;; i++) {
                    String fdName = ChildProcessConnection.EXTRA_FILES_PREFIX + i
                            + ChildProcessConnection.EXTRA_FILES_FD_SUFFIX;
                    ParcelFileDescriptor parcel = args.getParcelable(fdName);
                    if (parcel == null) {
                        // End of the file list.
                        break;
                    }
                    mFileFds.add(parcel);
                    String idName = ChildProcessConnection.EXTRA_FILES_PREFIX + i
                            + ChildProcessConnection.EXTRA_FILES_ID_SUFFIX;
                    mFileIds.add(args.getInt(idName));
                }
                //RELROS相关技术属性
                Bundle sharedRelros = args.getBundle(Linker.EXTRA_LINKER_SHARED_RELROS);
                if (sharedRelros != null) {
                    Linker.useSharedRelros(sharedRelros);
                    sharedRelros = null;
                }
                //唤醒阻塞ChildProcessService onCreate重的睡眠，后面会讲到
                mMainThread.notifyAll();
            }
            //返回render进程的pid
            return Process.myPid();
        }

       
    };

       ChildProcessService的Binder代理的setupConnection会依次获取从Browser进程传递过来的命令行参数、cpu count、cpu features、IPC Socket Client相关文件描述符、RELROS相关技术属性，然后唤醒阻塞ChildProcessService onCreate重的睡眠，后面会讲到，最后返回render进程的pid。

       2）再看看执行connectionCallback的onConnected方法，参数为render进程的pid。从上面得知ConnectionCallback定义如下，位于external/chromium_org/content/public/android/java/src/org/chromium/content/browser/ChildProcessLauncher.java：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
ChildProcessConnection.ConnectionCallback connectionCallback =
                new ChildProcessConnection.ConnectionCallback() {
                    @Override
                    public void onConnected(int pid) {
                        Log.d(TAG, "on connect callback, pid=" + pid + " context=" + clientContext);
                        if (pid != NULL_PROCESS_HANDLE) {
                            sBindingManager.addNewConnection(pid, connection);
                            sServiceMap.put(pid, connection);
                        }
                        // If the connection fails and pid == 0, the Java-side cleanup was already
                        // handled by DeathCallback. We still have to call back to native for
                        // cleanup there.
                        if (clientContext != 0) {  // Will be 0 in Java instrumentation tests.
                            nativeOnChildProcessStarted(clientContext, pid);
                        }
                    }
                };

    private static native void nativeOnChildProcessStarted(long clientContext, int pid);

       忽略其他，只看nativeOnChildProcessStarted这方法，它是一个native方法。通过上面child_process_launcher的Launch函数的值，这个native犯法最终会通过JNI调用child_process_launcher的OnChildProcessStarted函数。位于external/chromium_org/content/browser/child_process_launcher.cc：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#if defined(OS_ANDROID)
  static void OnChildProcessStarted(
      // |this_object| is NOT thread safe. Only use it to post a task back.
      scoped_refptr<Context> this_object,
      BrowserThread::ID client_thread_id,
      const base::TimeTicks begin_launch_time,
      base::ProcessHandle handle) {
    RecordHistograms(begin_launch_time);
    if (BrowserThread::CurrentlyOn(client_thread_id)) {
      // This is always invoked on the UI thread which is commonly the
      // |client_thread_id| so we can shortcut one PostTask.
      this_object->Notify(handle);
    } else {
      BrowserThread::PostTask(
          client_thread_id, FROM_HERE,
          base::Bind(
              &ChildProcessLauncher::Context::Notify,
              this_object,
              handle));
    }
  }
#endif

       如果实在当前线程，就直接执行Notify函数，否则就把它发到指定线程去执行。Notify定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
  void Notify(
#if defined(OS_POSIX) && !defined(OS_MACOSX) && !defined(OS_ANDROID)
      bool zygote,
#endif
      base::ProcessHandle handle) {
#if defined(OS_ANDROID)
    // Finally close the ipcfd
    base::ScopedFD ipcfd_closer(ipcfd_);
#endif
    starting_ = false;
    process_.set_handle(handle);
    if (!handle)
      LOG(ERROR) << "Failed to launch child process";

#if defined(OS_POSIX) && !defined(OS_MACOSX) && !defined(OS_ANDROID)
    zygote_ = zygote;
#endif
    if (client_) {
      if (handle) {
        client_->OnProcessLaunched();
      } else {
        client_->OnProcessLaunchFailed();
      }
    } else {
      Terminate();
    }
  }

       最后和非独立进程Render的最后一步一样，调用OnProcessLaunched，是一个fake的通知。这一步就不用管了。

       这些传递给Render进程相关参数的工作做完了，就改继续看看Render进程启动的Service类的流程了，即ChildProcessService类绑定过程。

ChildProcessService类绑定过程

       Service启动先走onCreate，我们看看ChildProcessService的onCreate方法，位于external/chromium_org/content/public/android/java/src/org/chromium/content/app/ChildProcessService.java：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
@Override
    public void onCreate() {
        Log.i(TAG, "Creating new ChildProcessService pid=" + Process.myPid());
        if (sContext.get() != null) {
            Log.e(TAG, "ChildProcessService created again in process!");
        }
        sContext.set(this);
        super.onCreate();
        //创建一个线程
        mMainThread = new Thread(new Runnable() {
            @Override
            public void run()  {
                try {
                    //RELRO技术相关
                    boolean useLinker = Linker.isUsed();
                    if (useLinker) {
                        synchronized (mMainThread) {
                            while (!mIsBound) {
                                mMainThread.wait();
                            }
                        }
                        if (mLinkerParams != null) {
                            if (mLinkerParams.mWaitForSharedRelro)
                                Linker.initServiceProcess(mLinkerParams.mBaseLoadAddress);
                            else
                                Linker.disableSharedRelros();

                            Linker.setTestRunnerClassName(mLinkerParams.mTestRunnerClassName);
                        }
                    }
                    
                    try {
                        //加载chromuim相关的so，比如webview相关的
                        //并且会出发JNI_OnLoad函数
                        //这一步会向ContentMain注册ContentMainDelegate
                        LibraryLoader.loadNow(getApplicationContext(), false);
                    } catch (ProcessInitException e) {
                        Log.e(TAG, "Failed to load native library, exiting child process", e);
                        System.exit(-1);
                    }
                    synchronized (mMainThread) {
                        //之前讲过，ChildProcessLauncher的warmUp启动时候，
                        //会在onCreate方法中阻塞，
                        //就是因为warmUp中没有给mCommandLineParams赋值，为null
                        while (mCommandLineParams == null) {
                            mMainThread.wait();
                        }
                    }
                    LibraryLoader.initialize(mCommandLineParams);
                    synchronized (mMainThread) {
                        mLibraryInitialized = true;
                        mMainThread.notifyAll();
                        while (mFileIds == null) {
                            mMainThread.wait();
                        }
                    }
                    //然后取出IPC Socket Client的文件描述符
                    assert mFileIds.size() == mFileFds.size();
                    int[] fileIds = new int[mFileIds.size()];
                    int[] fileFds = new int[mFileFds.size()];
                    for (int i = 0; i < mFileIds.size(); ++i) {
                        fileIds[i] = mFileIds.get(i);
                        fileFds[i] = mFileFds.get(i).detachFd();
                    }
//初始化所有类型进程                    ContentMain.initApplicationContext(sContext.get().getApplicationContext());
//将所有的客户端IPC 的fd保存起来，就是第一部分分析的独立render进程启动时候保存
//IPC client的base::GlobalDescriptors::GetInstance()                  nativeInitChildProcess(sContext.get().getApplicationContext(),
                            ChildProcessService.this, fileIds, fileFds,
                            mCpuCount, mCpuFeatures);
                    //这一步会讲IPC client的fd取出封装成ChannelProxy        
                    ContentMain.start();
                    //上一步消息循环会轮训，因此退出消息循环就会退render进程
                    nativeExitChildProcess();
                } catch (InterruptedException e) {
                    Log.w(TAG, MAIN_THREAD_NAME + " startup failed: " + e);
                } catch (ProcessInitException e) {
                    Log.w(TAG, MAIN_THREAD_NAME + " startup failed: " + e);
                }
            }
        }, MAIN_THREAD_NAME);
        mMainThread.start();
    }

       我们看到在Service进程里先起了一个线程，然后直接start。
       1）检测RELRO技术相关库和链接是否成功，如果不ok就要等待；
       2）加载chromuim相关的so，比如webview相关的，并且会出发JNI_OnLoad函数，这一步会向ContentMain注册ContentMainDelegate；我们下面会讲到；
       3）之前讲过，ChildProcessLauncher的warmUp启动时候，会在onCreate方法中阻塞，就是因为warmUp中没有给mCommandLineParams赋值，为null；
       4）然后取出IPC Socket Client的文件描述符；
       5）初始化所有类型进程；
       6）将所有的客户端IPC 的fd保存起来，就是第一部分分析的独立render进程启动时候保存；
       7）这一步会讲IPC client的fd取出封装成ChannelProxy ；
       8）上一步消息循环会轮训，因此退出消息循环就会退render进程。

       详细看看第五步后面的内容。
       我们先看看ContentMain的类结构，位于external/chromium_org/content/public/android/java/src/org/chromium/content/app/ContentMain.java：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@JNINamespace("content")
public class ContentMain {
    /**
     * Initialize application context in native side.
     **/
    public static void initApplicationContext(Context context) {
        nativeInitApplicationContext(context);
    }

    /**
     * Start the ContentMainRunner in native side.
     **/
    public static int start() {
        return nativeStart();
    }

    private static native void nativeInitApplicationContext(Context context);
    private static native int nativeStart();
}

       先看看initApplicationContext，C++层调用的是external/chromium_org/content/app/android/content_main.cc：

1
2
3
4
5

static void InitApplicationContext(JNIEnv* env, jclass clazz, jobject context) {
  base::android::ScopedJavaLocalRef<jobject> scoped_context(env, context);
  base::android::InitApplicationContext(env, scoped_context);
}

       就是保存了上层传来的Context，没什么。

       接着看onCreate中的nativeInitChildProcess方法，依然对应C++层external/chromium_org/content/app/android/child_process_service.cc：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
void InitChildProcess(JNIEnv* env,
                      jclass clazz,
                      jobject context,
                      jobject service,
                      jintArray j_file_ids,
                      jintArray j_file_fds,
                      jint cpu_count,
                      jlong cpu_features) {
  std::vector<int> file_ids;
  std::vector<int> file_fds;
  JavaIntArrayToIntVector(env, j_file_ids, &file_ids);
  JavaIntArrayToIntVector(env, j_file_fds, &file_fds);

  InternalInitChildProcess(
      file_ids, file_fds, env, clazz, context, service,
      cpu_count, cpu_features);
}

// Chrome actually uses the renderer code path for all of its child
// processes such as renderers, plugins, etc.
void InternalInitChildProcess(const std::vector<int>& file_ids,
                              const std::vector<int>& file_fds,
                              JNIEnv* env,
                              jclass clazz,
                              jobject context,
                              jobject service_in,
                              jint cpu_count,
                              jlong cpu_features) {
  base::android::ScopedJavaLocalRef<jobject> service(env, service_in);

  // Set the CPU properties.
  android_setCpu(cpu_count, cpu_features);
  // Register the file descriptors.
  // This includes the IPC channel, the crash dump signals and resource related
  // files.
  DCHECK(file_fds.size() == file_ids.size());
  //将所有的客户端IPC 的fd保存起来，就是第一部分分析的独立render进程启动时候保存
  //IPC client的base::GlobalDescriptors::GetInstance() 
  for (size_t i = 0; i < file_ids.size(); ++i)
    base::GlobalDescriptors::GetInstance()->Set(file_ids[i], file_fds[i]);

  // SurfaceTexturePeerChildImpl implements the SurfaceTextureLookup interface,
  // which need to be set before we create a compositor thread that could be
  // using it to initialize resources.
  content::SurfaceTexturePeer::InitInstance(
      new SurfaceTexturePeerChildImpl(service));

  base::android::MemoryPressureListenerAndroid::RegisterSystemCallback(env);
}

       其他内容忽略，我们只关注将所有的客户端IPC 的fd保存起来，就是第一部分分析的独立render进程启动时候保存IPC client的base::GlobalDescriptors::GetInstance()，这样就为接下来创建ChannelProxy Client打下基础了。

       最后再看看ContentMain的start方法，依然对应content_main.cc中的Start函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
//g_content_main_delegate是个单例
LazyInstance<scoped_ptr<ContentMainDelegate> > g_content_main_delegate =
    LAZY_INSTANCE_INITIALIZER;
    
static jint Start(JNIEnv* env, jclass clazz) {
  TRACE_EVENT0("startup", "content::Start");

  // On Android we can have multiple requests to start the browser in process
  // simultaneously. If we get an asynchonous request followed by a synchronous
  // request then we have to call this a second time to finish starting the
  // browser synchronously.
  if (!g_content_runner.Get().get()) {
    //取出g_content_main_delegate
    ContentMainParams params(g_content_main_delegate.Get().get());
    //为g_content_runner赋值
    g_content_runner.Get().reset(ContentMainRunner::Create());
    //调用g_content_runner的Initialize函数
    g_content_runner.Get()->Initialize(params);
  }
  //调用g_content_runner的Run函数
  return g_content_runner.Get()->Run();
}
//在ChildProcessService的onCreate会触发chromium webview相关库加载
//在jni_onLoad中会调用这个函数为g_content_main_delegate赋值
void SetContentMainDelegate(ContentMainDelegate* delegate) {
  DCHECK(!g_content_main_delegate.Get().get());
  g_content_main_delegate.Get().reset(delegate);
}

       上面说到，在ChildProcessService的onCreate会触发chromium webview相关库加载，在jni_onLoad中会调用这个函数为g_content_main_delegate赋值。这个步骤如下图：

JNI_OnLoad

       虚拟机在动态库加载完成后调用全局函数JNI_OnLoad,定义在chrome_jni_onload.cc中。位于external/chromium_org/chrome/app/android/chrome_jni_onload.cc：

1
2
3
JNI_EXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved) {
  return RunChrome(vm, ChromeMainDelegateAndroid::Create());
}

       JNI_OnLoad调用全局函数RunChrome，定义在chrome_android_initializer.cc中，位于

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
jint RunChrome(JavaVM* vm, ChromeMainDelegateAndroid* main_delegate) {
  base::android::InitVM(vm);
  JNIEnv* env = base::android::AttachCurrentThread();
  if (!base::android::RegisterLibraryLoaderEntryHook(env))
    return -1;

  // Pass the library version number to content so that we can check it from the
  // Java side before continuing initialization
  chrome::VersionInfo vi;
  base::android::SetLibraryLoadedHook(&content::LibraryLoaded);
  base::android::SetVersionNumber(vi.Version().c_str());

  DCHECK(main_delegate);
  //我们只关注这一个
  content::SetContentMainDelegate(main_delegate);

  return JNI_VERSION_1_4;
}

       RunChrome调用content命名空间的全局函数SetContentMainDelegate()定义在content_main.cc中。SetContentMainDelegate()将指向ChromeMainDelegateAndroid对象的指针保存到全局变量g_content_main_delegate中。

       回到content_main.cc中，我们因此得知g_content_main_delegate指向的就是ChromeMainDelegateAndroid的对象。

       我们继续往下看，为g_content_runner指针赋值。调用ContentMainRunner的Create函数，这个位于external/chromium_org/content/app/content_main_runner.cc：

1
2
3
4
// static
ContentMainRunner* ContentMainRunner::Create() {
  return new ContentMainRunnerImpl();
}

       创建一个ContentMainRunnerImpl对象。

       接着调用ContentMainRunnerImpl的Initialize函数，虽然这个函数很长，但是对于Android的宏定义不多，核心久一句位于external/chromium_org/content/app/content_main_runner.cc：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
virtual int Initialize(const ContentMainParams& params) OVERRIDE {
    ...

    ContentClientInitializer::Set(process_type, delegate_);

    ...
}

class ContentClientInitializer {
 public:
  static void Set(const std::string& process_type,
                  ContentMainDelegate* delegate) {
    ContentClient* content_client = GetContentClient();
    if (process_type.empty()) {
      if (delegate)
        content_client->browser_ = delegate->CreateContentBrowserClient();
      if (!content_client->browser_)
        content_client->browser_ = &g_empty_content_browser_client.Get();
    }

#if !defined(OS_IOS) && !defined(CHROME_MULTIPLE_DLL_BROWSER)
    if (process_type == switches::kPluginProcess ||
        process_type == switches::kPpapiPluginProcess) {
      if (delegate)
        content_client->plugin_ = delegate->CreateContentPluginClient();
      if (!content_client->plugin_)
        content_client->plugin_ = &g_empty_content_plugin_client.Get();
      // Single process not supported in split dll mode.
    } else if (process_type == switches::kRendererProcess ||
               CommandLine::ForCurrentProcess()->HasSwitch(
                   switches::kSingleProcess)) {
      if (delegate)
        content_client->renderer_ = delegate->CreateContentRendererClient();
      if (!content_client->renderer_)
        content_client->renderer_ = &g_empty_content_renderer_client.Get();
    }

    if (process_type == switches::kUtilityProcess ||
        CommandLine::ForCurrentProcess()->HasSwitch(
            switches::kSingleProcess)) {
      if (delegate)
        content_client->utility_ = delegate->CreateContentUtilityClient();
      // TODO(scottmg): http://crbug.com/237249 Should be in _child.
      if (!content_client->utility_)
        content_client->utility_ = &g_empty_content_utility_client.Get();
    }
#endif  // !OS_IOS && !CHROME_MULTIPLE_DLL_BROWSER
  }
};

       ContentMainRunnerImpl::Initialize接口调用ContentClientInitializer::Set(processtype, delegate)，ContentClientInitializer定义在content_main_runner.cc中，这个类只有一个static方法Set。
       Set方法的职责是调用ContentMainDelegate的相应接口设置ContentClient的实例域ContentBrowserClient，ContentPluginClient,ContentRenderClient,ContentUtilityClient。

       从上面g_content_main_delegate的赋值过程得知，ContentMainDelegate是客户端程序注册给content_main_runner.cc的回调接口，content_main_runner.cc通过调用ContentMainDelegate的接口来通知客户端当前Content框架的状态。
       客户端程序通过ContentMainDelegate::RegisterApplicationNativeMethods接口注册自己的本地方法。
       ContentMainDelegate中的有四个函数：

  • CreateContentBrowserClient();
  • CreateContentPluginClient();
  • CreateContentRendererClient();
  • CreateContentUtilityClient();
    用来分别创建ContentBrowserClient，ContentPlunginClient，ContentRendererClient。就是上面刚才说的那个四个实例。

       这就是ContentMainRunnerImpl的Initialize函数的作用。

       我们接着看ContentMainRunnerImpl的Run函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
virtual int Run() OVERRIDE {
    DCHECK(is_initialized_);
    DCHECK(!is_shutdown_);
    const CommandLine& command_line = *CommandLine::ForCurrentProcess();
    std::string process_type =
          command_line.GetSwitchValueASCII(switches::kProcessType);

    MainFunctionParams main_params(command_line);
    main_params.ui_task = ui_task_;
#if defined(OS_WIN)
    main_params.sandbox_info = &sandbox_info_;
#elif defined(OS_MACOSX)
    main_params.autorelease_pool = autorelease_pool_.get();
#endif

#if !defined(OS_IOS)
    return RunNamedProcessTypeMain(process_type, main_params, delegate_);
#else
    return 1;
#endif
  }

       核心还是RunNamedProcessTypeMain函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

// Run the FooMain() for a given process type.
// If |process_type| is empty, runs BrowserMain().
// Returns the exit code for this process.
int RunNamedProcessTypeMain(
    const std::string& process_type,
    const MainFunctionParams& main_function_params,
    ContentMainDelegate* delegate) {
  static const MainFunction kMainFunctions[] = {
#if !defined(CHROME_MULTIPLE_DLL_CHILD)
    { "",                            BrowserMain },
#endif
#if !defined(CHROME_MULTIPLE_DLL_BROWSER)
#if defined(ENABLE_PLUGINS)
#if !defined(OS_LINUX)
   ...
#endif
    { switches::kWorkerProcess,      WorkerMain },
    { switches::kPpapiPluginProcess, PpapiPluginMain },
    { switches::kPpapiBrokerProcess, PpapiBrokerMain },
#endif  // ENABLE_PLUGINS
    { switches::kUtilityProcess,     UtilityMain },
    //我们的tpye等于renderer
    { switches::kRendererProcess,    RendererMain },
    { switches::kGpuProcess,         GpuMain },
#endif  // !CHROME_MULTIPLE_DLL_BROWSER
  };
  //前面在分析RenderProcessHostImpl类的成员函数Init时提到，
  //RenderProcessHostImpl类的静态成员变量g_renderer_main_thread_factory
  //描述的是一个函数，通过它可以创建一个类型为InProcessRendererThread的线程
  RegisterMainThreadFactories();

  for (size_t i = 0; i < arraysize(kMainFunctions); ++i) {
    //如果type等于renderer
    if (process_type == kMainFunctions[i].name) {
      if (delegate) {
        //调用android平台的ChromeMainDelegate::RunProcess
        //但是它返回-1，后面会贴代码
        int exit_code = delegate->RunProcess(process_type,
            main_function_params);
#if defined(OS_ANDROID)
        // In Android's browser process, the negative exit code doesn't mean the
        // default behavior should be used as the UI message loop is managed by
        // the Java and the browser process's default behavior is always
        // overridden.
        if (process_type.empty())
          return exit_code;
#endif
        if (exit_code >= 0)
          return exit_code;
      }
      //所以最后调用了RendererMain函数
      return kMainFunctions[i].function(main_function_params);
    }
  }

#if defined(OS_POSIX) && !defined(OS_MACOSX) && !defined(OS_ANDROID)
  // Zygote startup is special -- see RunZygote comments above
  // for why we don't use ZygoteMain directly.
  if (process_type == switches::kZygoteProcess)
    return RunZygote(main_function_params, delegate);
#endif

  // If it's a process we don't know about, the embedder should know.
  if (delegate)
    return delegate->RunProcess(process_type, main_function_params);

  NOTREACHED() << "Unknown process type: " << process_type;
  return 1;
}
#endif

       1）创建一个type-func键值对的数组kMainFunctions，我们的type为renderer。
       2）然后调用RegisterMainThreadFactories函数注册RendererProcess，GpuProcess，UtilityProcess中创建IPC线程的工厂类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#if !defined(OS_IOS)
static void RegisterMainThreadFactories() {
#if !defined(CHROME_MULTIPLE_DLL_BROWSER)
  UtilityProcessHostImpl::RegisterUtilityMainThreadFactory(
      CreateInProcessUtilityThread);
  RenderProcessHostImpl::RegisterRendererMainThreadFactory(
      CreateInProcessRendererThread);
  GpuProcessHost::RegisterGpuMainThreadFactory(
      CreateInProcessGpuThread);
#else
  CommandLine& command_line = *CommandLine::ForCurrentProcess();
  if (command_line.HasSwitch(switches::kSingleProcess)) {
    LOG(FATAL) <<
        "--single-process is not supported in chrome multiple dll browser.";
  }
  if (command_line.HasSwitch(switches::kInProcessGPU)) {
    LOG(FATAL) <<
        "--in-process-gpu is not supported in chrome multiple dll browser.";
  }
#endif
}

       我们只关注RendererProcess的，看看RegisterRendererMainThreadFactory函数，位于external/chromium_org/content/browser/renderer_host/render_process_host_impl.cc：

1
2
3
4
void RenderProcessHostImpl::RegisterRendererMainThreadFactory(
    RendererMainThreadFactoryFunction create) {
  g_renderer_main_thread_factory = create;
}

       参数CreateInProcessRendererThread实现如下，位于

1
2
3
4
5
6
7
8

InProcessRendererThread::InProcessRendererThread(const std::string& channel_id)
    : Thread("Chrome_InProcRendererThread"), channel_id_(channel_id) {
}

base::Thread* CreateInProcessRendererThread(const std::string& channel_id) {
  return new InProcessRendererThread(channel_id);
}

       这时就一目了然了，前面在分析RenderProcessHostImpl类的成员函数Init时提到，RenderProcessHostImpl类的静态成员变量g_renderer_main_thread_factory描述的是一个函数，通过它可以创建一个类型为InProcessRendererThread的线程。

       回到RunNamedProcessTypeMain里，走到for循环里面。如果type等于renderer，就会执行ChromeMainDelegateAndroid的RunProcess函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
int ChromeMainDelegateAndroid::RunProcess(
    const std::string& process_type,
    const content::MainFunctionParams& main_function_params) {
  TRACE_EVENT0("startup", "ChromeMainDelegateAndroid::RunProcess")
  if (process_type.empty()) {
    JNIEnv* env = base::android::AttachCurrentThread();
    RegisterApplicationNativeMethods(env);

    // Because the browser process can be started asynchronously as a series of
    // UI thread tasks a second request to start it can come in while the
    // first request is still being processed. Chrome must keep the same
    // browser runner for the second request.
    // Also only record the start time the first time round, since this is the
    // start time of the application, and will be same for all requests.
    if (!browser_runner_.get()) {
      base::Time startTime = chrome::android::GetMainEntryPointTime();
      startup_metric_utils::RecordSavedMainEntryPointTime(startTime);
      browser_runner_.reset(content::BrowserMainRunner::Create());
    }
    return browser_runner_->Initialize(main_function_params);
  }
  //所以最后执行ChromeMainDelegate的RunProcess函数
  return ChromeMainDelegate::RunProcess(process_type, main_function_params);
}

       所以最后执行ChromeMainDelegate的RunProcess函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
int ChromeMainDelegate::RunProcess(
    const std::string& process_type,
    const content::MainFunctionParams& main_function_params) {
  // ANDROID doesn't support "service", so no ServiceProcessMain, and arraysize
  // doesn't support empty array. So we comment out the block for Android.
#if !defined(OS_ANDROID)
  static const MainFunction kMainFunctions[] = {
#if defined(ENABLE_FULL_PRINTING) && !defined(CHROME_MULTIPLE_DLL_CHILD)
    { switches::kServiceProcess,     ServiceProcessMain },
#endif

#if defined(OS_MACOSX)
    { switches::kRelauncherProcess,
      mac_relauncher::internal::RelauncherMain },
#endif

    // This entry is not needed on Linux, where the NaCl loader
    // process is launched via nacl_helper instead.
#if !defined(DISABLE_NACL) && !defined(CHROME_MULTIPLE_DLL_BROWSER) && \
    !defined(OS_LINUX)
    { switches::kNaClLoaderProcess,  NaClMain },
#else
    { "<invalid>", NULL },  // To avoid constant array of size 0
                            // when DISABLE_NACL and CHROME_MULTIPLE_DLL_CHILD
#endif  // DISABLE_NACL
  };

  for (size_t i = 0; i < arraysize(kMainFunctions); ++i) {
    if (process_type == kMainFunctions[i].name)
      return kMainFunctions[i].function(main_function_params);
  }
#endif
  //但是它返回-1
  return -1;
}

       但是它返回-1。因此又回到RunNamedProcessTypeMain函数的最后一行，即执行kMainFunctions[i].function(main_function_params)，即RendererMain函数。

       RendererMain函数定义在external/chromium_org/content/renderer/renderer_main.cc，虽然很长，但我们关注的很少：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// mainline routine for running as the Renderer process
int RendererMain(const MainFunctionParams& parameters) {

    ......
    //创建一个RenderProcessImpl实例
    RenderProcessImpl render_process;
    //创建一个RenderThreadImpl对象
    new RenderThreadImpl();
    ......
    TRACE_EVENT_BEGIN_ETW("RendererMain.START_MSG_LOOP", 0, 0);
    //开启线程消息循环
    base::MessageLoop::current()->Run();
    TRACE_EVENT_END_ETW("RendererMain.START_MSG_LOOP", 0, 0);
}

       这时候就一目了然了，创建一个RenderProcessImpl实例，再new一个RenderThreadImpl对象。我们回忆Render进程启动第一部分：

       回到RenderProcessHostImpl类的成员函数Init中，接下来它会调用前面创建的InProcessRendererThread对象的成员函数StartWithOptions启动一个线程。从前面Chromium多线程模型设计和实现分析一文可以知道，当该线程启动起来之后，并且在进入消息循环之前，会被调用InProcessRendererThread类的成员函数Init执行初始化工作。

       InProcessRendererThread类的成员函数Init的实现如下所示：

1
2
3
4
void InProcessRendererThread::Init() {
  render_process_.reset(new RenderProcessImpl());
  new RenderThreadImpl(channel_id_);
}

所以回到上述RendererMain函数中，接下来的事情就一目了然，就是创建ChannelProxy Client端对象，然后封装client的fd到到这个proxy和browser进程通信。

       最后开启线程消息循环，保持轮训，不让他退出。
       回到ChildProcessService的onCreate第8步骤，上一步消息循环会轮训，因此退出消息循环就会退render进程。

       到此render进程启动过程就分析完了。

小结

       Render进程启动第二部分相对于第一部分比较复杂，并且很多设计browser进程启动的内容（以后分析）。下一节分析一下进程间通信的消息分发机制（我们分析的是chromium IPC，但是现在已经用mojo了）。

meizi

坚持技术分享，您的支持将鼓励我继续创作！