Chromium扩展（Extension）机制简要介绍和学习计划

September 5, 2016, 12:58 am

Chromium提供了一种Extension机制，用来增强浏览器功能。我们可以将Extension看作是一种运行在Chromium中的应用。这种应用的开发语言是JavaScript，并且UI通过HTML描述。通过使用Chromium提供的API，Extension可以访问网络，修改浏览器行为，以及操作网页的内容等。本文接下来对Chromium的Extension机制进行简要介绍，以及制定学习计划。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

在Chrome（基于Chromium实现，以下我们将交替使用Chrome和Chromium）的地址栏中输入"chrome://extensions"，就可以看到当前安装的所有Extension，如图1所示：

图1 Chrome中的Extension列表

图1显示了两个Extension。一个是基于Browser Action实现的，另一个是基于Page Action实现的。它们在地址栏的右边分别对应有一个Button。点击这两个Button，可以弹出一个窗口。这一点后面我们会看到。

接下来，我们就通过上述两个Extension例子，对Chromium的Extension机制进行介绍。

每一个Extension都包含有一个清单文件manifest.json，类似于Android应用程序的AndroidManifest.xml文件。前者是json格式的，后者是xml格式的。清单文件描述了Extension的内容。以图1所示的Browser action example为例，它的manifest.json如下所示：

{
  "manifest_version": 2,

  "name": "Browser action example",
  "description": "This extension show a image and changes a web page's background",
  "version": "1.0",

  "browser_action": {
    "default_icon": "icon.png",
    "default_popup": "popup.html"
  },

  "content_scripts": [
    {
      "matches": ["http://*/*"],
      "js": ["content.js"],
      "run_at": "document_start",
      "all_frames": true
    }
  ]
}

前面几行是一些描述性信息。后面的browser_action和content_scripts指定了一个Browser Action和一个Content Script。

Browser Action对在浏览器中加载的所有网页都生效。后面我们可以看到，Extension还有一种Page Action，它针对特定的网页生效。一个Extension最多可以有一个Browser Action或者Page Action。不管是Browser Action，还是Page Action，都可以指定一个icon文件和一个popup文件。前者是一个图片，后者是一个html文件。指定的icon将会以Button的形式展现在地址栏的右边。当这个Button被点击的时候，就会弹出一个窗口，窗口会加载在清单文件中指定的popup.html文件。注意，这里指定的文件路径都是相对路径，相对Extension的根目录的。

上述popup.html的内容如下所示：

<html>
  <head>
    <title>Getting Started Extension's Popup</title>
    <style>
      body {
        font-family: "Segoe UI", "Lucida Grande", Tahoma, sans-serif;
        font-size: 100%;
      }
      #status {
        /* avoid an excessively wide status text */
        white-space: pre;
        text-overflow: ellipsis;
        overflow: hidden;
        max-width: 400px;
      }
    </style>

    <!--
      - JavaScript and HTML must be in separate files: see our Content Security
      - Policy documentation[1] for details and explanation.
      -
      - [1]: https://developer.chrome.com/extensions/contentSecurityPolicy
     -->
    <script src="popup.js"></script>
  </head>
  <body>
    <div id="status"></div>
    <img id="image-result" hidden>
  </body>
</html>

这个html文件的内容很简单，由以下内容组成：

1. 一个popup.js脚本

2. 一个div标签

3. 一个img标签

其中，div标签用来显示状态信息，img标签用来显示图片。它们的内容都是popup.js指定的，如下所示：

function getImageUrl(callback, errorCallback) {
  callback("https://images-cn-8.ssl-images-amazon.com/images/I/61vnPRDVoeL.jpg", 200, 250);
}

function renderStatus(statusText) {
  document.getElementById('status').textContent = statusText;
}

document.addEventListener('DOMContentLoaded', function() {
    getImageUrl(function(imageUrl, width, height) {
      var imageResult = document.getElementById('image-result');
      imageResult.width = width;
      imageResult.height = height;
      imageResult.src = imageUrl;
      imageResult.hidden = false;

    }, function(errorMessage) {
      renderStatus('Cannot display image. ' + errorMessage);
    });
});

这个popup.js所做的事情非常简单，就是为popup.html中的img标签指定一个src。安装了这个Entension之后，就可以在浏览器地址栏的右边出现一个Button。点击这个Button，就可以弹出一个窗口，它的内容如图2所示：

图2 Browser Action的popup.html

Browser action example的清单文件还指定了一个Content Script，即content.js。这个content.js通过matches字段指定对任何网页生效。这里所说的生效，是指将content.js注入到网页中去执行的。

上述content.js的内容如下所示：

document.body.style.backgroundColor="red"

它做了一件非常简单的事情，就是将网页的背景设置为红色。这件事情虽然非常简单，但是它告诉了我们，Extension通过Content Script可以操作在Chromium中加载的任何一个网页的内容！

我们再来看另一个Page action example。它的清单文件如下所示：

{
  "manifest_version": 2,

  "name": "Page action example",
  "description": "This extension show a image and changes a web page's background",
  "version": "1.0",

  "background": {
    "scripts": ["background.js"]
  },

  "page_action": {
    "default_icon": "icon.png", 
    "default_popup": "popup.html" 
  },

  "permissions": [
     "tabs"
   ],

  "content_scripts": [
    {
      "matches": ["https://fast.com/"],
      "js": ["content.js"],
      "run_at": "document_start",
      "all_frames": true
    }
  ]
}

这个清单文件没有指定Browser Action，但是指定了Page Action，以及Content Script和Background。Content Script和Background描述的都是一个JavaScript脚本，前者称为content.js，后者称为background.js。

Page Action与Browser Action类似，它也对应有一个icon和一个popup。不过，Page Action是有状态的，分为显示和隐藏两种。为显示状态时，它在地址栏右边的Button变亮，并且可以点击。为隐藏状态时，它在地址栏右边的Button变灰，并且不可以点击。

我们可以通过Chromium提供的Page Action API（chrome.pageAction.show和chrome.pageAction.hide）显示或者隐藏Page Action。一般就是根据当前打开的网页决定要显示还是隐藏一个Page Action。这个判断逻辑一般就是实现在background.js中，如下所示：

chrome.tabs.onUpdated.addListener(function (tabId, changeInfo, tab) { 
  if (tab.url.indexOf("fast.com") >= 0) {
    chrome.pageAction.show(tabId);  
  }

  var views = chrome.extension.getViews({type: "tab"});
  if (views.length > 0) {
    console.log(views[0].whoiam);
  } else {
    console.log("No tab");
  }
});  

chrome.runtime.onMessage.addListener(
  function(request, sender, sendResponse) {
    sendResponse({counter: request.counter + 1 }); 
  }
);

var whoiam = "background.html"

这个background.js通过chrome.tabs.onUpdated.addListener这个API指定了一个Listener。每当我们切换到浏览器中的Tab时，与这个Listener绑定的函数就会被调用。这个函数是一个匿名函数，它做了两件事情。

第一件事情是判断当前激活的Tab打开的网页的URL是否包含了"fast.com"关键字。如果包含了，那么就通过chrome.pageAction.show这个API将清单文件中指定的Page Action显示出来。

第二件事情是调用chrome.extension.getViews这个API检查当前的Extension是否有页面在浏览器的Tab中打开。如果有打开，那么就会获得这些页面的window对象。一旦获得了一个页面window对象，我们就可以访问它的成员。例如，定义在页面中的函数和变量。这实际上是提供了一种方式，使得Extension的不同页面可以相互通信。这里我们就是访问了一个whoiam变量，并且将它的内容打印出来。

关于Extension页面，及其通信方式，我们接下来还会进一步解释。

上述background.js还通过chrome.runtime.onMessage.addListener这个API定义了一个Listener以及一个whoiam变量。其中，Listener用来接收其它页面给它发送的消息，变量whoiam可以被其它页面直接访问。

当Page Action通过chrome.pageAction.show这个API被设置为显示状态时，我们就可以点击它在地址栏右边的按钮，弹出一个窗口。这个窗口在清单文件中指定加载的网页为popup.html，它的内容如下所示：

<html>
  <head>
    <title>Getting Started Extension's Popup</title>
    <style>
      body {
        font-family: "Segoe UI", "Lucida Grande", Tahoma, sans-serif;
        font-size: 100%;
      }
      #status {
        /* avoid an excessively wide status text */
        white-space: pre;
        text-overflow: ellipsis;
        overflow: hidden;
        max-width: 400px;
      }
    </style>

    <!--
      - JavaScript and HTML must be in separate files: see our Content Security
      - Policy documentation[1] for details and explanation.
      -
      - [1]: https://developer.chrome.com/extensions/contentSecurityPolicy
     -->
    <script src="popup.js"></script>
  </head>
  <body>
    <table align='center'>  
      <tr>  
        <td><button id="testRequest">send 0 to tab page</button></td>  
        <td id="resultsRequest"><font color="gray">response: null</font></td>  
      </tr>   
    </table>  
    <div id="status"></div>
    <img id="image-result" hidden>
  </body>
</html>

与前面Browser action example中的popup.html一样，这个popup.html也包含了一个popup.js，一个div标签和一个img标签。不过，这个popup.html还多了一个table标签。这个table包含了一行两列。其中一列用来显示一个Button，另一列用来显示文本。

上述popup.html显示出来的效果如图3所示：

图3 Page Action的popup.html

这个popup.html显示的图片是通过它包含的popup.js指定的，如下所示：

function getImageUrl(callback, errorCallback) {
  callback("http://avatar.csdn.net/5/6/E/1_luoshengyang.jpg", 200, 200);
}

function renderStatus(statusText) {
  document.getElementById('status').textContent = statusText;
}

var counter = 0;

function testRequest() {  
  chrome.tabs.getSelected(null, function(tab) {   
    chrome.tabs.sendRequest(tab.id, {counter: counter}, function handler(response) {  
      counter = response.counter;
      document.querySelector('#resultsRequest').innerHTML = "<font color='gray'> response: " + counter + "</font>";
      document.querySelector('#testRequest').innerText = "send " + (counter -1) + " to tab page";
    });  
  });  
}  

document.addEventListener('DOMContentLoaded', function() {
  getImageUrl(function(imageUrl, width, height) {
    var imageResult = document.getElementById('image-result');
    imageResult.width = width;
    imageResult.height = height;
    imageResult.src = imageUrl;
    imageResult.hidden = false;

    console.log(chrome.extension.getBackgroundPage().whoiam);
  }, function(errorMessage) {
    renderStatus('Cannot display image. ' + errorMessage);
  });

  document.querySelector('#testRequest').addEventListener(  
      'click', testRequest);  
});

var whoiam = "popup.html"

这个popup.js是在页面的文档加载完成时指定显示的图片的。同时，它还会在页面的文档加载完成时，做另外两件事情。

第一件事情是调用chrome.extension.getBackgroundPage这个API获得当前Extension的Background页面的window对象，并且通过这个window对象访问定义在Background页面中的whoiam变量。前面我们在background.js定义了一个whoiam变量，因此这里就可以对它进行访问。

第二件事情为popup.html页面中显示为"send to tab page"的Button指定一个Listener。这个Listener用来监听Button的Click事件。一旦监听到Click事件发生，函数testRequest就会被调用。

函数testRequest首先通过chrome.tabs.getSelected这个API获得当前激活的Tab，接着又通过chrome.tabs.sendRequest这个API向获得的当前激活的Tab发送一个消息。消息是json格式的，传递一个由变量counter描述的计数给接收者。接收者接收到这个消息之后，会将它封装的计数取出来，并且增加1，然后再将结果返回来。返回来的结果保存在变量counter的同时，也会显示在popup.html页面中id为resultsRequests的td标签中。

这样，通过不断地点击popup.html页面中显示为"send to tab page"的Button，就可以不断地与当前激活的Tab通信。后面我们可以看到，实际上是与在Tab中加载的Content Script通信的。

从popup.js的内容还可以看到，它定义了一个变量whoiam。这个变量可以被其它Extension页面直接访问。

前面提到，Page action example的清单文件还指定了一个Content Script，即content.js。这个content.js通过matches字段指定仅对URL为“https://fast.com/”的页面生效，也就是它只会注入到URL为“https://fast.com/”的页面中去。注入的内容如下所示：

document.body.innerHTML = "<table align='center'>\
                             <tr>\
                               <td><button id='testRequest'>send 0 to background page</button></td>\
                               <td id='resultsRequest'>response: null</td>\
                               </tr>\
                           </table>" +
                           document.body.innerHTML;

chrome.extension.onRequest.addListener(  
  function(request, sender, sendResponse) {  
    sendResponse({counter: request.counter + 1 });  
  }
);

var counter = 0;

function testRequest() {  
  chrome.runtime.sendMessage({counter: counter}, function(response) {
    counter = response.counter;
    document.querySelector('#resultsRequest').innerText = "response: " + counter;
    document.querySelector('#testRequest').innerText = "send " + (counter -1) + " to background page";
  });
}

document.querySelector('#testRequest').addEventListener(  
   'click', testRequest);

它注入了一个table。这个table包含一行两列。其中一个列包含了一个显示为“send 0 to background page”的Button，另外一个列用来显示文本。

注入的效果如图4所示：

图4 Content Script

当我们点击显示为“send 0 to background page”的Button时，定义在content.js中的函数testRequest就会被调用。函数testRequest用来向当前的Extension的Background页面发送消息。这个消息传递一个由变量counter描述的计数给Background页面。

Background页面在background.js中通过chrome.runtime.onMessage.addListener这个API定义了一个Listener。这个Listener用来接收上述由content.js发送过来的消息。接收到该消息后，background.js会将其封装的计数取出，并且增加1，然后将结果返回给content.js显示。

此外，content.js还通过chrome.extension.onRequest.addListener这个API定义了一个Listener。这个Listener用来监听其它页面发送过来的消息。也就是前面提到的从popup.html中发送过来的消息。

分析到这里，我们小结一下，Page action example这个Extension所包含的内容：

1. popup.html：显示在一个弹出窗口中。

2. background.html：这个页面是由Chromium根据background.js生成出来的，没有显示在窗口中，因此称为Background页面。

3. content.js：一个注入在宿主页面中的JavaScript。

其中，前两个属于页面，后面一个属于脚本。事实上，一个Extension可以同时拥有若干个页面。这些页面分为五种类型为：background、popup、tab、infobar、notification。它们分别代表在不同窗口打开的页面。其中，前面两种我们已经描述过了，后面三种也比较容易理解：

1. tab：像正常网页一样在浏览器的Tab中打开的页面。

2. infobar：在浏览器顶部信息栏显示的信息页面。

3. notification：在浏览器底部显示的通知页面。

每一个页面都有一个URL。URL的规范为：chrome-extension://[extension-id]/path。其中，协议部分为chrome-extension，extension-id是Chromium为Extension分配的ID，path是页面的路径。

从图1可以看到，Chrome为Page action example分配的Extension ID为“abcemahgedfccgcmlkaeiabpjjjhhmoc”。按照上述规范，图3显示的popup页面的URL就为“chrome-extension://abcemahgedfccgcmlkaeiabpjjjhhmoc/popup.html”。这个URL可以直接输入到Chrome的地址栏中去，使得popup.html也可以显示在一个Tab中。

Page action example还包含了另外一个tab.html文件，它的内容如下所示：

<html>
  <head>
    <title>Getting Started Extension's Tab</title>
  </head>
  <body>
    <table align='center' height="100%">
      <tr>
        <td><img src="sample.png" /></td>
      </tr>
    </table>
  </body>
</html>

这是一个简单的html页来，用来显示打包在Extension中的一个图片sample.png。

我们可以在浏览器的地址栏中输入“chrome-extension://abcemahgedfccgcmlkaeiabpjjjhhmoc/tab.html”访问这个页面，效果如图5所示：

图5 Open extension page in tab

这样，我们就可以归纳出一个Extension是由Extension Page和Content Script构成的。

Extension Page与普通的网页一样，具有一个URL。常规的Extension Page有popup.html、background.html。其中，popup.html显示在一个弹出窗口中，background.html运行在后台，没有显示在窗口中。给出一个Extension Page的URL，我们也可以在浏览器的Tab中打开它。

Content Script是一个JavaScript脚本，它会注入到宿主网页去执行，从页可以访问它的DOM Tree。这里说的宿主网页，就是在浏览器中加载的网页。这些网页是由网站提供的，不属于Extension的一部分。

Extension Page之间，以及Extension Page与Content Script之间，是可以相互通信的。正是因为它们可以相互通信，才能形成一个整体，共同去完成一个Extension的功能。其中，background.js所在的background.html扮演着一个中心角色。它在Extension加载的时候就会默默加载，并且一直运行在后台。其它的Extension Page或者Content Script都是按需加载的。因此，我们就可以将Extension的状态维护在background.html中，其它的Extension Page或者Content Script需要的时候，可以与它进行通信。

那么，Extension Page之间，以及Extension Page与Content Script之间，是如何通信的呢？我们通过图6说明，如下所示：

图6 Extension Page与Content Script之间的通信方式

同一个Extension的Extension Page都是运行在同一个进程中的。这个进程称为Extension进程，这实际上也是一个Render进程。在同一个进程打开的网页可以在JavaScript中直接获得对方的window对象。有了一个网页的window对象，就可以调它里面定义的函数或者变量，相当于就是可以与它进行通信。

Chromium的Extension机制提供了两个API：chrome.extension.getViews和chrome.extension.getBackgroundPage。其中，通过前者可以获得Background Page之外的Extension Page的window对象，而通过后者可以获得的Background Page的window对象。chrome.extension.getViews这个API在调用的时候，还可以指定一个type参数，用来指定要获取哪一种类型的Extension Page的window对象。如果没有指定，则获取Background Page之外的所有Extension Page的window对象。

Extension的Content Script由于是注入在其它网页中运行，因此它们不能与Extension Page进行直接通信，而是要进行跨进程通信。又由于Content Script和Extension Page是相互不知道对方的，因此它们在进行跨进程通信的时候，需要有一个桥梁。这个桥梁就是Browser进程。

Chromium的Extension机制提供了两个API：chrome.tabs.sendRequest和chome.extension.onRequest，用来从Extension Page向Content Script发送消息。同样，Chromium的Extension机制也为从Content Script向Extension Page发送消息提供了两个API：chrome.runtime.sendMessage和chrome.runtime.onMessage。它们的实现原理是一样的。当chrome.tabs.sendRequest或者chrome.runtime.sendMessage被调用的时候，它们会向Browser进程发送一个类型为ExtensionHostMsg_PostMessage的IPC消息。Browser进程接收到这个消息之后，又会向目标进程发送一个类型为ExtensionMsg_DeliverMessage的IPC消息。目标进程接收到这个消息之后，再通过JavaScript引擎分发给chome.extension.onRequest或者chrome.runtime.onMessage处理。

了解了Extension Page之间，以及Extension Page与Content Script之间的通信机制之后，我们再来看Extension Page和Content Script的加载过程。

Chromium的Browser进程在启动的时候，会创建一个Startup Task。这个Startup Task会初始化一个Extension Service，如图7所示：

图7 Extension加载过程

Extension Service在初始化的过程中，会通过一个Installed Loader加载当前用户安装的所有设置为Enabled的Extension。这些Extension形成一个列表，保存在一个Extension Registry中。以后通过这个Extension Registry，就可以获得当前启用的所有Extension的信息。

如果一个Extension指定了Background Page，那么Browser进程在初始化好浏览器窗口之后，还会自动加载它指定的Background Page，如图8所示：

图8 Background Page和Popup Page的加载过程

Browser进程初始化好浏览器窗口之后，会发送一个OnBrowserWindowReady通知。这个通知会触发Browser进程创建一个ExtensionHost对象。这个ExtensionHost对象又会通过WebContents类的静态成员函数Create加载指定的Background Page。WebContents类是Chromium的Content层向外提供的一个API。通过这个API，就可以使用Chromium来加载一个指定的网页了。

注意，Background Page会加载在一个Extension进程中。如果这个Extension进程还没有创建，那么WebContents类的静态成员函数Create会先创建它。以后Browser进程如果要与这个Background Page进行通信，那么就会通过上述创建的ExtensionHost对象进行。从这里我们也可以看到，每一个Background Page在Browser进程中都有一个对应的ExtensionHost对象，就类似于普通的网页在Browser进程中都有一个对应的RenderProcessHostImpl对象一样。这一点可以参考前面Chromium多进程架构简要介绍和学习计划这个系列的文章。这是很好理解的，因为Extension进程本质上也是一个Render进程。

其它类型的Extension Page，它们则是按需加载的。例如，对于Popup Page来说，当用户点击了它在地址栏右边对应的Button的时候，Browser进程才会加载它们。它们的加载过程与上述的Background Page是类似的，即先创建一个ExtensionHost对象，然后再通过WebContents类的静态成员函数Create进行加载。

最后，我们再来看Content Script的加载过程，如图9所示：

图9 Content Script的加载过程

Content Script的加载过程由三个流程组成。

第一个流程发生在Extension加载过程中，也就是图7所示的Extension加载流程。Browser进程在启动的时候，会创建一个UserScriptMaster对象，用来监听所有的Extension的加载事件。如果当前被加载的Extension指定了Content Script，那么指定的Content Script的内容就会保存在上述UserScriptMaster对象中。

第二个流程发生在Content Script的宿主网页所对应的Render进程的启动过程中。当这个Render进程启动完成时，Browser进程会获得一个OnProcessLaunched通知。这个通知直接分发给代表该Render进程的一个RenderProcessHostImpl对象处理。这个RenderProcessHostImpl对象首先会到上述的UserScriptMaster对象中收集要在宿主网页中加载的Content Script，然后再通过一个类型为ExtensionMsg_UpdateUserScript的IPC消息将这些Content Script发送给宿主网页所在的Render进程。这个Render进程会通过一个Dispatcher对象接收该IPC消息，并且将发送过来的Content Script保存在一个UserScriptSlave对象中。

第三个流程发生在Content Script的宿主网页的加载过程中。Content Script可以在Extension的清单文件中指定加载时机。有三个时机可以指定：document_start、document_end和document_idle，分别表示在宿主网页的Document对象开始创建、结束创建以及空闲时加载。接下来，我们假设Content Script指定了在document_start时加载。

从前面Chromium网页DOM Tree创建过程分析一文可以知道，WebKit在加载的一个网页的时候，首先会为它创建一个Document对象。在创建这个Document对象的时候，WebKit会通过Chromium中的Content层，也就是调用一个RenderFrameImpl对象的成员函数didCreateDocumentElement。这个RenderFrameImpl对象是在Content层中描述的一个在当前Render进程中加载的网页的。

RenderFrameImpl类的成员函数didCreateDocumentElement在执行的过程中，会到上述的UserScriptSlave对象收集要在当前加载的网页中加载的Content Script。这些Content Script又会进一步交给JavaScript引擎在一个Isolated World中执行。Content Script在Isolated World中执行，意味着它们是被隔离执行的，也就是它们不能访问在宿主网页中定义的JavaScript函数和变量。

RenderFrameImpl类的成员函数didCreateDocumentElement是如何将Content Script交给JavaScript引擎执行的呢？从前面Chromium网页Frame Tree创建过程分析一文可以知道，Chromium的Content层的每一个RenderFrameImpl对象在WebKit中都对应有一个WebLocalFrameImpl对象，并且该WebLocalFrameImpl对象会保存在它对应的RenderFrameImpl对象的内部。这个WebLocalFrameImpl对象可以看作是WebKit向Chromium的Content层提供的一个API接口。通过调用这个WebLocalFrameImpl对象的成员函数executeScriptInIsolatedWorld，就可以将指定的Content Script交给JavaScript引擎执行了。

这样，我们就通过两个Extension例子，对Extension机制涉及到的基本概念进行了介绍。为了更进一步理解Extension机制，接下来我们将结合源码，按照以下四个情景对Extension机制进行分析：

1. Extension的加载过程；

2. Extension Page的加载过程；

3. Content Script的加载过程；

4. Extension Page之间，以及Extension Page与Content Script之间的通信过程。

注意，这些文章的侧重点是分析Extension机制的实现，而不是Extension的开发。Extension的开发，可以参考官方文档：http://code.google.com/chrome/extensions/getstarted.html。

另外，除了Extension机制，Chromium还提供了Plugin机制，用来增强浏览器的功能。Extension和Plugin是两种不同的机制。从狭义上讲，Plugin仅仅是用来增加网页的功能，而Extension不仅能用来增加网页的功能，也能增强浏览器本身功能。而且，两者的开发方式（开发语言和API接口）也是完全不一样的。为了更好地理解两者的区别，后面我们将会用另外一个系列的文章分析Chromium的Plugin机制。

敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/9/5 0:58:34 原文链接

阅读：51812 评论：7 查看评论

↧

Chromium扩展（Extension）加载过程分析

September 12, 2016, 12:59 am

≫ Next: Chromium扩展（Extension）的页面（Page）加载过程分析

≪ Previous: Chromium扩展（Extension）机制简要介绍和学习计划

Chromium在启动的时候，会根据当前用户的Profile创建一个Extension Service。Extension Service在创建过程中，会加载当前已经安装的所有Extension，并且将它们注册在一个Extension Registry中。以后通过这个Extension Registry，就可以得到当前可用的Extension的信息了。本文接下来就分析Extension的加载过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

Chromium的启动，指的实际上是Chromium的Browser进程的启动。关于Chromium的多进程架构，可以参考前面Chromium多进程架构简要介绍和学习计划这个系列的文章。Chromium的Browser进程在启动之后，会创建一系列的Startup Task。每一个Startup Task都会负责初始化相应的模块。上述的Extension Service就是在一个Startup Task中创建的，如图1所示：

图1 Extension的加载过程

Extension Service在创建的过程中，会通过一个Installed Loader加载当前已经安装的所有Extension，并且将那些设置为Enabled的Extension注册到Extension Registry中，从而得到一个当前可用的Extension列表。

接下来，我们就从Chromium的Browser进程的启动开始，分析它加载Extension的过程。

在前面Chromium硬件加速渲染的OpenGL上下文绘图表面创建过程分析一文中，我们以Content Shell APK为例，分析了Browser进程的启动过程。在这个启动过程中，会创建一个BrowserStartupController对象，并且调用这个BrowserStartupController对象的成员函数startBrowserProcessesAsync异步启动和初始化Chromium的Content模块，如下所示：

public class BrowserStartupController {
    ......

    public void startBrowserProcessesAsync(final StartupCallback callback)
            throws ProcessInitException {
        ......

        // Browser process has not been fully started yet, so we defer executing the callback.
        mAsyncStartupCallbacks.add(callback);
        ......

        if (!mHasStartedInitializingBrowserProcess) {
            ......

            prepareToStartBrowserProcess(MAX_RENDERERS_LIMIT);
            ......

            if (contentStart() > 0) {
                // Failed. The callbacks may not have run, so run them.
                enqueueCallbackExecution(STARTUP_FAILURE, NOT_ALREADY_STARTED);
            }
        }
    }

    ......
}

这个函数定义在文件external/chromium_org/content/public/android/java/src/org/chromium/content/browser/BrowserStartupController.java中。

在Browser进程的Content模块还没有启动过的情况下，BrowserStartupController类的成员变量mHasStartedInitializingBrowserProcess的值会等于false。在这种情况下，BrowserStartupController类的成员函数startBrowserProcessesAsync会做两件事情：

1. 调用成员函数prepareToStartBrowserProcess在VM中加载libcontent_shell_content_view.so。

2. 调用成员函数contentStart启动和初始化Content模块。

从Dalvik虚拟机JNI方法的注册过程分析这篇文章可以知道，VM在加载so的过程中，将会调用它导出的一个名称为JNI_OnLoad的函数。对libcontent_shell_content_view.so来说，它导出的JNI_OnLoad函数的实现如下所示：

// This is called by the VM when the shared library is first loaded.
JNI_EXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved) {
  ......

  content::SetContentMainDelegate(new content::ShellMainDelegate());
  return JNI_VERSION_1_4;
}

这个函数定义在文件external/chromium_org/content/shell/android/shell_library_loader.cc中。

函数JNI_OnLoad将会创建一个ShellMainDelegate对象，并且调用函数SetContentMainDelegate将它保存在一个全局变量g_content_main_delegate中，如下所示：

namespace {
......

LazyInstance<scoped_ptr<contentmaindelegate> > g_content_main_delegate =
    LAZY_INSTANCE_INITIALIZER;
}  // namespace

void SetContentMainDelegate(ContentMainDelegate* delegate) {
  DCHECK(!g_content_main_delegate.Get().get());
  g_content_main_delegate.Get().reset(delegate);
}

这个函数定义在文件external/chromium_org/content/app/android/content_main.cc中。

这一步执行完成后，回到前面分析的BrowserStartupController类的成员函数startBrowserProcessesAsync中，它接下来将会调用另外一个成员函数contentStart启动和初始化Content模块，如下所示：

public class BrowserStartupController {
    ......

    int contentStart() {
        return ContentMain.start();
    }

    ......
}

这个函数定义在文件external/chromium_org/content/public/android/java/src/org/chromium/content/browser/BrowserStartupController.java中。

BrowserStartupController类的成员函数contentStart调用ContentMain类的静态成员函数start在Browser进程中启动和初始化Content模块。在前面Chromium的Render进程启动过程分析一文中，我们已经分析过ContentMain类的静态成员函数start的实现了。它最终会调用到C++层的一个函数Start启动和初始化Content模块，如下所示：

namespace {
LazyInstance<scoped_ptr<ContentMainRunner> > g_content_runner =
    LAZY_INSTANCE_INITIALIZER;

......
}  // namespace

......

static jint Start(JNIEnv* env, jclass clazz) {
  ......

  if (!g_content_runner.Get().get()) {
    ContentMainParams params(g_content_main_delegate.Get().get());
    g_content_runner.Get().reset(ContentMainRunner::Create());
    g_content_runner.Get()->Initialize(params);
  }
  return g_content_runner.Get()->Run();
}

这个函数定义在文件external/chromium_org/content/app/android/content_main.cc中。

函数Start首先判断一个全局变量g_content_runner是否已经指向了一个ContentMainRunner对象。如果还没有指向，那么就会调用ContentMainRunner类的静态成员函数Create创建一个ContentMainRunner对象，如下所示：

ContentMainRunner* ContentMainRunner::Create() {
  return new ContentMainRunnerImpl();
}

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

从这里可以看到，ContentMainRunner类的静态成员函数Create创建的实际上是一个ContentMainRunnerImpl对象。这个ContentMainRunnerImpl对象返回给前面分析的函数Start之后，就会保存在全局变量g_content_runner中。

函数Start获得了新创建的ContentMainRunnerImpl对象之后，会调用它的成员函数Initialize，并且将全局变量g_content_main_delegate指向的ShellMainDelegate对象封装在一个类型为ContentMainParams的参数中传递给它，让它执行初始化工作。

ContentMainRunnerImpl类的成员函数Initialize的实现如下所示：

class ContentMainRunnerImpl : public ContentMainRunner {
 public:
  ......

  virtual int Initialize(const ContentMainParams& params) OVERRIDE {
    ......

    delegate_ = params.delegate;

    ......
  }
 
  ......

 private:
  ......

  ContentMainDelegate* delegate_;
  
  ......
};

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

ContentMainRunnerImpl类的成员函数Initialize将封装在参数params中的一个ShellMainDelegate对象保存在成员变量delegate_中，也就是ContentMainRunnerImpl类的成员变量delegate_指向了一个ShellMainDelegate对象。

回到前面分析的函数Start中，它最后调用前面创建的ContentMainRunnerImpl对象的成员函数Run启动和初始化Content模块，如下所示：

class ContentMainRunnerImpl : public ContentMainRunner {
 public:
  ......

  virtual int Run() OVERRIDE {
    ......
    const CommandLine& command_line = *CommandLine::ForCurrentProcess();
    std::string process_type =
          command_line.GetSwitchValueASCII(switches::kProcessType);

    MainFunctionParams main_params(command_line);
    ......

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

  ......
};

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

ContentMainRunnerImpl类的成员函数Run首先检查当前进程是否指定了switches::kProcessType启动选项。如果指定了，那么就会获取它的值。获取到的值保存在本地变量process_type中，表示当前进程的类型。Browser进程没有指定switches::kProcessType启动选项，因此本地变量process_type的值将为空，表示当前进程是Browser进程。

ContentMainRunnerImpl类的成员函数Run接下来调用函数RunNamedProcessTypeMain启动和初始化Content模块，如下所示：

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)
    { switches::kPluginProcess,      PluginMain },
#endif
    { switches::kWorkerProcess,      WorkerMain },
    { switches::kPpapiPluginProcess, PpapiPluginMain },
    { switches::kPpapiBrokerProcess, PpapiBrokerMain },
#endif  // ENABLE_PLUGINS
    { switches::kUtilityProcess,     UtilityMain },
    { switches::kRendererProcess,    RendererMain },
    { switches::kGpuProcess,         GpuMain },
#endif  // !CHROME_MULTIPLE_DLL_BROWSER
  };

  ......

  for (size_t i = 0; i < arraysize(kMainFunctions); ++i) {
    if (process_type == kMainFunctions[i].name) {
      if (delegate) {
        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;
      }
      return kMainFunctions[i].function(main_function_params);
    }
  }

  ......

  return 1;
}

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

函数RunNamedProcessTypeMain在内部定义了一个静态数组kMainFunctions，它会根据参数process_type的值在这个数组中找到对应的函数执行，也就是不同的进程执行不同的函数来启动和初始化Content模块。

从前面Chromium的Render进程启动过程分析、Chromium的GPU进程启动过程分析和Chromium的Plugin进程启动过程分析这三篇文章可以知道，Render进程、GPU进程和Plugin进程分别通过调用函数RendererMain、GpuMain和PluginMain启动和初始化Content模块。

对于Browser进程来说，情况有点特殊，它并没有调用函数BrowserMain来启动和初始化Content模块。这是因为当参数process_type的值等于空时，函数RunNamedProcessTypeMain调用完成另外一个参数delegate指向的一个ShellMainDelegate对象的成员函数RunProcess后，就会直接直接返回，从而不会执行函数BrowserMain。

这意味着Browser进程是通过调用ShellMainDelegate类的成员函数RunProcess来启动和初始化Content模块的，如下所示：

int ShellMainDelegate::RunProcess(
    const std::string& process_type,
    const MainFunctionParams& main_function_params) {
  ......

  browser_runner_.reset(BrowserMainRunner::Create());
  return ShellBrowserMain(main_function_params, browser_runner_);
}

这个函数定义在文件external/chromium_org/content/shell/app/shell_main_delegate.cc中。

ShellMainDelegate类的成员函数RunProcess首先调用BrowserMainRunner类的静态成员函数Create创建一个BrowserMainRunnerImpl对象，如下所示：

BrowserMainRunner* BrowserMainRunner::Create() {
  return new BrowserMainRunnerImpl();
}

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

创建出来的BrowserMainRunnerImpl对象将会保存在ShellMainDelegate类的成员变量browser_runner_中，并且这个BrowserMainRunnerImpl对象会传递给另外一个函数ShellBrowserMain进行处理，如下所示：

// Main routine for running as the Browser process.
int ShellBrowserMain(
    const content::MainFunctionParams& parameters,
    const scoped_ptr<content::BrowserMainRunner>& main_runner) {
  ......

  int exit_code = main_runner->Initialize(parameters);
  ......

  if (exit_code >= 0)
    return exit_code;

  ......
    
  return exit_code;
}

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

函数ShellBrowserMain主要是调用参数main_runner指向的一个BrowserMainRunnerImpl对象的成员函数Initialize在Browser进程中初始化Content模块。BrowserMainRunnerImpl类的成员函数Initialize的返回值将会大于等于0，这时候函数ShellBrowserMain就会沿着调用路径一直返回到Java层去了，从而使得当前线程（Browser进程的主线程）在Java层进入到消息循环中去。

以上就是Content Shell APK的Browser进程的启动流程。Chrome APK的Browser进程的启动流程也是类似的，它们最后都会通过调用BrowserMainRunnerImpl类的成员函数Initialize初始化Content模块。为了方便描述，接下来我们就将以Chrome APK为例，继续分析BrowserMainRunnerImpl类的成员函数Initialize的实现，从中就可以看到Extension的加载过程。

BrowserMainRunnerImpl类的成员函数Initialize的实现如下所示：

class BrowserMainRunnerImpl : public BrowserMainRunner {
 public:
  ......

  virtual int Initialize(const MainFunctionParams& parameters) OVERRIDE {
    ......

    if (!initialization_started_) {
      initialization_started_ = true;
      ......

      main_loop_.reset(new BrowserMainLoop(parameters));

      main_loop_->Init();

      ......
    }

    main_loop_->CreateStartupTasks();
    int result_code = main_loop_->GetResultCode();
    if (result_code > 0)
      return result_code;

    // Return -1 to indicate no early termination.
    return -1;
  }

  ......
};

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

BrowserMainRunnerImpl类的成员函数Initialize首先检查成员变量initialization_started_的值是否不等于true。如果不等于true，那么就说明Browser进程还没有执行过初始化操作。在这种情况下，BrowserMainRunnerImpl类的成员函数Initialize接下来就会创建一个BrowserMainLoop对象，并且调用这个BrowserMainLoop对象的成员函数Init执行初始化工作，如下所示：

void BrowserMainLoop::Init() {
  ......
  parts_.reset(
      GetContentClient()->browser()->CreateBrowserMainParts(parameters_));
}

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

BrowserMainLoop对象的成员函数Init的主要任务是创建一个BrowserMainParts对象，并且保存在成员变量parts_中。后面会通过这个BrowserMainParts对象执行一些初始化工作。

为了创建这个BrowserMainParts对象，BrowserMainLoop对象的成员函数Init首先调用函数GetContentClient获得一个ContentClient对象。对于Chrome APK来说，这个ContentClient对象的实际类型为ChromeContentClient，也就是这里调用函数GetContentClient获得的是一个ChromeContentClient对象。

有了这个ChromeContentClient对象之后，就可以调用它的成员函数browser获得一个ChromeContentBrowserClient对象。有了这个ChromeContentBrowserClient对象，就可以调用它的成员函数CreateBrowserMainParts创建一个BrowserMainParts对象了，如下所示：

content::BrowserMainParts* ChromeContentBrowserClient::CreateBrowserMainParts(
    const content::MainFunctionParams& parameters) {
  ChromeBrowserMainParts* main_parts;
  // Construct the Main browser parts based on the OS type.
#if defined(OS_WIN)
  main_parts = new ChromeBrowserMainPartsWin(parameters);
#elif defined(OS_MACOSX)
  main_parts = new ChromeBrowserMainPartsMac(parameters);
#elif defined(OS_CHROMEOS)
  main_parts = new chromeos::ChromeBrowserMainPartsChromeos(parameters);
#elif defined(OS_LINUX)
  main_parts = new ChromeBrowserMainPartsLinux(parameters);
#elif defined(OS_ANDROID)
  main_parts = new ChromeBrowserMainPartsAndroid(parameters);
#elif defined(OS_POSIX)
  main_parts = new ChromeBrowserMainPartsPosix(parameters);
#else
  NOTREACHED();
  main_parts = new ChromeBrowserMainParts(parameters);
#endif

  ......

  return main_parts;
}

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

从这里可以看到，在Android平台上，ChromeContentBrowserClient类的成员函数CreateBrowserMainParts创建的是一个ChromeBrowserMainPartsAndroid对象。这个ChromeBrowserMainPartsAndroid对象是从ChromeBrowserMainParts类继承下来的。

这一步执行完成之后，BrowserMainLoop对象的成员函数Init就创建了一个ChromeBrowserMainPartsAndroid对象，并且保存在成员变量parts_中。回到前面分析的BrowserMainRunnerImpl类的成员函数Initialize中，它最后会调用前面已经初始化好的BrowserMainLoop对象的成员函数CreateStartupTasks创建一系列Startup Tasks，用来初始化Content模块。这其中就包含了一个类型为PreMainMessageLoopRun的Startup Task，也就是在Browser进程的主线程进入消息循环前执行的Startup Task，如下所示：

void BrowserMainLoop::CreateStartupTasks() {
  .....

  // First time through, we really want to create all the tasks
  if (!startup_task_runner_.get()) {
#if defined(OS_ANDROID)
    startup_task_runner_ = make_scoped_ptr(new StartupTaskRunner(
        base::Bind(&BrowserStartupComplete),
        base::MessageLoop::current()->message_loop_proxy()));
#else
    startup_task_runner_ = make_scoped_ptr(new StartupTaskRunner(
        base::Callback<void(int)>(),
        base::MessageLoop::current()->message_loop_proxy()));
#endif
    ......

    StartupTask pre_main_message_loop_run = base::Bind(
        &BrowserMainLoop::PreMainMessageLoopRun, base::Unretained(this));
    startup_task_runner_->AddTask(pre_main_message_loop_run);

    ......
  }
#if defined(OS_ANDROID)
  if (!BrowserMayStartAsynchronously()) {
    // A second request for asynchronous startup can be ignored, so
    // StartupRunningTasksAsync is only called first time through. If, however,
    // this is a request for synchronous startup then it must override any
    // previous call for async startup, so we call RunAllTasksNow()
    // unconditionally.
    startup_task_runner_->RunAllTasksNow();
  }
#else
  startup_task_runner_->RunAllTasksNow();
#endif
}

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

BrowserMainLoop类的成员函数CreateStartupTasks首先会检查成员变量startup_task_runner_是否还没有指向一个StartupTaskRunner对象。如果没有指向，那么就会创建一个StartupTaskRunner对象让它指向。这个StartupTaskRunner对象可以用来向当前线程（Browser进程的主线程）的消息队列发送消息，从而可以执行指定的Startup Task。

类型为PreMainMessageLoopRun的Startup Task绑定了BrowserMainLoop类的成员函数PreMainMessageLoopRun。这意味着接下来BrowserMainLoop类的成员函数PreMainMessageLoopRun会在Browser进程的主线程执行，如下所示：

int BrowserMainLoop::PreMainMessageLoopRun() {
  if (parts_) {
    ......
    parts_->PreMainMessageLoopRun();
  }

  ......
  return result_code_;
}

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

从前面的分析可以知道，BrowserMainLoop类的成员变量parts_指向的是一个ChromeBrowserMainPartsAndroid对象。BrowserMainLoop类的成员函数PreMainMessageLoopRun调用这个ChromeBrowserMainPartsAndroid对象的成员函数PreMainMessageLoopRun执行Browser进程在PreMainMessageLoopRun阶段的初始化工作。

ChromeBrowserMainPartsAndroid类的成员函数PreMainMessageLoopRun是从父类ChromeBrowserMainParts继承下来的，它的实现如下所示：

void ChromeBrowserMainParts::PreMainMessageLoopRun() {
  ......

  result_code_ = PreMainMessageLoopRunImpl();

  ......
}

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

ChromeBrowserMainParts类的成员函数PreMainMessageLoopRun调用另外一个成员函数PreMainMessageLoopRunImpl执行Browser进程在PreMainMessageLoopRun阶段的初始化工作，如下所示：

int ChromeBrowserMainParts::PreMainMessageLoopRunImpl() {
  ......

  profile_ = CreatePrimaryProfile(parameters(),
                                  user_data_dir_,
                                  parsed_command_line());
  ......

  return result_code_;
}

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

ChromeBrowserMainParts类的成员函数PreMainMessageLoopRunImpl执行了一系列的初始化工作。其中的一个初始化工作是为当前登录的用户创建Profile。这是通过调用函数CreatePrimaryProfile实现的。在创建Profile的过程中，就会加载为当前登录的用户安装的Extension。

接下来我们就继续分析函数CreatePrimaryProfile的实现，如下所示：

Profile* CreatePrimaryProfile(const content::MainFunctionParams& parameters,
                              const base::FilePath& user_data_dir,
                              const CommandLine& parsed_command_line) {
  ......

  Profile* profile = NULL;
#if defined(OS_CHROMEOS) || defined(OS_ANDROID)
  ......
  profile = ProfileManager::GetActiveUserProfile();
#else
  ......
#endif
  if (profile) {
    ......
    return profile;
  }

  ......

  return NULL;
}

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

在Android平台上，函数CreatePrimaryProfile调用ProfileManager类的静态成员函数GetActiveUserProfile获得当前用户的Profile，如下所示：

Profile* ProfileManager::GetActiveUserProfile() {
  ProfileManager* profile_manager = g_browser_process->profile_manager();
  ......
  Profile* profile =
      profile_manager->GetActiveUserOrOffTheRecordProfileFromPath(
          profile_manager->user_data_dir());
  ......
  return profile;
}

这个函数定义在文件external/chromium_org/chrome/browser/profiles/profile_manager.cc中。

ProfileManager类的静态成员函数GetActiveUserProfile首先在当前进程（Browser进程）中获得一个ProfileManager单例对象。通过调用这个ProfileManager单例对象的成员函数user_data_dir可以获得当前用户的数据目录。有了这个数据目录之后，再调用上述ProfileManager单例对象的成员函数GetActiveUserOrOffTheRecordProfileFromPath就可以获得当前用户的Profile，如下所示：

Profile* ProfileManager::GetActiveUserOrOffTheRecordProfileFromPath(
    const base::FilePath& user_data_dir) {
#if defined(OS_CHROMEOS)
  ......
#else
  base::FilePath default_profile_dir(user_data_dir);
  default_profile_dir = default_profile_dir.Append(GetInitialProfileDir());
  return GetProfile(default_profile_dir);
#endif
}

这个函数定义在文件external/chromium_org/chrome/browser/profiles/profile_manager.cc中。

ProfileManager类的成员函数GetActiveUserOrOffTheRecordProfileFromPath首先调用另外一个成员函数etInitialProfileDir获得Profile目录。这个Profile目录是相对参数user_data_dir描述的数据目录之下的。将Profile目录添加到数据目录之后，就得到Profile目录的绝对路径。有了这个绝对路径之后，ProfileManager类的成员函数GetActiveUserOrOffTheRecordProfileFromPath就调用成员函数GetProfile获得当前用户的Profile，如下所示：

Profile* ProfileManager::GetProfile(const base::FilePath& profile_dir) {
  TRACE_EVENT0("browser", "ProfileManager::GetProfile")
  // If the profile is already loaded (e.g., chrome.exe launched twice), just
  // return it.
  Profile* profile = GetProfileByPath(profile_dir);
  if (NULL != profile)
    return profile;

  profile = CreateProfileHelper(profile_dir);
  DCHECK(profile);
  if (profile) {
    bool result = AddProfile(profile);
    DCHECK(result);
  }
  return profile;
}

这个函数定义在文件external/chromium_org/chrome/browser/profiles/profile_manager.cc中。

ProfileManager类的成员函数GetProfile首先调用成员函数GetProfileInfoByPath检查是否已经为参数profile_dir描述的Profile目录创建过Profile。如果已经创建，那么就将该Profile返回给调用者。否则的话，就会调用成员函数CreateProfileHelper为参数profile_dir描述的Profile目录创建一个Profile，并且调用另外一个成员函数AddProfile将其保存在内部，以及返回给调用者。

ProfileManager类的成员函数AddProfile在将当前用户的Profile保存在内部之后，会根据Profile的内容执行相应初始化工作，如下所示：

bool ProfileManager::AddProfile(Profile* profile) {
  ......

  RegisterProfile(profile, true);
  ......
  DoFinalInit(profile, ShouldGoOffTheRecord(profile));
  return true;
}

这个函数定义在文件external/chromium_org/chrome/browser/profiles/profile_manager.cc中。

ProfileManager类的成员函数AddProfile首先调用成员函数RegisterProfile将参数profile描述的Profile保存在内部，接下来调用另外一个成员函数DoFinalnit根据该Profile执行相应的初始化工作，其中就包括创建Extension Service，如下所示：

void ProfileManager::DoFinalInit(Profile* profile, bool go_off_the_record) {
  DoFinalInitForServices(profile, go_off_the_record);
  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/profiles/profile_manager.cc中。

ProfileManager类的成员函数DoFinalnit是在调用成员函数DoFinalInitForServices的过程中创建Extension Service的，如下所示：

void ProfileManager::DoFinalInitForServices(Profile* profile,
                                            bool go_off_the_record) {
#if defined(ENABLE_EXTENSIONS)
  extensions::ExtensionSystem::Get(profile)->InitForRegularProfile(
      !go_off_the_record);
  ......
#endif
  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/profiles/profile_manager.cc中。

从这里可以看到，在定义了宏ENABLE_EXTENSIONS的情况下，Chromium才会支持Extension。这时候ProfileManager类的成员函数DoFinalInitForServices首先根据参数profile描述的Profile获得一个ExtensionSystemImpl对象，然后再调用这个ExtensionSystemImpl对象的成员函数InitForRegularProfile创建一个Extension Service，如下所示：

void ExtensionSystemImpl::InitForRegularProfile(bool extensions_enabled) {
  ......

  process_manager_.reset(ProcessManager::Create(profile_));

  shared_->Init(extensions_enabled);
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_system_impl.cc中。

ExtensionSystemImpl类的成员函数InitForRegularProfile首先会调用ProcessManager类的静态成员函数Create创建一个ProcessManager对象，并且保存在成员变量process_manager_。在接下来一篇文章中，我们就会看到，Extension的Background Page就是通过这个ProcessManager对象加载起来的。

ExtensionSystemImpl类的成员变量shared_指向的是一个ExtensionSystemImpl::Shared对象。ExtensionSystemImpl类的成员函数InitForRegularProfile调用这个ExtensionSystemImpl::Shared对象的成员函数Init创建一个Extension Service，如下所示：

void ExtensionSystemImpl::Shared::Init(bool extensions_enabled) {
  ......

  user_script_master_ = new UserScriptMaster(profile_);
  ......

  extension_service_.reset(new ExtensionService(
      profile_,
      CommandLine::ForCurrentProcess(),
      profile_->GetPath().AppendASCII(extensions::kInstallDirectoryName),
      ExtensionPrefs::Get(profile_),
      blacklist_.get(),
      autoupdate_enabled,
      extensions_enabled,
      &ready_));
  ......

  extension_service_->Init();
 
  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_system_impl.cc中。

Extension Service通过一个ExtensionService对象描述。ExtensionSystemImpl::Shared类的成员函数Init创建了这个ExtensionService对象之后，会保存在成员变量extension_service_中，并且调用这个ExtensionService对象的成员函数对其描述的Extension Service进行初始化，如下所示：

此外，我们还看到，ExtensionSystemImpl::Shared类的成员函数Init还创建了一个UserScriptMaster对象保存在成员变量user_script_master_中。这个UserScriptMaster是用来管理接下来要加载的Extension的Content Script的。这一点我们在后面的文章会进行详细分析。

现在，我们主要关注Extension Service的初始化过程。因此，接下来我们继续分析ExtensionService类的成员函数Init的实现，如下所示：

void ExtensionService::Init() {
  ......

  const CommandLine* cmd_line = CommandLine::ForCurrentProcess();
  if (cmd_line->HasSwitch(switches::kInstallFromWebstore) ||
      cmd_line->HasSwitch(switches::kLimitedInstallFromWebstore)) {
    ......
  } else {
    ......

    // LoadAllExtensions() calls OnLoadedInstalledExtensions().
    ......
    extensions::InstalledLoader(this).LoadAllExtensions();
    ......

    // Attempt to re-enable extensions whose only disable reason is reloading.
    std::vector<std::string> extensions_to_enable;
    const ExtensionSet& disabled_extensions = registry_->disabled_extensions();
    for (ExtensionSet::const_iterator iter = disabled_extensions.begin();
        iter != disabled_extensions.end(); ++iter) {
      const Extension* e = iter->get();
      if (extension_prefs_->GetDisableReasons(e->id()) ==
          Extension::DISABLE_RELOAD) {
        extensions_to_enable.push_back(e->id());
      }
    }
    for (std::vector<std::string>::iterator it = extensions_to_enable.begin();
         it != extensions_to_enable.end(); ++it) {
      EnableExtension(*it);
    }
 
    ......
  }

  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_service.cc中。

ExtensionService类的成员函数Init首先检查Browser进程的启动参数是否包含有switches::kInstallFromWebstore或者switches::kLimitedInstallFromWebstore选项。如果包含有，那么就只会从Web Store上加载当前用户的Extension。我们假设没有包含这两个选项，那么ExtensionService类的成员函数Init将会从本地加载当前用户的Extension。

ExtensionService类的成员函数Init首先构造一个InstalledLoader对象，然后再调用这个InstalledLoader对象的成员函数LoadAllExtensions加载当前用户安装的所有Extension。这些加载的Extension，即有Enabled的，也有Disabled的。

加载后的Extension会保存在ExtensionService类的成员变量registry_描述的一个Extension Registry中。ExtensionService类的成员函数Init最后会从这个Extension Registry获得那些处于Enabled状态的Extension，并且调用另外一个成员函数EnableExtension启用它们。

接下来，我们主要关注Extension的加载过程。因此，我们继续分析InstalledLoader类的成员函数LoadAllExtensions的实现，如下所示：

void InstalledLoader::LoadAllExtensions() {
  ......

  Profile* profile = extension_service_->profile();
  scoped_ptr<ExtensionPrefs::ExtensionsInfo> extensions_info(
      extension_prefs_->GetInstalledExtensionsInfo());

  ......

  for (size_t i = 0; i < extensions_info->size(); ++i) {
    if (extensions_info->at(i)->extension_location != Manifest::COMMAND_LINE)
      Load(*extensions_info->at(i), should_write_prefs);
  }

  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/installed_loader.cc中。

InstalledLoader类的成员函数LoadAllExtensions首先获得当前用户安装的所有Extension。注意，这些Extension既包括用户在“chrome://extensions”页面中安装的Extension，也包括用户在启动Chromium时通过命令行参数“--load-extension”指定的Extension。不过，InstalledLoader类的成员函数LoadAllExtensions只会加载那些非命令行参数指定的Extension。对于命令行参数指定的Extension，在Extension Service初始化结束后，Extension System会通过另外一个Unpacked Installer来加载它们。

InstalledLoader类的成员函数LoadAllExtensions是通过调用另外一个成员函数Load加载那些非命令行参数指定的Extension的，如下所示：

void InstalledLoader::Load(const ExtensionInfo& info, bool write_to_prefs) {
  std::string error;
  scoped_refptr<const Extension> extension(NULL);
  if (info.extension_manifest) {
    extension = Extension::Create(
        info.extension_path,
        info.extension_location,
        *info.extension_manifest,
        GetCreationFlags(&info),
        &error);
  } else {
    error = errors::kManifestUnreadable;
  }

  ......

  extension_service_->AddExtension(extension.get());
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/installed_loader.cc中。

InstalledLoader类的成员函数Load首先是根据参数info描述的Extension Info创建一个Extension对象，这是通过调用Extension类的静态成员函数Create实现的。这个Extension对象最终会交给前面创建的Extension Service处理。当Extension Service处理完毕，参数info描述的Extension就加载完毕。

InstalledLoader类的成员变量extension_service_指向的是一个ExtensionService对象。这个ExtensionService对象描述的就是前面创建的Extension Service。通过调用这个ExtensionService对象的成员函数AddExtension即可以将参数info描述的Extension交给前面创建的Extension Service处理。处理过程如下所示：

void ExtensionService::AddExtension(const Extension* extension) {
  ......

  if (extension_prefs_->IsExtensionBlacklisted(extension->id())) {
    ......
    registry_->AddBlacklisted(extension);
  } else if (!reloading &&
             extension_prefs_->IsExtensionDisabled(extension->id())) {
    registry_->AddDisabled(extension);
    ......
  } else if (reloading) {
    ......
    EnableExtension(extension->id());
  } else {
    ......
    registry_->AddEnabled(extension);
    ......
    NotifyExtensionLoaded(extension);
  }
  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_service.cc中。

ExtensionService类的成员函数AddExtension会判断参数extension描述的Extension的状态，并且执行的操作：

1. 如果它被用户列入黑名单，那么就将它记录在Extension Registry内部的Black List上。

2. 如果它被用户禁用，那么将它记录在Extension Registry内部的Disabled List上。

3. 如果它被重新加载，那么对它执行一个Enable操作。

4. 如果它是第一次加载，那么将它记录在Extension Registry内部的Enabled List上。

接下来我们主要关注第4种情况。这时候ExtensionService类的成员函数AddExtension首先会调用成员变量registry_指向的一个ExtensionRegistry对象的成员函数AddEnabled将参数extension描述的Extension记录在Extension Registry内部的Enabled List上，接下来又调用另外一个成员函数NotifyExtensionLoaded通知其它模块，有一个新的Extension被加载。

接下来我们就继续分析ExtensionRegistry类的成员函数AddEnabled和ExtensionService类的成员函数NotifyExtensionLoaded的实现，以便完整了解Extension的加载过程。

ExtensionRegistry类的成员函数AddEnabled的实现如下所示：

bool ExtensionRegistry::AddEnabled(
    const scoped_refptr<const Extension>& extension) {
  return enabled_extensions_.Insert(extension);
}

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

ExtensionRegistry类的成员变量enabled_extensions_描述的就是一个Enabled List，因此ExtensionRegistry类的成员函数AddEnabled会将参数extension描述的Extension保存在里面。

ExtensionService类的成员函数NotifyExtensionLoaded的实现如下所示：

void ExtensionService::NotifyExtensionLoaded(const Extension* extension) {
  ......

  registry_->TriggerOnLoaded(extension);
 
  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_service.cc中。

ExtensionService类的成员函数NotifyExtensionLoaded会通过Extension Registry通知其它模块有一个新的Extension被加载，这是通过调用成员变量registry_指向的一个ExtensionRegistry对象的成员函数TriggerOnLoaded实现的，如下所示：

void ExtensionRegistry::TriggerOnLoaded(const Extension* extension) {
  DCHECK(enabled_extensions_.Contains(extension->id()));
  FOR_EACH_OBSERVER(ExtensionRegistryObserver,
                    observers_,
                    OnExtensionLoaded(browser_context_, extension));
}

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

一个模块如果需要关注新加载的Extension，那么就会注册一个Extension Registry Observer到Extension Registry的内部。这些Extension Registry Observer保存在ExtensionRegistry类的成员变量observers_描述的一个List中。

ExtensionRegistry类的成员函数TriggerOnLoaded所做的事情就是调用每一个注册在Extension Registry中的Extension Registry Observer的成员函数OnExtensionLoaded，分别通知它们有一个新的Extension被加载。在后面的文章中，我们就会看到，负责管理Content Script的User Script Master模块会注册一个Extension Registry Observer到Extension Registry，目的就是获取每一个新加载的Extension指定的Content Script，以便在合适的时候注入到宿主网页中去执行。

至此，我们就分析完成了Chromium加载Extension的过程。这是在Extension Service的初始化过程中执行的。这个Extension Service又是在Chromium为当前用户创建Profile的过程中启动的。最后，为当前用户创建Profile的操作是在Chromium启动的过程中执行的。这意味着Extension是在Chromium启动的时候加载的，也就是在Chromium的Browser进程启动时加载。在接下来的一篇文章中，我们继续分析Extension的Background Page和Popup Page的加载过程，敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/9/12 0:59:50 原文链接

阅读：39156 评论：6 查看评论

↧

Chromium扩展（Extension）的页面（Page）加载过程分析

September 19, 2016, 1:00 am

≫ Next: Chromium扩展（Extension）的Content Script加载过程分析

≪ Previous: Chromium扩展（Extension）加载过程分析

Chromium的Extension Page其实就是网页，因此它们的加载过程与普通网页相同。常见的Extension Page有Background Page和Popup Page。其中，Background Page在浏览器窗口初始化完成后自动加载，之后运行在后台中。Popup Page在用户点击地址栏右边的按钮时加载，并且显示在弹窗中。本文接下来就分析Extension Page的加载过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

Extension Page是加载在Extension Process中的，如图1所示：

图1 Extension的Background Page和Popup Page的加载示意图

Extension Process实际上就是Render Process。Chromium的Content层向外提供了一个WebContents类，通过调用这个类的静态成员函数Create就可以在一个Extension Process加载一个指定的Extension Page。

Background Page是一个特殊的网页，它的内容是空的，不过包含有一个background.js。这个background.js是在Extension的清单文件中指定的。Popup Page则与普通网页是一样的，它既可以包含有UI元素，也可以包含JavaScript脚本。

接下来，我们就结合源代码，先分析Background Page的加载过程，再分析Popup Page的加载过程。

Chromium的chrome模块会创建一个ChromeNotificationObserver对象，用来监听每一个新打开的浏览器窗口的NOTIFICATION_BROWSER_WINDOW_READY事件。这时候上述ChromeNotificationObserver对象的成员函数OnBrowserWindowReady会被调用，如下所示：

void ChromeNotificationObserver::OnBrowserWindowReady(Browser* browser) {
  Profile* profile = browser->profile();
  ......

  extensions::ProcessManager* manager =
      ExtensionSystem::Get(profile)->process_manager();
  ......

  manager->OnBrowserWindowReady();

  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/chrome_notification_observer.cc中。

参数browser指向的是一个Browser对象。这个Browser对象描述的就是一个新打开的浏览器窗口，ChromeNotificationObserver类的成员函数OnBrowserWindowReady首先调用它的成员函数profile获得浏览器在启动过程中创建的Profile，然后再根据这个Profile获得一个ProcessManager对象。有了这个ProcessManager对象之后，就可以调用它的成员函数OnBrowserWindowReady，用来通知它有一个新的浏览器窗口打开了。浏览器启动时创建Profile的过程，以及根据Profile创建ProcessManager对象的过程，可以参考前面Chromium扩展（Extension）加载过程分析一文。

ProcessManager类的成员函数OnBrowserWindowReady在执行的过程中，就会为当前加载的Extension创建Background Page，如下所示：

void ProcessManager::OnBrowserWindowReady() {
  ......

  CreateBackgroundHostsForProfileStartup();
}

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

ProcessManager类的成员函数OnBrowserWindowReady调用另外一个成员函数CreateBackgroundHostsForProfileStartup为当前加载的Extension创建Background Page，如下所示：

void ProcessManager::CreateBackgroundHostsForProfileStartup() {
  ......

  const ExtensionSet& enabled_extensions =
      ExtensionRegistry::Get(GetBrowserContext())->enabled_extensions();
  for (ExtensionSet::const_iterator extension = enabled_extensions.begin();
       extension != enabled_extensions.end();
       ++extension) {
    CreateBackgroundHostForExtensionLoad(this, extension->get());

    ......
  }

  ......
}

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

在前面Chromium扩展（Extension）加载过程分析一文提到，Chromium的Browser进程在启动的时候，会将那些状态设置为Enabled的Extension保存在一个Extension Registry的Enabled List中。ProcessManager类的成员函数CreateBackgroundHostsForProfileStartup主要就是遍历这个Enabled List中的每一个Extension，并且调用函数CreateBackgroundHostForExtensionLoad检查它们是否指定了Background Page。如果指定了，那么就会进行加载。

函数CreateBackgroundHostForExtensionLoad的实现如下所示：

static void CreateBackgroundHostForExtensionLoad(
    ProcessManager* manager, const Extension* extension) {
  DVLOG(1) << "CreateBackgroundHostForExtensionLoad";
  if (BackgroundInfo::HasPersistentBackgroundPage(extension))
    manager->CreateBackgroundHost(extension,
                                  BackgroundInfo::GetBackgroundURL(extension));
}

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

函数CreateBackgroundHostForExtensionLoad首先检查参数extension描述的Extension是否指定了类型为persitent的Background Page。如果指定了，那么就会调用参数manager指向的一个ProcessManager对象的成员函数CreateBackgroundHost对它进行加载。对于非persitent的Background Page，它们只会在特定事件发生时，才会被加载。本文主要以类型为persitent的Background Page为例，说明它们的加载过程。非persitent的Background Page的加载过程，也是类似的。

函数CreateBackgroundHostForExtensionLoad在调用ProcessManager类的成员函数CreateBackgroundHost加载一个Background Page之前，首先要获得这个Background Page的URL。这个URL是通过调用BackgroundInfo类的静态成员函数GetBackgroundURL获得的，如下所示：

GURL BackgroundInfo::GetBackgroundURL(const Extension* extension) {
  const BackgroundInfo& info = GetBackgroundInfo(extension);
  if (info.background_scripts_.empty())
    return info.background_url_;
  return extension->GetResourceURL(kGeneratedBackgroundPageFilename);
}

这个函数定义在文件external/chromium_org/extensions/common/manifest_handlers/background_info.cc中。

Chromium将其平台上的程序分为扩展（Extension）和应用（App）两种。两者具有相同的文件结构，在Chromium中都是通过一个Extension类描述，但是后者比前者具有更严格的权限限制。应用又分为Hosted App（托管应用）和Packaged App（打包应用）两种。Hosted App只提供一个图标和Manifest文件，并且在Manifest文件中声明了它的Popup Page和Background Page等URL。Packaged App则将Popup Page和Background Page文件打包在一起安装在本地。关于Extension、Hosted App和Packaged App的更详细描述，可以参考Chrome应用基础一文。

我们假设参数extension描述的是一个Extension，并且是一个安装在本地的Extension。这时候它在Manifest文件实际上只是为Backgropund Page指定了Background Script，如我们在前面Chromium扩展（Extension）机制简要介绍和学习计划一文所示的Page action example：

{  
  ......  
  
  "background": {  
    "scripts": ["background.js"]  
  },  

  ......
}

BackgroundInfo类的静态成员函数GetBackgroundURL首先会获得参数extension描述的Extension的Background Page信息。这些信息保存在一个BackgroundInfo对象中。当这个BackgroundInfo对象的成员变量background_scripts_的字符串不为空时，这个字符串描述的就是一个Background Page的Background Script，同时也表明参数extension描述的不是一个Hosted App。在这种情况下，我们就不能直接获得Background Page的URL，而是要通过调用参数extension指向的Extension对象的成员函数GetResourceURL获得。

Extension类的成员函数GetResourceURL的实现如下所示：

class Extension : public base::RefCountedThreadSafe<Extension> {
 public:
  ......

  GURL GetResourceURL(const std::string& relative_path) const {
    return GetResourceURL(url(), relative_path);
  }

  ......
};

这个函数定义在文件external/chromium_org/extensions/common/extension.h中。

从前面的调用过程可以知道，参数relative_path的值为kGeneratedBackgroundPageFilename。Extension类的成员函数GetResourceURL首先调用另外一个成员函数url获得当前正在处理的Extension的URL。这个URL的形式为：chrome-extension://[extension_id]/。其中，[extension_id]为当前正在处理的Extension的ID。

最后，Extension类的成员函数GetResourceURL将参数relative_path的值kGeneratedBackgroundPageFilename添加在前面获得的URL的后面，从而得到当前正在处理的Extension的Background Page的URL。这是通过调用Extension类的静态成员函数GetResourceURL实现的，如下所示：

// static
GURL Extension::GetResourceURL(const GURL& extension_url,
                               const std::string& relative_path) {
  ......

  std::string path = relative_path;

  // If the relative path starts with "/", it is "absolute" relative to the
  // extension base directory, but extension_url is already specified to refer
  // to that base directory, so strip the leading "/" if present.
  if (relative_path.size() > 0 && relative_path[0] == '/')
    path = relative_path.substr(1);

  GURL ret_val = GURL(extension_url.spec() + path);
  ......

  return ret_val;
}

这个函数定义在文件external/chromium_org/extensions/common/extension.cc中。

通过上面的分析，我们就可以知道，一个Extension如果指定了Background Page，那么这个Background Page的URL就为chrome-extension://[extension_id]/kGeneratedBackgroundPageFilename。其中，kGeneratedBackgroundPageFilename是一个常量，它的定义如下所示：

const char kGeneratedBackgroundPageFilename[] =
    "_generated_background_page.html";

这个常量定义在文件external/chromium_org/extensions/common/constants.cc中。

这意味着，一个Extension的Background Page的URL为：chrome-extension://[extension_id]/_generated_background_page.html。Chromium的extension模块会注册一个Chromium Extension Protocol Handler，用来处理chrome-extension协议。也就是说，当我们在浏览器的地址栏输入上述URL时Chromium Extension Protocol Handler会返回[extension_id]/_generated_background_page.html的内容给WebKit处理。这个文件的内容是动态生成的。以前面的Page action example为例，Chromium Extension Protocol Handler为它生成的_generated_background_page.html的内容如下所示：

<!DOCTYPE html>
<body>
<script src="background.js"></script>

获得了要加载的Background Page的URL之后，回到前面分析的函数CreateBackgroundHostForExtensionLoad中，接下来它就会调用ProcessManager类的成员函数CreateBackgroundHost加载Background Page，如下所示：

bool ProcessManager::CreateBackgroundHost(const Extension* extension,
                                          const GURL& url) {
  ......

  ExtensionHost* host =
      new ExtensionHost(extension, GetSiteInstanceForURL(url), url,
                        VIEW_TYPE_EXTENSION_BACKGROUND_PAGE);
  host->CreateRenderViewSoon();
  ......
  return true;
}

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

ProcessManager类的成员函数CreateBackgroundHost首先是创建一个ExtensionHost对象。这个ExtensionHost对象类似于Chromium加载一个普通URL时在Browser进程中创建的RenderProcessHost对象。关于RenderProcessHost的详细描述，可以参考Chromium多进程架构简要介绍和学习计划这个系列的文章。

ExtensionHost对象在创建的过程中，会创建一个WebContents对象，如下所示：

ExtensionHost::ExtensionHost(const Extension* extension,
                             SiteInstance* site_instance,
                             const GURL& url,
                             ViewType host_type)
    : ......,
      initial_url_(url),
      ...... {
  ......

  host_contents_.reset(WebContents::Create(
      WebContents::CreateParams(browser_context_, site_instance))),
  
  ......
}

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

创建出来的WebContents对象保存在ExtensionHost类的成员变量host_contents_中。同时，要加载的Background Page URL将会保存在ExtensionHost类的成员变量initial_url_中。

回到前面分析的ProcessManager类的成员函数CreateBackgroundHost，它创建了一个ExtensionHost对象之后，接下来就会调用这个ExtensionHost对象的成员函数CreateRenderViewSoon加载指定的Background Page，如下所示：

void ExtensionHost::CreateRenderViewSoon() {
  if ((render_process_host() && render_process_host()->HasConnection())) {
    // If the process is already started, go ahead and initialize the RenderView
    // synchronously. The process creation is the real meaty part that we want
    // to defer.
    CreateRenderViewNow();
  } else {
    ProcessCreationQueue::GetInstance()->CreateSoon(this);
  }
}

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

ExtensionHost类的成员函数CreateRenderViewSoon首先判断用来加载指定的Background Page的Extension Process是否已经创建出来了。如果已经创建，那么就直接调用另外一个成员函数CreateRenderViewNow同步请求在这个Extension Process中加载指定的Background Page。否则的话，则需要通过调用当前进程中的一个ProcessCreationQueue单例对象的成员函数CreateSoon异步请求加载指定的的Background Page。后一种情况之所以要异步请求，是因为这种情况需要先创建一个Extension Process，然后才能加载指定的Background Page，而创建Extension Process是一个相对耗时的操作。

在异步请求情况下，指定的Background Page同样也是通过ExtensionHost类的成员函数CreateRenderViewNow进行加载的。因此，接下来我们继续分析它的实现，如下所示：

void ExtensionHost::CreateRenderViewNow() {
  LoadInitialURL();
  ......
}

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

ExtensionHost类的成员函数CreateRenderViewNow调用另外一个成员函数LoadInitialURL加载指定的Background Page，如下所示：

void ExtensionHost::LoadInitialURL() {
  host_contents_->GetController().LoadURL(
      initial_url_, content::Referrer(), content::PAGE_TRANSITION_LINK,
      std::string());
}

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

从前面的分析可以知道，指定要加载的Background Page的URL保存在ExtensionHost类的成员变量initial_url_中。ExtensionHost类的成员函数LoadInitialURL首先通过调用成员变量host_contents_指向的WebContents对象的成员函数GetController获得一个NavigationControllerImpl对象。有了这个NavigationControllerImpl对象之后，就可以调用它的成员函数LoadURL在相应的Extension Process中加载指定的Background Page了。这个过程与加载一个普通的URL是一样的，具体可以参考前面Chromium网页Frame Tree创建过程分析一文。

这样，我们就分析完成了Extension的Background Page的加载过程。从分析的过程可以知道，Extension的Background Page本质上是一个保存在本地的网页，因此它的加载过程与普通的URL并无异。接下来，我们继续分析Extension的Popup Page的加载过程。

从前面Chromium扩展（Extension）机制简要介绍和学习计划一文可以知道，Browser Action和Page Action均可在地址栏右边放置一个按钮，并且在点击该按钮时，显示一个Popup Page。两者加载Popup Page的原理都是一样的，因此接下来我们以Browser Action为例，分析Popup Page的加载过程。

当一个Extension指定了Browser Action时，Chromium将会为其创建一个BrowserActionButton。这个BrowserActionButton描述的就是Extension在地址栏右边的按钮。当用户点击这个按钮的时候，BrowserActionButton类的成员函数ButtonPressed就会被调用，如下所示：

void BrowserActionButton::ButtonPressed(views::Button* sender,
                                        const ui::Event& event) {
  delegate_->OnBrowserActionExecuted(this);
}

这个函数定义在文件external/chromium_org/chrome/browser/ui/views/toolbar/browser_action_view.cc中。

BrowserActionButton类的成员变量delegate_指向的是一个BrowserActionsContainer对象。这个BrowserActionsContainer对象描述的是包含Browser Action Button的容器，BrowserActionButton类的成员函数ButtonPressed调用它的成员函数OnBrowserActionExecuted，通知它在一个弹出窗口中加载一个Popup Page。

BrowserActionsContainer类的成员函数OnBrowserActionExecuted的实现如下所示：

void BrowserActionsContainer::OnBrowserActionExecuted(
    BrowserActionButton* button) {
  ShowPopup(button, ExtensionPopup::SHOW, true);
}

这个函数定义在文件external/chromium_org/chrome/browser/ui/views/toolbar/browser_actions_container.cc中。

BrowserActionsContainer类的成员函数OnBrowserActionExecuted调用另外一个成员函数ShowPopup显示一个Popup Page，如下所示：

bool BrowserActionsContainer::ShowPopup(
    BrowserActionButton* button,
    ExtensionPopup::ShowAction show_action,
    bool should_grant) {
  const Extension* extension = button->extension();
  GURL popup_url;
  if (model_->ExecuteBrowserAction(
          extension, browser_, &popup_url, should_grant) !=
      extensions::ExtensionToolbarModel::ACTION_SHOW_POPUP) {
    return false;
  }

  ......

  popup_ = ExtensionPopup::ShowPopup(popup_url, browser_, reference_view,
                                     views::BubbleBorder::TOP_RIGHT,
                                     show_action);
  ......

  return true;
}

这个函数定义在文件external/chromium_org/chrome/browser/ui/views/toolbar/browser_actions_container.cc中。

BrowserActionsContainer类的成员函数ShowPopup首先调用成员变量model_指向的一个ExtensionToolbarModel对象的成员函数ExecuteBrowserAction获得要显示的Popup Page的URL，如下所示：

ExtensionToolbarModel::Action ExtensionToolbarModel::ExecuteBrowserAction(
    const Extension* extension,
    Browser* browser,
    GURL* popup_url_out,
    bool should_grant) {
  ......

  ExtensionAction* browser_action =
      ExtensionActionManager::Get(profile_)->GetBrowserAction(*extension);

  ......

  if (browser_action->HasPopup(tab_id)) {
    if (popup_url_out)
      *popup_url_out = browser_action->GetPopupUrl(tab_id);
    return ACTION_SHOW_POPUP;
  }

  ......

  return ACTION_NONE;
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_toolbar_model.cc中。

参数extension描述的就是要显示Popup Page的Extension。ExtensionToolbarModel类的成员函数ExecuteBrowserAction首先通过调用ExtensionActionManager类的静态成员函数Get获得与当前使用的Profile关联的一个ExtensionActionManager对象。有了这个ExtensionActionManager对象之后，就可以获得参数extension描述的Extension在清单文件中配置的Browser Action信息。这些信息封装在一个ExtensionAction对象中。

获得了要显示Popup Page的Extension的Browser Action信息之后，就可以检查它是否指定了Popup Page。如果指定了，并且输出参数popup_url_out的值不等于NULL，那么ExtensionToolbarModel类的成员函数ExecuteBrowserAction就会调用前面获得的一个ExtensionAction对象的成员函数GetPopupUrl获得当前要显示的Popup Page的URL。获取到的Popup Page URL将会通过输出参数popup_url_out返回给调用者。

接下来我们继续分析ExtensionAction类的成员函数GetPopupUrl的实现，以便了解Extension的Popup Page URL的结构，如下所示：

GURL ExtensionAction::GetPopupUrl(int tab_id) const {
  return GetValue(&popup_url_, tab_id);
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_action.cc中。

ExtensionAction类的成员函数GetPopupUrl返回的是成员变量popup_url_的值。这个值是在ExtensionAction类的构造函数中设置的，如下所示：

ExtensionAction::ExtensionAction(const std::string& extension_id,
                                 extensions::ActionInfo::Type action_type,
                                 const extensions::ActionInfo& manifest_data)
    : extension_id_(extension_id), action_type_(action_type) {
  ......
  SetPopupUrl(kDefaultTabId, manifest_data.default_popup_url);
  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_action.cc中。

参数manifest_data指向的是一个ActionInfo对象。这个ActionInfo对象描述的是Extension在清单文件中配置的Browser Action信息。通过这个ActionInfo对象的成员变量default_popup_url可以获得为Browser Action指定的Popup Page文件名。以前面Chromium扩展（Extension）机制简要介绍和学习计划一文中的Browser action example为例，它为Browser Action指定的Popup Page文件名为“popup.html”，如下所示：

{  
  ...... 
  
  "browser_action": {  
    "default_icon": "icon.png",  
    "default_popup": "popup.html"  
  },  
  
  ......
}

回到ExtensionAction类的构造函数中，它获得的Popup Page URL将会通过调用成员函数SetPopupUrl保存在成员变量popup_url_中，如下所示：

void ExtensionAction::SetPopupUrl(int tab_id, const GURL& url) {
  ......
  SetValue(&popup_url_, tab_id, url);
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_action.cc中。

从前面的分析就可以知道，Extension的Popup Page的URL来自于ExtensionAction类的成员变量popup_url_，而后者的值又来自于ActionInfo类的成员变量default_popup_url。因此，接下来我们继续分析ActionInfo类的成员变量default_popup_url的设置过程，以便了解Extension的Popup Page URL的结构。

ActionInfo类的成员变量default_popup_url是在加载Extension的过程中设置的。一个Extension如果指定了Browser Action，那么Chromium就会调用ActionInfo类的静态成员函数Load解析Browser Action的信息，如下所示：

scoped_ptr<ActionInfo> ActionInfo::Load(const Extension* extension,
                                        const base::DictionaryValue* dict,
                                        base::string16* error) {
  scoped_ptr<ActionInfo> result(new ActionInfo());
  ......

  // Read the action's |popup| (optional).
  const char* popup_key = NULL;
  if (dict->HasKey(keys::kPageActionDefaultPopup))
    popup_key = keys::kPageActionDefaultPopup;

  ......

  if (popup_key) {
    const base::DictionaryValue* popup = NULL;
    std::string url_str;

    if (dict->GetString(popup_key, &url_str)) {
      // On success, |url_str| is set.  Nothing else to do.
    } 
    ......

    if (!url_str.empty()) {
      // An empty string is treated as having no popup.
      result->default_popup_url = Extension::GetResourceURL(extension->url(),
                                                            url_str);
      ......
    } 
    ......
  }

  return result.Pass();
}

这个函数定义在文件external/chromium_org/chrome/common/extensions/api/extension_action/action_info.cc中。

ActionInfo类的静态成员函数Load首先创建一个ActionInfo对象描述当前要解析的Browser Action的信息。

ActionInfo类的静态成员函数Load接下来检查当前要解析的Browser Action是否指定了popup属性。如果指定了，那么它的值就是一个Popup Page的文件名。这个文件名会被提取出来，保存在变量url_str中。

有了Popup Page的文件名之后，我们还需要知道它所属的Extension的URL。这可以通过调用参数extension指向的Extension对象的成员函数url获得。前面我们提到过，一个Extension的URL的形式为：chrome-extension://[extension_id]/。其中，[extension_id]为当前正在处理的Extension的ID。

有了Extension的URL之后，就可以将前面获得的Popup Page文件名附加在它之后，从而得到一个Popup Page的URL。这是通过调用Extension类的静态成员函数GetResourceURL实现的。Extension类的静态成员函数GetResourceURL我们在前面已经分析过，这里不再复述。

最后，ActionInfo类的静态成员函数Load会将获得Popup Page URL保存在前面创建的ActionInfo对象的成员变量default_popup_url中。这样，我们前面分析的ExtensionAction类的构造函数就可以通过这个成员变量获得一个Popup Page的URL，并且将它保存在自己的成员变量popup_url_中了。

这一步执行完成之后，回到前面分析的BrowserActionsContainer类的成员函数ShowPopup中，这时候就它获得了要加载的Popup Page的URL，接下来它又会通过调用ExtensionPopup类的静态成员函数ShowPopup加载该URL，如下所示：

ExtensionPopup* ExtensionPopup::ShowPopup(const GURL& url,
                                          Browser* browser,
                                          views::View* anchor_view,
                                          views::BubbleBorder::Arrow arrow,
                                          ShowAction show_action) {
  extensions::ExtensionViewHost* host =
      extensions::ExtensionViewHostFactory::CreatePopupHost(url, browser);
  ExtensionPopup* popup = new ExtensionPopup(host, anchor_view, arrow,
      show_action);

  ......

  return popup;
}

这个函数定义在文件external/chromium_org/chrome/browser/ui/views/extensions/extension_popup.cc中。

ExtensionPopup类的静态成员函数ShowPopup首先调用ExtensionViewHostFactory类的静态成员函数CreatePopupHost创建一个ExtensionViewHost对象。有了这个ExtensionViewHost对象之后，就可以将它封装在一个ExtensionPopup对象中。这个ExtensionPopup对象描述的就是当前要显示的Popup Page。

ExtensionViewHostFactory类的静态成员函数CreatePopupHost在创建ExtensionViewHost对象的过程中，就会通过前面提到的WebContents接口加载Popup Page，如下所示：

ExtensionViewHost* ExtensionViewHostFactory::CreatePopupHost(const GURL& url,
                                                             Browser* browser) {
  DCHECK(browser);
  return CreateViewHost(
      url, browser->profile(), browser, VIEW_TYPE_EXTENSION_POPUP);
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_view_host_factory.cc中。

ExtensionViewHostFactory类的静态成员函数CreatePopupHost通过调用函数CreateViewHost创建一个ExtensionViewHost对象，如下所示：

ExtensionViewHost* CreateViewHost(const GURL& url,
                                  Profile* profile,
                                  Browser* browser,
                                  extensions::ViewType view_type) {
  ......

  const Extension* extension = GetExtensionForUrl(profile, url);
  ......

  return CreateViewHostForExtension(
      extension, url, profile, browser, view_type);
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_view_host_factory.cc中。

函数CreateViewHost首先通过调用函数GetExtensionForUrl获得一个Extension对象。这个Extension对象描述的就是当前要显示Popup Page的Extension。有了这个Extension对象之后，函数CreateViewHost最后调用另外一个函数CreateViewHostForExtension创建一个ExtensionViewHost对象，如下所示：

ExtensionViewHost* CreateViewHostForExtension(const Extension* extension,
                                              const GURL& url,
                                              Profile* profile,
                                              Browser* browser,
                                              ViewType view_type) {
  ......
  ProcessManager* pm =
      ExtensionSystem::Get(profile)->process_manager();
  content::SiteInstance* site_instance = pm->GetSiteInstanceForURL(url);
  ExtensionViewHost* host =
#if defined(OS_MACOSX)
      new ExtensionViewHostMac(extension, site_instance, url, view_type);
#else
      new ExtensionViewHost(extension, site_instance, url, view_type);
#endif
  host->CreateView(browser);
  return host;
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_view_host_factory.cc中。

从这里可以看到，在非Mac OS X平台上，函数CreateViewHostForExtension会创建一个ExtensionViewHost对象。这个ExtensionViewHost对象的创建过程，也就是ExtensionViewHost的构造函数的实现，如下所示：

ExtensionViewHost::ExtensionViewHost(
    const Extension* extension,
    content::SiteInstance* site_instance,
    const GURL& url,
    ViewType host_type)
    : ExtensionHost(extension, site_instance, url, host_type),
      ...... {
  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/extension_view_host.cc中。

ExtensionViewHost类是从ExtensionHost类继承下来的。因此，ExtensionViewHost的构造函数会调用父类ExtensionHost的构造函数，用来执行初始化工作。前面我们在分析Extension的Background Page的加载过程时，已经分析过ExtensionHost类的构造函数了。它将会创建一个WebContents对象。有了这个WebContents对象之后，以后就可以加载这里的参数url描述的一个Popup Page了。

这样，我们就分析完成Extension的Popup Page的加载过程了。从分析的过程就可以看出，Extension的Popup Page与Background Page都具有自己的URL。URL的形式为chrome-extension://[extension_id]/xxx.html。这些URL都是通过Chromium的Content层向外提供的API接口WebContents在一个Extension Process中加载的。

与此同时，普通网页的URL也是通过Chromium的Content层向外提供的API接口WebContents在一个Render Process中加载的。Extension Process和Render Process的概念是一样的，都是用来加载、解析和渲染网页的。从这个角度看，Extension Page的加载、解析和渲染与一般的Web Page并无异。

至此，我们就以Background Page和Popup Page为例，分析了Extension的Page加载过程。我们在前面Chromium扩展（Extension）机制简要介绍和学习计划一文提到，Extension由Page和Content Script组成。在接下来一篇文章中，我们将继续分析Extension的Content Script的加载过程。这样我们就更加完整地理解Extension的实现原理了。敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/9/19 1:00:29 原文链接

阅读：53419 评论：7 查看评论

↧

Chromium扩展（Extension）的Content Script加载过程分析

September 26, 2016, 1:00 am

≫ Next: Chromium扩展（Extension）通信机制分析

≪ Previous: Chromium扩展（Extension）的页面（Page）加载过程分析

Chromium的Extension由Page和Content Script组成。Page有UI和JS，它们加载在自己的Extension Process中渲染和执行。Content Script只有JS，这些JS是注入在宿主网页中执行的。Content Script可以访问宿主网页的DOM Tree，从而可以增强宿主网页的功能。本文接下来分析Content Script注入到宿主网页执行的过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

我们可以在Extension的清单文件中指定Content Script对哪些网页有兴趣，如前面Chromium扩展（Extension）机制简要介绍和学习计划一文的Page action example所示：

{
  ......

  "content_scripts": [
    {
      "matches": ["https://fast.com/"],
      "js": ["content.js"],
      "run_at": "document_start",
      "all_frames": true
    }
  ]
}

这个清单文件仅对URL为“https://fast.com/”的网页感兴趣。当这个网页在Chromium中加载的时候，Chromium就会往里面注入脚本content.js。注入过程如图1所示：

图1 Content Script注入到宿主网页执行的过程

首先，在前面Chromium扩展（Extension）加载过程分析一文提到，Browser进程在加载Extension之前，会创建一个UserScriptMaster对象。此后每当加载一个Extension，这个UserScriptMaster对象的成员函数OnExtensionLoaded都会被调用，用来收集当前正在加载的Extension的Content Script。

此后，每当Browser进程启动一个Render进程时，代表该Render进程的一个RenderProcessHostImpl对象的成员函数OnProcessLaunched都会被调用，用来通知Browser进程新的Render进程已经启动起来的。这时候这个RenderProcessHostImpl对象会到上述UserScriptMaster对象中获取当前收集到的所有Content Script。这些Content Script接下来会通过一个类型为ExtensionMsg_UpdateUserScript的IPC消息传递给新启动的Render进程。新启动的Render进程通过一个Dispatcher对象接收这个IPC消息，并且会将它传递过来的Content Script保存在一个UserScriptSlave对象中。

接下来，每当Render进程加载一个网页时，都会在三个时机检查是否需要在该网页中注入Content Script。从前面Chromium扩展（Extension）机制简要介绍和学习计划一文可以知道，这三个时机分别为document_start、document_end和document_idle，分别表示网页的Document对象开始创建、结束创建以及空闲时。接下来我们以document_start这个时机为例，说明Content Script注入到宿主网页的过程。

网页的Document对象是在WebKit中创建的。WebKit为网页创建了Document对象之后，会调用Content层的一个RenderFrameImpl对象的成员函数didCreateDocumentElement，用来通知后者，它描述的网页的Document对象已经创建好了。这时候这个RenderFrameImpl对象将会调用前面提到的UserScriptSlave对象的成员函数InjectScripts，用来通知后者，现在可以将Content Script注入当前正在加载的网页中去执行。前面提到的UserScriptSlave对象会调用另外一个WebLocalFrameImpl对象的成员函数executeScriptInIsolatedWorld，用来注入符合条件的Content Script到当前正在加载的网页中去，并且在JS引擎的一个Isolated World中执行。Content Script在Isolated World中执行，意味着它不可以访问在宿主网页中定义的JavaScript，包括不能调用在宿主网页中定义的JavaScript函数，以及访问宿主网页中定义的变量。

以上就是Content Script注入到宿主网页中执行的大概流程。接下来我们结合源代码进行详细的分析，以便对这个注入流程有更深刻的认识。

我们首先分析UserScriptMaster类收集Content Script的过程。这要从UserScriptMaster类的构造函数说起，如下所示：

UserScriptMaster::UserScriptMaster(Profile* profile)
    : ......,
      extension_registry_observer_(this) {
  extension_registry_observer_.Add(ExtensionRegistry::Get(profile_));
  registrar_.Add(this, chrome::NOTIFICATION_EXTENSIONS_READY,
                 content::Source<profile>(profile_));
  registrar_.Add(this, content::NOTIFICATION_RENDERER_PROCESS_CREATED,
                 content::NotificationService::AllBrowserContextsAndSources());
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

UserScriptMaster类的成员变量extension_registry_observer_描述的是一个ExtensionRegistryObserver对象。这个ExtensionRegistryObserver对象接下来会注册到与参数profile描述的一个Profile对象关联的一个Extension Registry对象中去，也就是注入到与当前使用的Profile关联的一个Extension Registry对象中去。这个Extension Registry对象的创建过程可以参考前面Chromium扩展（Extension）加载过程分析一文。

与此同时，UserScriptMaster类的构造函数还会通过成员变量registrar_描述的一个NotificationRegistrar对象监控chrome::NOTIFICATION_EXTENSIONS_READY和content::NOTIFICATION_RENDERER_PROCESS_CREATED事件。其中，事件chrome::NOTIFICATION_EXTENSIONS_READY用来通知Chromium的Extension Service已经启动了，而事件content::NOTIFICATION_RENDERER_PROCESS_CREATED用来通知有一个新的Render进程启动起来。如前面所述，当新的Render进程启动起来的时候，UserScriptMaster类会将当前加载的Extension定义的Content Script传递给它处理。这个过程我们在后面会进行详细分析。

从前面Chromium扩展（Extension）加载过程分析一文还可以知道，接下来加载的每一个Extension，都会保存在上述Extension Registry对象内部的一个Enabled List中，并且都会调用注册在上述Extension Registry对象中的每一个ExtensionRegistryObserver对象的成员函数OnExtensionLoaded，通知它们有一个新的Extension被加载。

当UserScriptMaster类的成员变量extension_registry_observer_描述的ExtensionRegistryObserver对象的成员函数OnExtensionLoaded被调用时，它又会调用UserScriptMaster类的成员函数OnExtensionLoaded，以便UserScriptMaster类可以收集新加载的Extension定义的Content Script，如下所示：

void UserScriptMaster::OnExtensionLoaded(
    content::BrowserContext* browser_context,
    const Extension* extension) {
  // Add any content scripts inside the extension.
  extensions_info_[extension->id()] =
      ExtensionSet::ExtensionPathAndDefaultLocale(
          extension->path(), LocaleInfo::GetDefaultLocale(extension));
  ......
  const UserScriptList& scripts =
      ContentScriptsInfo::GetContentScripts(extension);
  for (UserScriptList::const_iterator iter = scripts.begin();
       iter != scripts.end();
       ++iter) {
    user_scripts_.push_back(*iter);
    .....
  }
  if (extensions_service_ready_) {
    changed_extensions_.insert(extension->id());
    if (script_reloader_.get()) {
      pending_load_ = true;
    } else {
      StartLoad();
    }
  }
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

参数extension描述的就是当前正在加载的Extension。UserScriptMaster类的成员函数OnExtensionLoaded首先会调用ExtensionSet类的静态成员函数ExtensionPathAndDefaultLocale将该Extension的Path和Locale信息封装在一个ExtensionPathAndDefaultLocale对象中，并且以该Extension的ID为键值，将上述ExtensionPathAndDefaultLocale对象保存在成员变量extensions_info_描述的一个std::map中。

UserScriptMaster类的成员函数OnExtensionLoaded接下来将当前正在加载的Extension定义的所有Content Script保存在成员变量user_scripts_描述的一个std::vector中。

UserScriptMaster类有一个类型为bool的成员变量extensions_service_ready_。当它的值等于true的时候，表示Chromium的Extension Service已经启动起来了。这时候extensions_service_ready_就会将当前正在加载的Extension的ID插入到UserScriptMaster类的成员变量changed_extensions_描述的一个std::set中去，表示有一个新的Extension需要处理。这里说的处理，就是将新加载的Extension定义的Content Script的内容读取出来，并且保存在一个共享内存中。

将Extension定义的Content Script的内容读取出来，并且保存在一个共享内存中，是通过UserScriptMaster类的成员变量script_reloader_指向的一个ScriptReloader对象实现的。如果这个ScriptReloader已经创建出来，那么就表示它现在正在读取Content Script的过程中。这时候UserScriptMaster类的成员变量pending_load_的值会被设置为true，表示当前需要读取的Content Script发生了变化，因此需要重新进行读取。

如果UserScriptMaster类的成员变量script_reloader_指向的ScriptReloader对象还没有创建出来，那么UserScriptMaster类的成员函数OnExtensionLoaded就会调用另外一个成员函数StartLoad创建该ScriptReloader对象，并且通过该ScriptReloader对象读取当前已经加载的Extension定义的Content Script，如下所示：

void UserScriptMaster::StartLoad() {
  if (!script_reloader_.get())
    script_reloader_ = new ScriptReloader(this);

  script_reloader_->StartLoad(user_scripts_, extensions_info_);
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

从这里可以看到，如果UserScriptMaster类的成员变量script_reloader_指向的ScriptReloader对象还没有创建出来，那么UserScriptMaster类的成员函数StartLoad就会创建，并且在创建之后，调用它的成员函数StartLoad读取当前已经加载的Extension定义的Content Script，如下所示：

void UserScriptMaster::ScriptReloader::StartLoad(
    const UserScriptList& user_scripts,
    const ExtensionsInfo& extensions_info) {
  // Add a reference to ourselves to keep ourselves alive while we're running.
  // Balanced by NotifyMaster().
  AddRef();

  ......
  this->extensions_info_ = extensions_info;
  BrowserThread::PostTask(
      BrowserThread::FILE, FROM_HERE,
      base::Bind(
          &UserScriptMaster::ScriptReloader::RunLoad, this, user_scripts));
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

ScriptReloader类的成员函数StartLoad首先调用成员函数AddRef增加当前正在处理的ScriptReloader对象的引用计数，避免它在读取Content Script的过程中被销毁。

从前面的调用过程可以知道，参数user_scripts描述的是一个std::vector。这个std::vector保存在当前已经加载的Extension定义的Content Script。另外一个参数extension_info指向的是一个std::map。这个std::map描述了当前加载的所有Extension。

ScriptReloader类的成员函数StartLoad将参数extension_info指向的std::map保存在自己的成员变量extension_info_之后，就向Browser进程中专门用来执行文件读写操作的BrowserThread::FILE线程的消息队列发送一个Task。这个Task绑定了ScriptReloader类的成员函数RunLoad。

这意味着ScriptReloader类的成员函数RunLoad接下来会在BrowserThread::FILE线程被调用，用来读取保存在参数user_scripts描述的std::vector中的Content Script，如下所示：

// This method will be called on the file thread.
void UserScriptMaster::ScriptReloader::RunLoad(
    const UserScriptList& user_scripts) {
  LoadUserScripts(const_cast<UserScriptList*>(&user_scripts));

  // Scripts now contains list of up-to-date scripts. Load the content in the
  // shared memory and let the master know it's ready. We need to post the task
  // back even if no scripts ware found to balance the AddRef/Release calls.
  BrowserThread::PostTask(master_thread_id_,
                          FROM_HERE,
                          base::Bind(&ScriptReloader::NotifyMaster,
                                     this,
                                     base::Passed(Serialize(user_scripts))));
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

ScriptReloader类的成员函数RunLoad首先调用成员函数LoadUserScripts读取当前已经加载的Extension定义的Content Script，如下所示：

void UserScriptMaster::ScriptReloader::LoadUserScripts(
    UserScriptList* user_scripts) {
  for (size_t i = 0; i < user_scripts->size(); ++i) {
    UserScript& script = user_scripts->at(i);
    scoped_ptr<SubstitutionMap> localization_messages(
        GetLocalizationMessages(script.extension_id()));
    for (size_t k = 0; k < script.js_scripts().size(); ++k) {
      UserScript::File& script_file = script.js_scripts()[k];
      if (script_file.GetContent().empty())
        LoadScriptContent(
            script.extension_id(), &script_file, NULL, verifier_.get());
    }
    for (size_t k = 0; k < script.css_scripts().size(); ++k) {
      UserScript::File& script_file = script.css_scripts()[k];
      if (script_file.GetContent().empty())
        LoadScriptContent(script.extension_id(),
                          &script_file,
                          localization_messages.get(),
                          verifier_.get());
    }
  }
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

参数user_srcipts描述的std::vector里面保存的是一系列的UserScript对象。每一个UserScript对象里面包含若干个Content Script文件。每一个Content Script文件都是通过一个UserScript::File对象描述。注意，这些Content Script有可能是JavaScript，也有可能是CSS Script。这意味着Extension不仅可以注入JavaScript到宿主网页中，还可以注入CSS Script。

ScriptReloader类的成员函数LoadUserScripts依次调用函数LoadScriptContent读取这些Content Script文件的内容，如下所示：

static bool LoadScriptContent(const std::string& extension_id,
                              UserScript::File* script_file,
                              const SubstitutionMap* localization_messages,
                              ContentVerifier* verifier) {
  std::string content;
  const base::FilePath& path = ExtensionResource::GetFilePath(
      script_file->extension_root(), script_file->relative_path(),
      ExtensionResource::SYMLINKS_MUST_RESOLVE_WITHIN_ROOT);
  if (path.empty()) {
    ......
  } else {
    if (!base::ReadFileToString(path, &content)) {
      LOG(WARNING) << "Failed to load user script file: " << path.value();
      return false;
    }
    ......
  }

  ......

  // Remove BOM from the content.
  std::string::size_type index = content.find(base::kUtf8ByteOrderMark);
  if (index == 0) {
    script_file->set_content(content.substr(strlen(base::kUtf8ByteOrderMark)));
  } else {
    script_file->set_content(content);
  }

  return true;
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

函数LoadScriptContent首先调用ExtensionResource类的静态成员函数GetFilePath获得要读取的Content Script的文件路径，然后再调用函数base::ReadFileToString读取该文件的内容。这样就可以获得要读取的Content Script的内容，这些内容最终又会保存在参数script_file描述的一个UserScript::File对象的内部。

这一步执行完成后，Chromium就获得了当前已经加载的Extension所定义的Content Script的内容。这些内容保存在每一个Content Script对应的UserScript::File对象中。回到前面分析的ScriptReloader类的成员函数RunLoad中，接下来它调用函数Serialize将前面读取的Content Script的内容保存在一块共享内存中，如下所示：

// Pickle user scripts and return pointer to the shared memory.
static scoped_ptr<base::SharedMemory> Serialize(const UserScriptList& scripts) {
  Pickle pickle;
  pickle.WriteUInt64(scripts.size());
  for (size_t i = 0; i < scripts.size(); i++) {
    const UserScript& script = scripts[i];
    // TODO(aa): This can be replaced by sending content script metadata to
    // renderers along with other extension data in ExtensionMsg_Loaded.
    // See crbug.com/70516.
    script.Pickle(&pickle);
    // Write scripts as 'data' so that we can read it out in the slave without
    // allocating a new string.
    for (size_t j = 0; j < script.js_scripts().size(); j++) {
      base::StringPiece contents = script.js_scripts()[j].GetContent();
      pickle.WriteData(contents.data(), contents.length());
    }
    for (size_t j = 0; j < script.css_scripts().size(); j++) {
      base::StringPiece contents = script.css_scripts()[j].GetContent();
      pickle.WriteData(contents.data(), contents.length());
    }
  }

  // Create the shared memory object.
  base::SharedMemory shared_memory;

  base::SharedMemoryCreateOptions options;
  options.size = pickle.size();
  options.share_read_only = true;
  if (!shared_memory.Create(options))
    return scoped_ptr<base::SharedMemory>();

  if (!shared_memory.Map(pickle.size()))
    return scoped_ptr<base::SharedMemory>();

  // Copy the pickle to shared memory.
  memcpy(shared_memory.memory(), pickle.data(), pickle.size());

  base::SharedMemoryHandle readonly_handle;
  if (!shared_memory.ShareReadOnlyToProcess(base::GetCurrentProcessHandle(),
                                            &readonly_handle))
    return scoped_ptr<base::SharedMemory>();

  return make_scoped_ptr(new base::SharedMemory(readonly_handle,
                                                /*read_only=*/true));
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

函数Serialize依次遍历保存在参数scripts描述的一个std::vector中的每一个UserScript对象，并且将这些UserScript对象包含的Content Script写入到本地变量pickle描述一个Pickle对象中。从前面Chromium的IPC消息发送、接收和分发机制分析一文可以知道，Pickle类是Chromium定义的一种IPC消息格式，它将数据按照一定的格式打包在一块内存中。

函数Serialize将Content Script写入到本地变量pickle描述的Pickle对象中去之后，接下来又会创建一块共享内存。这块共享内存通过本地变量shared_memory描述的一个SharedMemory对象描述。有了这块共享内存之后，函数Serialize就会将Content Script的内容从本地变量pickle描述的Pickle对象中拷贝到它里面去。

函数Serialize最后获得已经写入了Content Script的共享内存的只读版本，并且将这个只读版本封装在另外一个SharedMemory对象中返回给调用者，以便调用者以后可以将它传递给宿主网页所在的Render进程进行只读访问。

这一步执行完成后，Chromium就获得了一块只读的共享内存，这块共享内存保存了当前已经加载的Extension所定义的Content Script的内容。回到前面分析的ScriptReloader类的成员函数RunLoad中，接下来它又会向成员变量master_thread_id_描述的线程的消息队列发送一个Task。这个Task绑定了ScriptReloader类的成员函数NotifyMaster，用来通知其内部引用的一个UserScriptMaster对象，当前已经加载的Extension所定义的Content Script的内容已经读取完毕。

ScriptReloader类的成员函数NotifyMaster的实现如下所示：

void UserScriptMaster::ScriptReloader::NotifyMaster(
    scoped_ptr<base::SharedMemory> memory) {
  // The master could go away
  if (master_)
    master_->NewScriptsAvailable(memory.Pass());

  // Drop our self-reference.
  // Balances StartLoad().
  Release();
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

ScriptReloader类内部引用的UserScriptMaster对象保存在成员变量master_中。ScriptReloader类的成员函数NotifyMaster首先调用这个UserScriptMaster对象的成员函数NewScriptsAvailable，通知它已经加载的Extension所定义的Content Script的内容已经读取完毕。

通知完成后，ScriptReloader类的成员函数NotifyMaster还会调用成员函数Release减少当前正在处理的ScriptReloader对象的引用计数，用来平衡在读取Content Script之前，对该ScriptReloader对象的引用计数的增加。

接下来我们继续分析UserScriptMaster类的成员函数NewScriptsAvailable的实现，以便了解它是如何处理当前已经加载的Extension的Content Script的内容的，如下所示：

void UserScriptMaster::NewScriptsAvailable(
    scoped_ptr<base::SharedMemory> handle) {
  if (pending_load_) {
    // While we were loading, there were further changes.  Don't bother
    // notifying about these scripts and instead just immediately reload.
    pending_load_ = false;
    StartLoad();
  } else {
    ......

    // We've got scripts ready to go.
    shared_memory_ = handle.Pass();

    for (content::RenderProcessHost::iterator i(
            content::RenderProcessHost::AllHostsIterator());
         !i.IsAtEnd(); i.Advance()) {
      SendUpdate(i.GetCurrentValue(),
                 shared_memory_.get(),
                 changed_extensions_);
    }
    ......
  }
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

UserScriptMaster类的成员函数NewScriptsAvailable首先判断成员变量pending_load_的值是否等于true。如果等于true，那么就说明前面在读取Content Script的过程中，又有新的Extension被加载。这时候UserScriptMaster类的成员函数会调用前面分析过的成员函数StartLoad对Content Script进行重新读取。

我们假设这时候UserScriptMaster类的成员变量pending_load_的值等于false。在这种情况下，UserScriptMaster类的成员函数NewScriptsAvailable首先将参数handle描述的共享内存保存在成员变量shared_memory_中，接下来又会将这块共享内存传递给当前已经启动的Render进程，这是通过调用成员函数SendUpdate实现的。

我们假设当前还没有Render进程启动起来。前面分析UserScriptMaster类的构造函数的实现时提到，UserScriptMaster类会监控Render进程启动事件，也就是content::NOTIFICATION_RENDERER_PROCESS_CREATED事件。以后每当有一个Render进程启动完成，UserScriptMaster类的成员函数Observe就会被调用。UserScriptMaster类的成员函数Observe在调用的过程中，就会将前面已经加载的Extension的Content Script发送给新启动的Render进程，以便后者可以将Content Script注入到它后续加载的网页中去。

接下来我们就从Render进程启动完成后开始，分析UserScriptMaster类将Content Script传递给Render进程的过程。从前面Chromium的Render进程启动过程分析一文可以知道，Render进程是由Browser进程启动的。Browser进程又是通过ChildProcessLauncher::Context类启动Render进程的。当Render进程启动完成后，ChildProcessLauncher::Context类的静态成员函数OnChildProcessStarted就会被调用，它的实现如下所示：

class ChildProcessLauncher::Context
    : public base::RefCountedThreadSafe<ChildProcessLauncher::Context> {
 public:
  ......

  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));
    }
  }

  ......
};

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

参数client_thread_id描述的是当初请求启动Render进程的线程的ID。另外一个参数this_object描述的是用来启动Render进程的一个ChildProcessLauncher::Context对象。这个ChildProcessLauncher::Context对象就是在请求启动Render进程的线程中创建的。

ChildProcessLauncher::Context类的静态成员函数OnChildProcessStarted首先检查当前线程是否就是当初请求启动Render进程的线程。如果是的话，那么就直接调用参数this_object描述的ChildProcessLauncher::Context对象的成员函数Notify，用来通知它请求的Render进程已经启动完成了。否则的话，会向当初请求启动Render进程的线程的消息队列发送一个Task，然后在这个Task执行的时候，再调用参数this_object描述的ChildProcessLauncher::Context对象的成员函数Notify。通过这种方式，保证参数this_object描述的ChildProcessLauncher::Context对象总是在创建它的线程中使用。这样可以避免在多线程环境下，访问对象（调用对象的成员函数）需要加锁的问题（加锁会引入竞争，竞争会带来不确定的延时）。这是Chromium多线程编程哲学所要遵循的原则之一。关于Chromium多线程编程哲学，可以参考前面Chromium多线程模型设计和实现分析一文。

接下来，我们就继续分析ChildProcessLauncher::Context类的成员函数Notify的实现，如下所示：

class ChildProcessLauncher::Context
    : public base::RefCountedThreadSafe<ChildProcessLauncher::Context> {
  ......

 private:
  ......

  void Notify(
#if defined(OS_POSIX) && !defined(OS_MACOSX) && !defined(OS_ANDROID)
      bool zygote,
#endif
      base::ProcessHandle handle) {
    ......

    if (client_) {
      if (handle) {
        client_->OnProcessLaunched();
      } else {
        client_->OnProcessLaunchFailed();
      }
    } 

    ......
  }

  ......
};

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

ChildProcessLauncher::Context类的成员变量client_指向的是一个RenderProcessHostImpl对象。这个RenderProcessHostImpl对象是在Browser进程中描述它启动的一个Render进程的。通过这个RenderProcessHostImpl对象，可以与Render进程进行IPC。

参数handle描述的就是前面请求启动的Render进程的句柄。当这个句柄值不等于0时，就表示请求的Render进程已经成功地启动起来了。这时候ChildProcessLauncher::Context类的成员函数就会调用成员变量client_指向的RenderProcessHostImpl对象的成员函数OnProcessLaunched，以便它可以发出一个content::NOTIFICATION_RENDERER_PROCESS_CREATED事件通知，如下所示：

void RenderProcessHostImpl::OnProcessLaunched() {
  ......

  NotificationService::current()->Notify(
      NOTIFICATION_RENDERER_PROCESS_CREATED,
      Source<RenderProcessHost>(this),
      NotificationService::NoDetails());

  ......
}

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

从前面的分析可以知道，一旦RenderProcessHostImpl对象的成员函数OnProcessLaunched发出content::NOTIFICATION_RENDERER_PROCESS_CREATED事件通知，UserScriptMaster类的成员函数Observe就会被调用，如下所示：

void UserScriptMaster::Observe(int type,
                               const content::NotificationSource& source,
                               const content::NotificationDetails& details) {
  ......

  switch (type) {
    ......
    case content::NOTIFICATION_RENDERER_PROCESS_CREATED: {
      content::RenderProcessHost* process =
          content::Source<content::RenderProcessHost>(source).ptr();
      ......
      if (ScriptsReady()) {
        SendUpdate(process,
                   GetSharedMemory(),
                   std::set<std::string>());  // Include all extensions.
      }
      break;
    }
    ......
  }

  ......
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

UserScriptMaster类的成员函数Observe在处理content::NOTIFICATION_RENDERER_PROCESS_CREATED事件通知的时候，首先会调用成员函数ScriptsReady检查当前加载的Extension的Content Script是否已经读取出来，并且保存在内部维护的一块共享内存中去了。如果是的话，那么就会继续调用另外一个成员函数SendUpdate将这块共享内存传递给当前启动完成的Render进程。

UserScriptMaster类的成员函数SendUpdate的实现如下所示：

void UserScriptMaster::SendUpdate(
    content::RenderProcessHost* process,
    base::SharedMemory* shared_memory,
    const std::set<std::string>& changed_extensions) {
  ......

  base::SharedMemoryHandle handle_for_process;
  if (!shared_memory->ShareToProcess(handle, &handle_for_process))
    return;  // This can legitimately fail if the renderer asserts at startup.

  if (base::SharedMemory::IsHandleValid(handle_for_process)) {
    process->Send(new ExtensionMsg_UpdateUserScripts(handle_for_process,
                                                     changed_extensions));
  }
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/user_script_master.cc中。

参数shared_memory描述的共享内存就是要发送给参数process描述的Render进程的，它里面包含了当前加载的Extension的Content Script。UserScriptMaster类的成员函数SendUpdate将这块共享封装在一个类型为ExtensionMsg_UpdateUserScripts的IPC消息中，并且发送给参数process描述的Render进程。

Render进程在启动的时候会创建一个Dispatcher对象。这个Dispatcher对象会通过成员函数OnControlMessageReceived接收类型为ExtensionMsg_UpdateUserScripts的IPC消息，如下所示：

bool Dispatcher::OnControlMessageReceived(const IPC::Message& message) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(Dispatcher, message)
  ......
  IPC_MESSAGE_HANDLER(ExtensionMsg_UpdateUserScripts, OnUpdateUserScripts)
  ......
  IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()

  return handled;
}

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

Dispatcher类的成员函数OnControlMessageReceived将类型为ExtensionMsg_UpdateUserScripts的IPC消息分发给另外一个成员函数OnUpdateUserScripts处理，如下所示：

void Dispatcher::OnUpdateUserScripts(
    base::SharedMemoryHandle scripts,
    const std::set<std::string>& extension_ids) {
  ......

  user_script_slave_->UpdateScripts(scripts, extension_ids);
  ......
}

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

Dispatcher类的成员变量user_script_slave_指向的是一个UserScriptSlave对象。Dispatcher类的成员函数OnUpdateUserScripts调用这个UserScriptSlave对象的成员函数UpdateScripts将参数scripts描述的共享内存包含的Content Script交给它处理。处理过程如下所示：

bool UserScriptSlave::UpdateScripts(
    base::SharedMemoryHandle shared_memory,
    const std::set<std::string>& changed_extensions) {
  ......

  // Unpickle scripts.
  uint64 num_scripts = 0;
  Pickle pickle(reinterpret_cast<char*>(shared_memory_->memory()), pickle_size);
  PickleIterator iter(pickle);
  CHECK(pickle.ReadUInt64(&iter, &num_scripts));
  ......

  // If we pass no explicit extension ids, we should refresh all extensions.
  bool include_all_extensions = changed_extensions.empty();
  ......
  
  if (include_all_extensions) {
    script_injections_.clear();
  } 

  ......

  for (uint64 i = 0; i < num_scripts; ++i) {
    scoped_ptr<UserScript> script(new UserScript());
    script->Unpickle(pickle, &iter);
    ......
    
    for (size_t j = 0; j < script->js_scripts().size(); ++j) {
      const char* body = NULL;
      int body_length = 0;
      CHECK(pickle.ReadData(&iter, &body, &body_length));
      script->js_scripts()[j].set_external_content(
          base::StringPiece(body, body_length));
    }
    for (size_t j = 0; j < script->css_scripts().size(); ++j) {
      const char* body = NULL;
      int body_length = 0;
      CHECK(pickle.ReadData(&iter, &body, &body_length));
      script->css_scripts()[j].set_external_content(
          base::StringPiece(body, body_length));
    }

    // If we include all extensions or the given extension changed, we add a
    // new script injection.
    if (include_all_extensions ||
        changed_extensions.count(script->extension_id()) > 0) {
      script_injections_.push_back(new ScriptInjection(script.Pass(), this));
    } 

    ......
  }
  return true;
}

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

UserScriptSlave类的成员函数UpdateScripts会通过本地变量pickle描述的Pickle对象解析和读取包含在参数shared_memory中的Content Script。这些Content Script将会保存在UserScriptSlave类的成员变量script_injections_描述的一个Vector中。

当参数changed_extensions描述的字符串不等于空时，它的值就表示Content Script内容发生过变化的Extension。这时候UserScriptSlave类可以对内部维护的Content Script进行增量更新。从前面的调用过程可以知道，在我们这种情景中，参数changed_extensions描述的字符串等于空。在这种情况下，UserScriptSlave类将会对内部维护的Content Script进行全部更新。也就是先清空成员变量script_injections_描述的Vector，然后再将包含在参数shared_memory中的Content Script增加到这个Vector中去。

从前面分析的函数Serialize可以知道，包含在参数shared_memory中的Content Script是按照Extension进行组织的。一个Extension对应一个UserScript对象。一个UserScript对象又可以包含若干个Content Script。这些Content Script又可能同时包含有JavaScript和CSS Script。UserScriptSlave类的成员函数UpdateScripts通过本地变量pickle描述的Pickle对象依次获得每一个Extension的Content Script，并且封装在一个ScriptInjection对象中。这些ScriptInjection对象会保存在UserScriptSlave类的成员变量script_injections_描述的一个Vector中。

这一步执行完成后，每一个Render进程就会获得当前加载的所有Extension定义的Content Script。这些Content Script由一个UserScriptSlave对象维护。以后每当Render进程加载一个网页，就会询问这个UserScriptSlave对象，是否需要往里面注入相应的Content Script。

接下来，我们以前面提到的Page action example的Content Script注入到URL为“https://fast.com/”的网页为例，分析Content Script注入宿主网页执行的过程。从Page action example的Content Script的定义可以知道，它是在URL为“https://fast.com/”的网页的Document对象创建时注入的。

前面提到，网页的Document对象是在WebKit中创建的。WebKit为网页创建了Document对象之后，会调用Content层的一个RenderFrameImpl对象的成员函数didCreateDocumentElement，用来通知后者，它描述的网页的Document对象已经创建好了，如下所示：

void RenderFrameImpl::didCreateDocumentElement(blink::WebLocalFrame* frame) {
  ......

  FOR_EACH_OBSERVER(RenderViewObserver, render_view_->observers(),
                    DidCreateDocumentElement(frame));
}

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

RenderFrameImpl类的成员变量render_view_指向的是一个RenderViewImpl对象。这个RenderViewImpl对象的内部维护有一系列的Render View Observer。这些Render View Observer用来监听WebKit事件。这样，如果一个模块要监听某一个网页的WebKit事件，那么就往与该网页对应的RenderViewImpl对象内部注册一个Render View Observer即可。

Chromium的Extension模块会监听所有网页的WebKit事件，这是通过向与这些网页对应的RenderViewImpl对象内部注册一个类型为ExtensionHelper的Render View Observer实现的。这意味着当WebKit发出事件通知时，ExtensionHelper类的相应成员函数会被调用。在我们这个情景中，就是当网页的Document对象已经创建出来时，ExtensionHelper类的成员函数DidCreateDocumentElement会被调用。在调用的过程中，它就会往当前加载的网页注入那些运行时机为“document_start”的Content Script，如下所示：

void ExtensionHelper::DidCreateDocumentElement(WebLocalFrame* frame) {
  dispatcher_->user_script_slave()->InjectScripts(
      frame, UserScript::DOCUMENT_START);
  ......
}

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

ExtensionHelper类的成员变量dispatcher_指向的是一个Dispatcher对象。这个Dispatcher对象就是前面分析的用来处理从Browser进程发送过来的类型为ExtensionMsg_UpdateUserScripts的IPC消息的Dispatcher对象。ExtensionHelper类的成员函数DidCreateDocumentElement首先调用这个Dispatcher对象的成员函数user_script_slave获得它内部维护的一个UserScriptSlave对象。有了这个UserScriptSlave对象之后，就可以调用它的成员函数InjectScripts向当前加载的网页注入那些运行时机为“document_start”的Content Script，如下所示：

void UserScriptSlave::InjectScripts(WebFrame* frame,
                                    UserScript::RunLocation location) {
  GURL document_url = ScriptInjection::GetDocumentUrlForFrame(frame);
  ......

  ScriptInjection::ScriptsRunInfo scripts_run_info;
  for (ScopedVector<ScriptInjection>::const_iterator iter =
           script_injections_.begin();
       iter != script_injections_.end();
       ++iter) {
    (*iter)->InjectIfAllowed(frame, location, document_url, &scripts_run_info);
  }

  ......
}

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

参数frame描述的就是当前加载的网页。UserScriptSlave类的成员函数InjectScripts首先通过调用ScriptInjection类的静态成员函数GetDocumentUrlForFrame获得这个网页的URL。有了这个URL之后，UserScriptSlave类的成员函数InjectScripts接下来就会遍历保存在成员变量script_injections_描述的Vector中的每一个ScriptInjection对象，并且调用这些ScriptInjection对象的成员函数InjectIfAllowed。

从前面的分析可以知道，保存在UserScriptSlave类的成员变量script_injections_中的ScriptInjection对象描述的就是当前加载的Extension的Content Script。这些ScriptInjection对象的成员函数InjectIfAllowed在执行期间，就会判断是否需要将自己描述的Content Script注入到当前加载的网页中去执行，也就是前面获得的URL对应的网页。

接下来我们就继续分析ScriptInjection类的成员函数InjectIfAllowed的实现，以便了解Content Script注入到宿主网页执行的过程，如下所示：

void ScriptInjection::InjectIfAllowed(blink::WebFrame* frame,
                                      UserScript::RunLocation run_location,
                                      const GURL& document_url,
                                      ScriptsRunInfo* scripts_run_info) {
  if (!WantsToRun(frame, run_location, document_url))
    return;

  const Extension* extension = user_script_slave_->GetExtension(extension_id_);
  DCHECK(extension);  // WantsToRun() should be false if there's no extension.

  // We use the top render view here (instead of the render view for the
  // frame), because script injection on any frame requires permission for
  // the top frame. Additionally, if we have to show any UI for permissions,
  // it should only be done on the top frame.
  content::RenderView* top_render_view =
      content::RenderView::FromWebView(frame->top()->view());

  int tab_id = ExtensionHelper::Get(top_render_view)->tab_id();

  // By default, we allow injection.
  bool should_inject = true;

  // Check if the extension requires user consent for injection *and* we have a
  // valid tab id (if we don't have a tab id, we have no UI surface to ask for
  // user consent).
  if (tab_id != -1 &&
      extension->permissions_data()->RequiresActionForScriptExecution(
          extension, tab_id, frame->top()->document().url())) {
    int64 request_id = kInvalidRequestId;
    int page_id = top_render_view->GetPageId();

    // We only delay the injection if the feature is enabled.
    // Otherwise, we simply treat this as a notification by passing an invalid
    // id.
    if (FeatureSwitch::scripts_require_action()->IsEnabled()) {
      should_inject = false;
      ScopedVector<PendingInjection>::iterator pending_injection =
          pending_injections_.insert(
              pending_injections_.end(),
              new PendingInjection(frame, run_location, page_id));
      request_id = (*pending_injection)->id;
    }

    top_render_view->Send(
        new ExtensionHostMsg_RequestContentScriptPermission(
            top_render_view->GetRoutingID(),
            extension->id(),
            page_id,
            request_id));
  }

  if (should_inject)
    Inject(frame, run_location, scripts_run_info);
}

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

ScriptInjection类的成员函数InjectIfAllowed首先调用成员函数WantsToRun判断当前加载的网页是否是当前正在处理的Content Script感兴趣的网页，也就是判断当前加载的网页的URL是否匹配Content Script在其Extension的清单文件设置的URL规则。如果不匹配，那么就说明不需要将当前正在处理的Content Script注入到当前加载的网页中执行。

如果匹配，ScriptInjection类的成员函数InjectIfAllowed还会进一步检查当前正在处理的Content Script所在的Extension是否对当前正在加载的网页申请了Permission。如果没有申请，并且Chromium启用了Scripts Require Action Feature，那么就需要用户同意后，才能将当前正在处理的Content Script注入到当前加载的网页中执行。这个需要用户同意的操作是通过向Browser进程发出一个类型ExtensionHostMsg_RequestContentScriptPermission的IPC消息触发的。

我们假设当前加载的网页是当前正在处理的Content Script感兴趣的网页，并且Chromium没有开启Scripts Require Action Feature。这时候ScriptInjection类的成员函数InjectIfAllowed就会马上调用成员函数Inject将当前正在处理的Content Script注入到当前加载的网页中执行，如下所示：

void ScriptInjection::Inject(blink::WebFrame* frame,
                             UserScript::RunLocation run_location,
                             ScriptsRunInfo* scripts_run_info) const {
  ......

  if (ShouldInjectCSS(run_location))
    InjectCSS(frame, scripts_run_info);
  if (ShouldInjectJS(run_location))
    InjectJS(frame, scripts_run_info);
}

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

ScriptInjection类的成员函数Inject首先调用成员函数ShouldInjectsCSS判断当前正在处理的Content Script是否包含有CSS Script，并且参数run_location描述的Content Script运行时机是否为“document_start”。如果都是的话，那么当前正在处理的Content Script包含的CSS Script就会通过调用另外一个成员函数InjectCSS注入到当前加载的网页中去。这意味着CSS Script只可以在宿主网页的Document对象创建时注入。

ScriptInjection类的成员函数Inject接下来又调用成员函数ShouldInjectJS判断当前正在处理的Content Script是否包含有JavaScript，并且参数run_location描述的Content Script运行时机是否为包含的JavaScript在清单文件中指定的运行时机。如果都是的话，那么当前正在处理的Content Script包含的JavaScript就会通过调用另外一个成员函数InjectJS注入到当前加载的网页中去执行。

接下来我们只关注JavaScript注入到宿主网页执行的过程，因此我们继续分析ScriptInjection类的成员函数InjectJS的实现，如下所示：

void ScriptInjection::InjectJS(blink::WebFrame* frame,
                               ScriptsRunInfo* scripts_run_info) const {
  const UserScript::FileList& js_scripts = script_->js_scripts();
  std::vector<blink::WebScriptSource> sources;
  scripts_run_info->num_js += js_scripts.size();
  for (UserScript::FileList::const_iterator iter = js_scripts.begin();
       iter != js_scripts.end();
       ++iter) {
    std::string content = iter->GetContent().as_string();

    .......
    sources.push_back(blink::WebScriptSource(
        blink::WebString::fromUTF8(content), iter->url()));
  }

  ......

  int isolated_world_id =
      user_script_slave_->GetIsolatedWorldIdForExtension(
          user_script_slave_->GetExtension(extension_id_), frame);
  ......

  DOMActivityLogger::AttachToWorld(isolated_world_id, extension_id_);
  frame->executeScriptInIsolatedWorld(isolated_world_id,
                                      &sources.front(),
                                      sources.size(),
                                      EXTENSION_GROUP_CONTENT_SCRIPTS);
  
 
  ......
}

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

ScriptInjection类的成员函数InjectJS首先遍历将要执行的每一个JavaScript文件。在遍历的过程中，每一个JavaScript文件的内容都会被读取出来，并且封装在一个blink::WebScriptSource对象中。这些blink::WebScriptSource对象最后又会保存在本地变量sources描述的一个blink::WebScriptSource向量中。这个blink::WebScriptSource向量接下来会传递给WebKit中的JS引擎。JS引擎获得了这个向量之后，就会执行保存在里面的JavaScript。

Extension的Content Script是在一个Isolated World中执行的，这意味着它们不能访问在宿主网页中定义的JS变量和函数，也不能访问在宿主网页中注入的其它Extension的Content Script定义的JS变量和函数。为此，Chromium会为每一个Extension分配一个不同的Isolated World ID，使得它们的Content Script注入到宿主网页时，既不能互相访问各自定义的JS变量和函数，也不能访问宿主网页定义的JS变量和函数。

按照上述规则，ScriptInjection类的成员函数InjectJS在注入指定的JavaScript到宿主网页中执行之前，首先会调用成员变量user_script_slave_指向的一个UserScriptSlave对象的成员函数GetIsolatedWorldIdForExtension获得一个Isolated World ID。有了这个Isolated World ID之后，就可以调用参数frame指向的一个WebLocalFrameImpl对象的成员函数executeScriptInIsolatedWorld了。

WebLocalFrameImpl类是WebKit向Chromium提供的一个API接口。这个API接口的成员函数executeScriptInIsolatedWorld会将指定的JavaScript交给WebKit内部使用的JS引擎在指定的Isolated World中执行。在Chromium中，这个JS引擎就是V8引擎。V8引擎执行JavaScript的过程，以后我们有机会再分析。

至此，我们就分析完成Extension的Content Script注入到宿主网页中执行的过程了。这些Content Script虽然是在宿主网页中执行，但是它们是不能访问宿主网页定义的JS变量和函数的，也不能访问注入在宿主网页中的其它Extension的Content Script定义的JS变量和函数。不过，它们却可以操作宿主网页的DOM Tree，这样就可以修改宿主网页的UI和行为了。

如果我们将Extension看作是一个App，那么它的Page和Content Script就可以看作是它的Module。既然是Module，它们之间就避免不了互相通信，以完成一个App的功能。Chromium为Extension的Page与Page之间，以及Page和Content Script之间，均提供了通信接口。不过，Page与Page之间的通信方式，与Page和Content Script之间的通信方式，是不一样的。这是因为Page运行在所属Extension加载在的Extension Process中，而Content Script运行在宿主网页所加载在的Render Process中。在接下来一篇文章中，我们就继续分析Extension的Page与Page之间，以及Page与Content Script之间的通信机制，敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/9/26 1:00:57 原文链接

阅读：37653 评论：10 查看评论

↧

Chromium扩展（Extension）通信机制分析

October 10, 2016, 1:00 am

≫ Next: Chromium插件（Plugin）机制简要介绍和学习计划

≪ Previous: Chromium扩展（Extension）的Content Script加载过程分析

Chromium的Extension由Page和Content Script组成。如果将Extension看作是一个App，那么Page和Content Script就是Extension的Module。既然是Module，就避免不了需要相互通信。也正是由于相互通信，使得它们形成一个完整的App。本文接下来就分析Extension的Page之间以及Page与Content Script之间的通信机制。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

从前面Chromium扩展（Extension）的页面（Page）加载过程分析和Chromium扩展（Extension）的Content Script加载过程分析这两篇文章可以知道，Extension的Page，实际上就是Web Page，它们加载在同一个Extension Process中，而Extension的Content Script，实际上是JavaScript，它们加载在宿主网页所在的Render Process中。这意味着Extension的Page之间，可以进行进程内通信，但是Page与Content Script之间，需要进行进程间通信。

Chromium的Extension模块提供了接口，让Extension的Page与Page之间，以及Page与Content Script之间，可以方便地通信，如图1所示：

图1 Extension的通信机制

Extension的Page之间的通信，表现为可以访问各自定义的JS变量和函数。例如，我们在前面Chromium扩展（Extension）机制简要介绍和学习计划一文中提到的Page action example，定义了一个Background Page和一个Popup Page。其中，Background Page包含了的一个background.js，它的内容如下所示：

chrome.tabs.onUpdated.addListener(function (tabId, changeInfo, tab) {   
  ...... 
  
  var views = chrome.extension.getViews({type: "tab"});  
  if (views.length > 0) {  
    console.log(views[0].whoiam);  
  } else {  
    console.log("No tab");  
  }  
});    
  
......  
  
var whoiam = "background.html"

它定义了一个变量whoiam，同时它又会通过Extension模块提供的API接口chrome.extension.getViews，获得在浏览器窗口的Tab中加载的所有Extension Page的window对象。假设此时Page action example在Tab中加载了一个Extension Page，并且这个Page也像Background Page一样定义了变量whoiam，那么Background Page就可以通过它的window对象直接访问它的变量whoiam。

API接口chrome.extension.getViews除了可以获得在Tab中加载的Page的window对象，还可以获得以其它方式加载的Page的window对象。例如，在弹窗口中加载的Popup Page的window对象，以及在浏览器的Info Bar（信息栏）和Notification（通知面板）中加载的Page的window对象。可以通过type参数指定要获取哪一种类型的Page的window对象。如果没有指定，那么就会获得所有类型的Page的window对象。

注意，API接口chrome.extension.getViews获得的是非Background Page的window对象。如果需要获得Background Page的window对象，可以使用另外一个API接口chrome.extension.getBackgroundPage。例如，我们在前面Chromium扩展（Extension）机制简要介绍和学习计划一文中提到的Page action example的Popup Page，包含有一个popup.js，它的内容如下所示：

document.addEventListener('DOMContentLoaded', function() {  
  getImageUrl(function(imageUrl, width, height) {  
    var imageResult = document.getElementById('image-result');  
    imageResult.width = width;  
    imageResult.height = height;  
    imageResult.src = imageUrl;  
    imageResult.hidden = false;  
  
    console.log(chrome.extension.getBackgroundPage().whoiam);  
  }, function(errorMessage) {  
    renderStatus('Cannot display image. ' + errorMessage);  
  });  
  
  ......   
});  
  
var whoiam = "popup.html"

它在Popup Page中显示图片时，就可以通过调用API接口chrome.extension.getBackgroundPage获得Background Page的window对象，然后通过这个window对象访问在Background Page中定义的变量whoiam。从前面的定义可以知道，这个变量的值等于“background.html”。

总结来说，就是Extension的Page之间，可以通过chrome.extension.getViews和chrome.extension.getBackgroundPage这两个API接口获得对方的window对象。有了对方的window对象之后，就可以直接进行通信了。

由于Extension的Page和Content Script不在同一个进程，它们的通信过程就会复杂一些。总体来说，是通过消息进行通信的。接下来我们以Popup Page与Content Script的通信为例，说明Extension的Page和Content Script的通信过程。

在前面Chromium扩展（Extension）机制简要介绍和学习计划一文中提到的Page action example，它的Popup Page可以通过API接口chrome.tabs.sendRequest向Content Script发送请求，如下所示：

function testRequest() {    
  chrome.tabs.getSelected(null, function(tab) {     
    chrome.tabs.sendRequest(tab.id, {counter: counter}, function handler(response) {    
      counter = response.counter;  
      document.querySelector('#resultsRequest').innerHTML = "<font color='gray'> response: " + counter + "</font>";  
      document.querySelector('#testRequest').innerText = "send " + (counter -1) + " to tab page";  
    });    
  });    
}

这个请求会被封装在一个类型为ExtensionHostMsg_PostMessage的IPC消息，并且发送给Browser进程。Browser进程会找到Page action example的Content Script的宿主网页所在的Render进程，并且将请求封装成另外一个类型为ExtensionMsg_DeliverMessage的IPC消息发送给它。

Render进程收到类型为ExtensionMsg_DeliverMessage的IPC消息后，就会将封装在里面的请求提取出来，并且交给Content Script处理，如下所示：

chrome.extension.onRequest.addListener(    
  function(request, sender, sendResponse) {    
    sendResponse({counter: request.counter + 1 });    
  }  
);

Content Script需要通过API接口chrome.extension.onRequest.addListener注册一个函数，用来接收来自Extension Page的请求。这个函数的第三个参数是一个Callback函数。通过这个Callback函数，Content Script可以向Background Page发送Response。

Extension的Content Script同样也可以向Extension的Page发送请求。不过，它是通过另外一个API接口chrome.runtime.sendMessage进行发送的。例如，上述Page action example的Content Script就是通过这个接口向Background Page发送请求的，如下所示：

function testRequest() {    
  chrome.runtime.sendMessage({counter: counter}, function(response) {  
    counter = response.counter;  
    document.querySelector('#resultsRequest').innerText = "response: " + counter;  
    document.querySelector('#testRequest').innerText = "send " + (counter -1) + " to background page";  
  });  
}

这个请求同样是先通过一个类型为ExtensionHostMsg_PostMessage的IPC消息传递到Browser进程，然后再由Browser进程通过另外一个类型为ExtensionMsg_DeliverMessage的IPC消息传递给Extension进程中的Background Page。

Background Page需要通过API接口chrome.runtime.onMessage.addListener注册一个函数，用来接收来自Content Script的请求，如下所示：

chrome.runtime.onMessage.addListener(  
  function(request, sender, sendResponse) {  
    sendResponse({counter: request.counter + 1 });   
  }  
);

这个函数的第三个参数同样是一个Callback函数。通过这个Callback函数，Background Page可以向Content Script发送Response。

总结来说，就是Extension的Page可以通过API接口chrome.tabs.sendRequest和chrome.extension.onRequest.addListener与Content Script通信，而Content Script可以通过API接口chrome.runtime.sendMessage和chrome.runtime.onMessage.addListener与Page通信。

接下来，我们结合源代码分析chrome.extension.getViews、chrome.extension.getBackgroundPage和chrome.runtime.sendMessage这三个API接口的实现。了解这三个API接口的实现之后，我们就会对上述的Extension通信机制，有更深刻的认识。

在分析上述三个API接口之前，我们首先简单介绍一下JS Binding。JS Binding类型于Java里面的JNI，用来在JS与C/C++之间建立桥梁，也就是用来将一个JS接口绑定到一个C/C++函数中去。

Chromium使用的JS引擎是V8。V8引擎在创建完成Script Context之后，会向WebKit发出通知。WebKit再向Chromium的Content模块发出通知。Content模块又会向Extension模块发出通知。Extension模块获得通知后，就会将chrome.extension.getViews、chrome.extension.getBackgroundPage和chrome.runtime.sendMessage接口绑定到Chromium内部定义的函数中去，从而使得它们可以通过Chromium的基础设施来实现Extension的通信机制。

V8引擎的初始化发生在V8WindowShell类的成员函数initialize中，它的实现如下所示：

bool V8WindowShell::initialize()
{
    TRACE_EVENT0("v8", "V8WindowShell::initialize");
    ......

    createContext();
    ......

    ScriptState::Scope scope(m_scriptState.get());
    v8::Handle<v8::Context> context = m_scriptState->context();
    ......

    m_frame->loader().client()->didCreateScriptContext(context, m_world->extensionGroup(), m_world->worldId());
    return true;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/bindings/v8/V8WindowShell.cpp中。

V8WindowShell类的成员函数initialize在初始化完成V8引擎之后，会通过调用成员变量m_frame指向的一个LocalFrame对象的成员函数loader获得一个FrameLoader对象。有了这个FrameLoader对象之后，再调用它的成员函数client就可以获得一个FrameLoaderClientImpl对象。有了这个FrameLoaderClientImpl对象，就可以调用它的成员函数didCreateScriptContext向WebKit发出通知，V8引擎的Script Context创建好了。

FrameLoaderClientImpl类的成员函数didCreateScriptContext的实现如下所示：

void FrameLoaderClientImpl::didCreateScriptContext(v8::Handle<v8::Context> context, int extensionGroup, int worldId)
{
    WebViewImpl* webview = m_webFrame->viewImpl();
    ......
    if (m_webFrame->client())
        m_webFrame->client()->didCreateScriptContext(m_webFrame, context, extensionGroup, worldId);
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/web/FrameLoaderClientImpl.cpp中。

FrameLoaderClientImpl类的成员变量m_webFrame指向的是一个WebLocalFrameImpl对象。FrameLoaderClientImpl类的成员函数didCreateScriptContext首先调用这个WebLocalFrameImpl对象的成员函数viewImpl获得一个WebViewImpl对象。有了这个WebViewImpl对象之后，再调用它的成员函数client可以获得一个RenderFrameImpl对象。这个RenderFrameImpl对象实现了WebViewClient接口，它是从Chromium的Content层设置进来的，作为WebKit回调Content的接口。因此，有了这个RenderFrameImpl对象之后，FrameLoaderClientImpl类的成员函数didCreateScriptContext就可以调用它的成员函数didCreateScriptContext，用来通知它V8引擎的Script Context创建好了。

RenderFrameImpl类的成员函数didCreateScriptContext的实现如下所示：

void RenderFrameImpl::didCreateScriptContext(blink::WebLocalFrame* frame,
                                             v8::Handle<v8::Context> context,
                                             int extension_group,
                                             int world_id) {
  DCHECK(!frame_ || frame_ == frame);
  GetContentClient()->renderer()->DidCreateScriptContext(
      frame, context, extension_group, world_id);
}

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

我们假设当前基于Chromium实现的浏览器为Chrome。这时候RenderFrameImpl类的成员函数didCreateScriptContext调用函数GetContentClient获得的是一个ChromeContentClient对象。有了这个ChromeContentClient对象之后，调用它的成员函数renderer可以获得一个ChromeContentRendererClient对象。有了这个ChromeContentRendererClient对象之后，RenderFrameImpl类的成员函数didCreateScriptContext就可以调用它的成员函数DidCreateScriptContext，用来通知它V8引擎的Script Context创建好了。

ChromeContentRendererClient类的成员函数DidCreateScriptContext的实现如下所示：

void ChromeContentRendererClient::DidCreateScriptContext(
    WebFrame* frame, v8::Handle<v8::Context> context, int extension_group,
    int world_id) {
  extension_dispatcher_->DidCreateScriptContext(
      frame, context, extension_group, world_id);
}

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

ChromeContentRendererClient类的成员变量extension_dispatcher_指向的是一个Dispatcher对象。这个Dispatcher对象就是我们在前面Chromium扩展（Extension）的Content Script加载过程分析一文中提到的那个用来接收Extension相关的IPC消息的Dispatcher对象，ChromeContentRendererClient类的成员函数DidCreateScriptContext调用所做的事情就是调用它的成员函数DidCreateScriptContext，用来通知它V8引擎的Script Context创建好了。

Dispatcher类的成员函数DidCreateScriptContext的实现如下所示：

void Dispatcher::DidCreateScriptContext(
    WebFrame* frame,
    const v8::Handle<v8::Context>& v8_context,
    int extension_group,
    int world_id) {
  ......

  std::string extension_id = GetExtensionID(frame, world_id);

  const Extension* extension = extensions_.GetByID(extension_id);
  ......

  Feature::Context context_type =
      ClassifyJavaScriptContext(extension,
                                extension_group,
                                ScriptContext::GetDataSourceURLForFrame(frame),
                                frame->document().securityOrigin());

  ScriptContext* context =
      delegate_->CreateScriptContext(v8_context, frame, extension, context_type)
          .release();
  ......

  {
    scoped_ptr<ModuleSystem> module_system(
        new ModuleSystem(context, &source_map_));
    context->set_module_system(module_system.Pass());
  }
  ModuleSystem* module_system = context->module_system();

  ......

  RegisterNativeHandlers(module_system, context);

  ......
}

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

参数frame描述的是当前加载的网页，另外一个参数world_id描述的是V8引擎中的一个Isolated World ID。从前面Chromium扩展（Extension）的Content Script加载过程分析一文可以知道，Isolated World是用来执行Extension的Content Script的，并且每一个Extension在其宿主网页中都有一个唯一的Isolated World。这意味着根据这个Isolated World ID可以获得它所对应的Extension。这可以通过调用Dispatcher类的成员函数GetExtensionID获得。

知道了参数world_id描述的Isolated World对应的Extension之后，Dispatcher类的成员函数DidCreateScriptContext就可以为这个Extension创建一个Script Context。这个Script Context实际上只是对参数v8_context描述的V8 Script Context进行封装。

创建上述Script Context的目的是创建一个Module System。通过这个Module System，可以向参数world_id描述的Isolated World注册Native Handler。Native Handler的作用就是创建JS Binding。有了这些JS Binding之后，我们就可以在Content Script中调用Extension相关的API接口了。

Dispatcher类的成员函数DidCreateScriptContext最后是通过调用另外一个成员函数RegisterNativeHandlers向参数world_id描述的Isolated World注册Native Handler的，它的实现如下所示：

void Dispatcher::RegisterNativeHandlers(ModuleSystem* module_system,
                                        ScriptContext* context) {
  ......

  module_system->RegisterNativeHandler(
      "messaging_natives",
      scoped_ptr<NativeHandler>(MessagingBindings::Get(this, context)));

  ......

  module_system->RegisterNativeHandler(
      "runtime", scoped_ptr<NativeHandler>(new RuntimeCustomBindings(context)));

  ......
}

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

Dispatcher类的成员函数RegisterNativeHandlers注册了一系列的Native Handler。每一个Native Handler都对应有一个名称。这个名称在JS中称为Module，可以通过JS函数require进行引用。这一点后面我们就会看到它的用法。

这里我们只关注与前面提到的API接口chrome.extension.getViews、chrome.extension.getBackgroundPage和chrome.runtime.sendMessage相关的两个Module：“message_natives”和“runtime”。

其中，名称为“message_natives”的Module使用的Native Handler是一个ExtensionImpl对象。这个ExtensionImpl对象是通过调用MessagingBindings类的静态成员函数Get创建的，如下所示：

ObjectBackedNativeHandler* MessagingBindings::Get(Dispatcher* dispatcher,
                                                  ScriptContext* context) {
  return new ExtensionImpl(dispatcher, context);
}

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

这个ExtensionImpl对象在创建的时候，就会为名称为“message_natives”的Module导出的JS函数创建Binding，如下所示：

class ExtensionImpl : public ObjectBackedNativeHandler {
 public:
  ExtensionImpl(Dispatcher* dispatcher, ScriptContext* context)
      : ObjectBackedNativeHandler(context), dispatcher_(dispatcher) {
    ......
    RouteFunction(
        "PostMessage",
        base::Bind(&ExtensionImpl::PostMessage, base::Unretained(this)));
    ......
  }

  ......
};

这个类定义在文件external/chromium_org/extensions/renderer/messaging_bindings.cc中。

从这里可以看到，名称为“message_natives”的Module导出了一个名称为“PostMessage”的JS函数。这个JS函数绑定了ExtensionImpl类的成员函数PostMessage。这意味着以后我们在JS中调用了messaging_natives.PostMessage函数时，ExtensionImpl类的成员函数PostMessage就会被调用。

回到Dispatcher类的成员函数RegisterNativeHandlers中，它注册的另外一个名称为“runtime”的Module使用的Native Handler是一个RuntimeCustomBindings对象。这个RuntimeCustomBindings对象在创建的过程中，就会为名称为“runtime”的Module导出的JS函数创建Binding，如下所示：

RuntimeCustomBindings::RuntimeCustomBindings(ScriptContext* context)
    : ObjectBackedNativeHandler(context) {
  ......
  RouteFunction("GetExtensionViews",
                base::Bind(&RuntimeCustomBindings::GetExtensionViews,
                           base::Unretained(this)));
}

这个类定义在文件external/chromium_org/extensions/renderer/runtime_custom_bindings.cc中。

这里可以看到，名称为“runtime”的Module导出了一个名称为“GetExtensionViews”的JS函数。这个JS函数绑定了RuntimeCustomBindings类的成员函数GetExtensionViews。这意味着以后我们在JS中调用了runtime.GetExtensionViews函数时，RuntimeCustomBindings类的成员函数GetExtensionViews就会被调用。

有了以上JS Binding相关的背景知识之后，接下来我们就开始分析Chromium的Extension提供的API接口chrome.extension.getViews、chrome.extension.getBackgroundPage和chrome.runtime.sendMessage的实现了。

我们首先分析chrome.extension.getViews和chrome.extension.getBackgroundPage这两个API接口的实现，如下所示：

var binding = require('binding').Binding.create('extension');
.....
var runtimeNatives = requireNative('runtime');
var GetExtensionViews = runtimeNatives.GetExtensionViews;

binding.registerCustomHook(function(bindingsAPI, extensionId) {
  ......

  var apiFunctions = bindingsAPI.apiFunctions;

  apiFunctions.setHandleRequest('getViews', function(properties) {
    var windowId = WINDOW_ID_NONE;
    var type = 'ALL';
    if (properties) {
      if (properties.type != null) {
        type = properties.type;
      }
      if (properties.windowId != null) {
        windowId = properties.windowId;
      }
    }
    return GetExtensionViews(windowId, type);
  });

  ......

  apiFunctions.setHandleRequest('getBackgroundPage', function() {
    return GetExtensionViews(-1, 'BACKGROUND')[0] || null;
  });

  ......
});

这两个JS接口定义在文件external/chromium_org/extensions/renderer/resources/extension_custom_bindings.js中。

从这里可以看到，chrome.extension.getViews和chrome.extension.getBackgroundPage这两个API接口都是通过调用名称为"runtime"的Module导出的函数GetExtensionViews（即runtime.GetExtensionViews）实现的。不过，后者在调用函数runtime.GetExtensionViews时，两个参数被固定为-1和"BACKGROUND"，表示要获取的是Background Page的window对象。

从前面的分析可以知道，函数runtime.GetExtensionViews绑定到了RuntimeCustomBindings类的成员函数GetExtensionViews。这意味着，当我们在JS中调用chrome.extension.getViews和chrome.extension.getBackgroundPage这两个API接口时，最后会调用到C++层的RuntimeCustomBindings类的成员函数GetExtensionViews。它的实现如下所示：

void RuntimeCustomBindings::GetExtensionViews(
    const v8::FunctionCallbackInfo<v8::Value>& args) {
  if (args.Length() != 2)
    return;

  if (!args[0]->IsInt32() || !args[1]->IsString())
    return;

  // |browser_window_id| == extension_misc::kUnknownWindowId means getting
  // all views for the current extension.
  int browser_window_id = args[0]->Int32Value();

  std::string view_type_string = *v8::String::Utf8Value(args[1]->ToString());
  StringToUpperASCII(&view_type_string);
  // |view_type| == VIEW_TYPE_INVALID means getting any type of
  // views.
  ViewType view_type = VIEW_TYPE_INVALID;
  if (view_type_string == kViewTypeBackgroundPage) {
    view_type = VIEW_TYPE_EXTENSION_BACKGROUND_PAGE;
  } else if (view_type_string == kViewTypeInfobar) {
    view_type = VIEW_TYPE_EXTENSION_INFOBAR;
  } else if (view_type_string == kViewTypeTabContents) {
    view_type = VIEW_TYPE_TAB_CONTENTS;
  } else if (view_type_string == kViewTypePopup) {
    view_type = VIEW_TYPE_EXTENSION_POPUP;
  } else if (view_type_string == kViewTypeExtensionDialog) {
    view_type = VIEW_TYPE_EXTENSION_DIALOG;
  } else if (view_type_string == kViewTypeAppWindow) {
    view_type = VIEW_TYPE_APP_WINDOW;
  } else if (view_type_string == kViewTypePanel) {
    view_type = VIEW_TYPE_PANEL;
  } else if (view_type_string != kViewTypeAll) {
    return;
  }

  std::string extension_id = context()->GetExtensionID();
  if (extension_id.empty())
    return;

  std::vector<content::RenderView*> views = ExtensionHelper::GetExtensionViews(
      extension_id, browser_window_id, view_type);
  v8::Local<v8::Array> v8_views = v8::Array::New(args.GetIsolate());
  int v8_index = 0;
  for (size_t i = 0; i < views.size(); ++i) {
    v8::Local<v8::Context> context =
        views[i]->GetWebView()->mainFrame()->mainWorldScriptContext();
    if (!context.IsEmpty()) {
      v8::Local<v8::Value> window = context->Global();
      DCHECK(!window.IsEmpty());
      v8_views->Set(v8::Integer::New(args.GetIsolate(), v8_index++), window);
    }
  }

  args.GetReturnValue().Set(v8_views);
}

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

RuntimeCustomBindings类的成员函数GetExtensionViews首先将从JS传递过来的参数（Page Window ID和Page Type）提取出来，并且获得当前正在调用的Extension的ID，然后就调用ExtensionHelper类的静态成员函数GetExtensionViews获得指定的Page所加载在的Render View。

在Render进程中，每一个网页都是加载在一个Render View中的。有了Render View之后，就可以获得它在WebKit层为网页创建的V8 Script Context。有了V8 Script Context之后，就可以获得网页的window对象了。这些window对象最后会返回到JS层中去给调用者。

接下来，我们继续分析ExtensionHelper类的静态成员函数GetExtensionViews的实现，以便了解Extension Page对应的Render View的获取过程，如下所示：

std::vector<content::RenderView*> ExtensionHelper::GetExtensionViews(
    const std::string& extension_id,
    int browser_window_id,
    ViewType view_type) {
  ViewAccumulator accumulator(extension_id, browser_window_id, view_type);
  content::RenderView::ForEach(&accumulator);
  return accumulator.views();
}

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

ExtensionHelper类的静态成员函数GetExtensionViews通过调用RenderView类的静态成员函数ForEach遍历在当前Render进程创建的所有Render View，并且通过一个ViewAccumulator对象挑选出那些符合条件的Render View返回给调用者。

RenderView类的静态成员函数ForEach的实现如下所示：

void RenderView::ForEach(RenderViewVisitor* visitor) {
  ViewMap* views = g_view_map.Pointer();
  for (ViewMap::iterator it = views->begin(); it != views->end(); ++it) {
    if (!visitor->Visit(it->second))
      return;
  }
}

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

RenderView类的静态成员函数ForEach通过遍历全局变量g_view_map描述的一个Map可以获得当前Render进程创建的所有Render View。这些Render View将会进一步交给参数visitor描述的一个ViewAccumulator对象进行处理。

从前面Chromium网页Frame Tree创建过程分析一文可以知道，Render进程为网页创建的Render View实际上是一个RenderViewImpl对象。每一个RenderViewImpl对象在创建完成后，它们的成员函数Initialize都会被调用，用来执行初始化工作。在初始化的过程，RenderViewImpl对象就会将自己保存在上述全局变量g_view_map描述的一个Map中，如下所示：

void RenderViewImpl::Initialize(RenderViewImplParams* params) {
  ......

  g_view_map.Get().insert(std::make_pair(webview(), this));

  ......
}

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

因此，前面分析的RenderView类的静态成员函数ForEach，可以通过遍历全局变量g_view_map描述的Map获得当前Render进程创建的所有Render View。

这样，我们就分析完成了chrome.extension.getViews和chrome.extension.getBackgroundPage这两个API接口的实现。接下来，我们继续分析chrome.runtime.sendMessage这个API接口的实现，如下所示：

var messaging = require('messaging');
......

binding.registerCustomHook(function(binding, id, contextType) {
  ......

  apiFunctions.setHandleRequest('sendMessage',
      function(targetId, message, options, responseCallback) {
    var connectOptions = {name: messaging.kMessageChannel};
    forEach(options, function(k, v) {
      connectOptions[k] = v;
    });
    var port = runtime.connect(targetId || runtime.id, connectOptions);
    messaging.sendMessageImpl(port, message, responseCallback);
  });

  ......
});

这个JS接口定义在文件external/chromium_org/extensions/renderer/resources/runtime_custom_bindings.js中。

从这里可以看到，chrome.runtime.sendMessage这个API接口是通过调用名称为"messaging"的Module导出的函数sendMessageImpl（即messaging.sendMessageImpl）实现的。

在调用函数messaging.sendMessageImpl的时候，需要指定的一个Port。在Extension中，所有的消息都是通过通道进行传输的。这个通道就称为Port。我们可以通过调用另外一个API接口runtime.connect获得一个连接到目标通信对象的Port。有了这个Port之后，就可以向目标通信对象发送消息了。目标通信对象可以通过参数targetId描述。如果没有指定targetId，则使用默认的Port进行发送消息。这个默认的Port由runtime.id描述。

函数messaging.sendMessageImpl的实现如下所示：

function sendMessageImpl(port, request, responseCallback) {
    if (port.name != kNativeMessageChannel)
      port.postMessage(request);

    ......

    function messageListener(response) {
      try {
        responseCallback(response);
      } finally {
        port.disconnect();
      }
    }

    ......

    port.onMessage.addListener(messageListener);
};

这个函数定义在文件external/chromium_org/extensions/renderer/resources/messaging.js中。

从前面的调用过程可以知道，参数port描述的Port的名称被设置为kMessageChannel，它的值不等于kNativeMessageChannel。在这种情况下，函数messaging.sendMessageImpl将会调用参数port描述的Port的成员函数postMessage发送参数request描述的消息给目标通信对象，并且它会将参数responseCallback描述的一个Callback封装在一个Listener中。当目标通信对象处理完成参数request描述的消息进行Reponse时，上述Listener就会调用它内部封装的Callback，这样消息的发送方就可以得到接收方的回复了。

参数port描述的Port的成员函数postMessage的实现如下所示：

var messagingNatives = requireNative('messaging_natives');
......

PortImpl.prototype.postMessage = function(msg) {
    .....
    messagingNatives.PostMessage(this.portId_, msg);
};

这个函数定义在文件external/chromium_org/extensions/renderer/resources/messaging.js中。

从这里可以看到，Port类的成员函数postMessage是通过调用名称为“messaging_natives”的Module导出的函数PostMessage（即messaging_natives.PostMessage）实现的。

从前面的分析可以知道，函数messaging_natives.PostMessage绑定到了ExtensionImpl类的成员函数PostMessage。这意味中，当我们在JS中调用chrome.runtime.sendMessage这个API接口时，最后会调用到C++层的ExtensionImpl类的成员函数PostMessage。它的实现如下所示：

class ExtensionImpl : public ObjectBackedNativeHandler {
 ......

 private:
  ......

  // Sends a message along the given channel.
  void PostMessage(const v8::FunctionCallbackInfo<v8::Value>& args) {
    content::RenderView* renderview = context()->GetRenderView();
    ......

    int port_id = args[0]->Int32Value();
    ......

    renderview->Send(new ExtensionHostMsg_PostMessage(
        renderview->GetRoutingID(), port_id,
        Message(*v8::String::Utf8Value(args[1]),
                blink::WebUserGestureIndicator::isProcessingUserGesture())));
  }

  ......
};

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

ExtensionImpl类的成员函数PostMessage首先获得一个Render View。这个Render View描述的是消息发送方所属的网页。获得这个Render View的目的，是为了调用它的成员函数Send向Browser进程发送一个类型为ExtensionHostMsg_PostMessage的IPC消息。这个IPC消息封装了JS层所要发送的消息。

Browser进程通过ChromeExtensionWebContentsObserver类的成员函数OnMessageReceived接收类型为ExtensionHostMsg_PostMessage的IPC消息，如下所示：

bool ChromeExtensionWebContentsObserver::OnMessageReceived(
    const IPC::Message& message) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(ChromeExtensionWebContentsObserver, message)
    IPC_MESSAGE_HANDLER(ExtensionHostMsg_PostMessage, OnPostMessage)
    IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()
  return handled;
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/chrome_extension_web_contents_observer.cc中。

从这里可以看到，ChromeExtensionWebContentsObserver类的成员函数OnMessageReceived将类型为ExtensionHostMsg_PostMessage的IPC消息分发给另外一个成员函数OnPostMessage处理，如下所示：

void ChromeExtensionWebContentsObserver::OnPostMessage(int port_id,
                                                       const Message& message) {
  MessageService* message_service = MessageService::Get(browser_context());
  if (message_service) {
    message_service->PostMessage(port_id, message);
  }
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/chrome_extension_web_contents_observer.cc中。

ChromeExtensionWebContentsObserver类的成员函数OnPostMessage首先通过MessageService类的静态成员函数Get获得一个MessageService对象。这个MessageService对象负责管理在当前Render进程创建的所有Port。因此，有了这个MessageService对象之后，就可以调用它的成员函数PostMessage将参数message描述的消息分发给参数port_id描述的Port处理，如下所示：

void MessageService::PostMessage(int source_port_id, const Message& message) {
  int channel_id = GET_CHANNEL_ID(source_port_id);
  MessageChannelMap::iterator iter = channels_.find(channel_id);
  ......

  DispatchMessage(source_port_id, iter->second, message);
}

这个函数定义在external/chromium_org/chrome/browser/extensions/api/messaging/message_service.cc中。

MessageService类的成员函数PostMessage首先根据参数source_port_id获得一个Channel ID。有了这个Channel ID之后，就可以在成员变量channels_描述的一个Map中获得一个对应的MessageChannel对象。这个MessageChannel描述的就是一个Port。因此，有了这个MessageChannel对象之后，MessageService类的成员函数PostMessage就可以调用另外一个成员函数DispatchMessage将参数message描述的消息分发给它处理，如下所示：

void MessageService::DispatchMessage(int source_port_id,
                                     MessageChannel* channel,
                                     const Message& message) {
  // Figure out which port the ID corresponds to.
  int dest_port_id = GET_OPPOSITE_PORT_ID(source_port_id);
  MessagePort* port = IS_OPENER_PORT_ID(dest_port_id) ?
      channel->opener.get() : channel->receiver.get();

  port->DispatchOnMessage(message, dest_port_id);
}

这个函数定义在external/chromium_org/chrome/browser/extensions/api/messaging/message_service.cc中。

MessageService类的成员函数DispatchMessage首先根据参数source_port_id获得目标通信对象用来接收消息的Port的ID。这个ID就称为Dest Port ID。有了这个Dest Port ID之后，就可以通过参数channel描述的MessageChannel对象获得一个MessagePort对象。通过调用这个MessagePort对象的成员函数DispatchOnMessage，就可以将参数message描述的消息发送给目标通信对象。

上述获得的MessagePort对象的实际类型是ExtensionMessagePort。ExtensionMessagePort类重写了父类MessagePort的成员函数DispatchOnMessage。因此，MessageService类的成员函数DispatchMessage实际上是通过调用ExtensionMessagePort类的成员函数DispatchOnMessage向目标通信对象发送消息，如下所示：

void ExtensionMessagePort::DispatchOnMessage(const Message& message,
                                             int target_port_id) {
  process_->Send(new ExtensionMsg_DeliverMessage(
      routing_id_, target_port_id, message));
}

这个函数定义在文件external/chromium_org/chrome/browser/extensions/api/messaging/extension_message_port.cc中。

ExtensionMessagePort类的成员变量process_指向的是一个RenderProcessHost对象。这个RenderProcessHost对象描述的是目标通信对象所在的Render进程，ExtensionMessagePort类的成员函数DispatchOnMessage通过调用它的成员函数Send可以向目标通信对象所在的Render进程发送一个类型为ExtensionMsg_DeliverMessage的IPC消息。这个IPC消息封装了参数message描述的消息。

Render进程通过ExtensionHelper类的成员函数OnMessageReceived接收类型为ExtensionMsg_DeliverMessage的IPC消息，如下所示：

bool ExtensionHelper::OnMessageReceived(const IPC::Message& message) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(ExtensionHelper, message)
    ......
    IPC_MESSAGE_HANDLER(ExtensionMsg_DeliverMessage, OnExtensionDeliverMessage)
    ......
    IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()
  return handled;
}

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

从这里可以看到，ExtensionHelper类的成员函数OnMessageReceived将类型为ExtensionMsg_DeliverMessage的IPC消息分发给另外一个成员函数OnExtensionDeliverMessage处理，如下所示：

void ExtensionHelper::OnExtensionDeliverMessage(int target_id,
                                                const Message& message) {
  MessagingBindings::DeliverMessage(
      dispatcher_->script_context_set(), target_id, message, render_view());
}

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

ExtensionHelper类的成员变量dispatcher_指向的是一个Dispatcher对象。这个Dispatcher对象在当前Render进程中是唯一的。调用这个Dispatcher对象的成员函数script_context_set可以获得一个V8 Script Context集合，其中的每一个V8 Script Context都对应有一个Page。由于当前Render进程可能加载有多个Page，每一个Page也可能会创建多个V8 Script Context，因此这里获得的V8 Script Context的个数可能大于1。

此外，在当前Render进程加载的每一个Page都对应有一个ExtensionHelper对象。对于当前正在处理的ExtensionHelper对象来说，它对应的Page可以通过它的调用成员函数render_view获得。ExtensionHelper类的成员函数OnExtensionDeliverMessage所要做的事情就是将参数message描述的消息分发给当前正在处理的ExtensionHelper对象对应的Page处理。确切地说，是将分发给该Page创建的所有V8 Script Context进行处理。这是通过调用MessagingBindings类的静态成员函数DeliverMessage实现的，如下所示：

void MessagingBindings::DeliverMessage(
    const ScriptContextSet& context_set,
    int target_port_id,
    const Message& message,
    content::RenderView* restrict_to_render_view) {
  ......

  context_set.ForEach(
      restrict_to_render_view,
      base::Bind(&DeliverMessageToScriptContext, message.data, target_port_id));
}

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

MessagingBindings类的静态成员函数DeliverMessage所做的事情就是遍历参数context_set描述的V8 Script Context集合中的所有V8 Script Context。对于每一个V8 Script Context，都检查它们对应的Page是否就是参数restrict_to_render_view描述的Page。如果是的话，那么就会调用函数DeliverMessageToScriptContext将参数message描述的消息分给它处理，如下所示：

void DeliverMessageToScriptContext(const std::string& message_data,
                                   int target_port_id,
                                   ScriptContext* script_context) {
  v8::Isolate* isolate = v8::Isolate::GetCurrent();
  v8::HandleScope handle_scope(isolate);

  // Check to see whether the context has this port before bothering to create
  // the message.
  v8::Handle<v8::Value> port_id_handle =
      v8::Integer::New(isolate, target_port_id);
  v8::Handle<v8::Value> has_port =
      script_context->module_system()->CallModuleMethod(
          "messaging", "hasPort", 1, &port_id_handle);

  CHECK(!has_port.IsEmpty());
  if (!has_port->BooleanValue())
    return;

  std::vector<v8::Handle<v8::Value> > arguments;
  arguments.push_back(v8::String::NewFromUtf8(isolate,
                                              message_data.c_str(),
                                              v8::String::kNormalString,
                                              message_data.size()));
  arguments.push_back(port_id_handle);
  script_context->module_system()->CallModuleMethod(
      "messaging", "dispatchOnMessage", &arguments);
}

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

函数DeliverMessageToScriptContext首先是检查在参数script_context描述的V8 Script Context中，是否存在一个ID等于参数target_port_id的Port。如果存在，那么就会将参数message_data描述的消息分发给它处理。这是通过调用名称为"messaging"的Module导出的JS函数dispatchOnMessage（即messaging.dispatchOnMessage）实现的。

JS函数messaging.dispatchOnMessage的定义如下所示：

  // Called by native code when a message has been sent to the given port.
  function dispatchOnMessage(msg, portId) {
    var port = ports[portId];
    if (port) {
      if (msg)
        msg = $JSON.parse(msg);
      port.onMessage.dispatch(msg, port);
    }
  };

这个函数定义在文件external/chromium_org/extensions/renderer/resources/messaging.js中。

JS函数messaging.dispatchOnMessage首先根据参数portId描述的Port ID找到对应的Port。每一个Port都有一个onMessage属性。这个onMessage属性描述的是一个Event对象。这个Event对象内部维护有一个Listener列表。列表中的每一个Listener就是参数msg描述的消息的接收者。通过调用这个Event对象的成员函数dispatch即可以将参数msg描述的消息分发给它内部维护的Listener对象处理。

这样，我们就分析完成了chrome.runtime.sendMessage这个API接口的实现。与此同时，我们也分析完成了Extension的Page与Page之间，以及Page与Content Script之间的通信机制。概括来说，就是Page与Page之间通过直接访问对方定义的变量或者函数完成通信过程，而Page与Content Script之间通过消息完成通信过程。

至此，我们就分析完成了Chromium的Extension机制。从分析的过程可以知道，Extension相当于是运行在Chromium环境中的一种App。这种App由Page和Content Script组成。Page与Page之间，以及Page与Content Script之间，可以相互通信。其中，Content Script可以注入在Chromium加载的网页中执行，从而可以增加网页的功能。此外，这种App的开发语言是JavaScript，UI是HTML页面，并且通过Chromium提供的API完成自身的功能。重新学习Chromium的Extension机制，可以参考前面Chromium扩展（Extension）机制简要介绍和学习计划一文。更多的信息，也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/10/10 1:00:35 原文链接

阅读：38019 评论：7 查看评论

↧

Chromium插件（Plugin）机制简要介绍和学习计划

October 24, 2016, 12:59 am

≫ Next: Chromium插件（Plugin）模块（Module）加载过程分析

≪ Previous: Chromium扩展（Extension）通信机制分析

在Chromium中，除了可以使用Extension增强浏览器功能，还可以使用Plugin。两者最大区别是前者用JS开发，后者用C/C++开发。这意味着Plugin以Native Code运行，在性能上要优于Extension，适合执行计算密集型工作。不过，以Native Code运行，使得Plugin在安全上面临更大挑战。本文接下来对Chromium的Plugin机制进行简要介绍和制定学习计划。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

Chromium最初支持两种类型的Plugin：NPAPI Plugin和PPAPI Plugin。NPAPI的全称是Netscape Plugin Application Programming Interface，PPAPI的全称是Pepper Plugin Application Programming Interface。从表面上看，两者的区别在于使用了不同的API规范。其中，NPAPI来自于Mozilla，而PPAPI来自于Google。但实际上，PPAPI与另外一种称为Native Client（NaCl）的技术是紧密联系在一起的。

Native Client是一个由编译工具链（Toolchain）和运行时（Runtime）组成的集合。Toolchain包含在NaCl SDK中。此外，NaCl SDK还提供了PPAPI接口。也就是，通过NaCl SDK，我们可以开发PPAPI Plugin。这些PPAPI Plugin要使用NaCl SDK提供的Toolchain进行编译。Toolchain使用了修改过的GCC对PPAPI Plugin进行编译。这个修改过的GCC为PPAPI Plugin生成的每一条跳转指令的目标地址都是32位对齐的，并且PPAPI Plugin的第一条指令的地址也是32位对齐的。对齐的目的是出于安全考虑，防止恶意代码跳转到任意地址执行指令。同时，有些被认为是危险的指令是禁止使用的，例如ret指令。

除此之外，这个修改过的GCC还会设置一个系统API白名单。在这个白名单里面的系统API，被认为是安全的，也就是对系统不会造成威胁和破坏，它们可以被PPAPI Plugin调用。不在这个白名单内的系统API，将会被禁止调用。这意味着，我们在开发PPAPI Plugin的时候，只可以使用由Chromium提供的PPAPI，以及位于白名单内的系统API。

对PPAPI Plugin的CPU指令以及API调用进行限制，目的都是为了安全。这些安全理论基础可以参考Native Client: A Sandbox for Portable, Untrusted x86 Native Code和Google Native Client: Analysis Of A Secure Browser Plugin Sandbox这两个PDF文档，我们在这里就不展开来讲了。

单单靠Toolchain对PPAPI Plugin的CPU指令以及API调用进行限制是不足够的，因为黑客可以对编译后的PPAPI Plugin进行修改。因此，就需要有一套Runtime，在PPAPI Plugin加载时进行验证。这套Runtime由一个NaCl PPAPI Plugin和一个Service Runtime组成，如图1所示：

图1 NaCl Architecture

NaCl PPAPI Plugin是一个内置在Chromium中的PPAPI Plugin，它属于一个Trusted Plugin，运行在Render进程中。Chromium还内置了一个PPAPI Flash，它同样也是一个Trusted Plugin，运行在Render进程中。此外，负责解析网页的WebKit，以及运行网页中的JS的V8引擎，也是运行在Render进程中的。

注意，内置的PPAPI Plugin不需要使用NaCl技术，因为它们是Trusted Code。为了区分使用了NaCl技术的PPAPI Plugin和内置的PPAPI Plugin，我们将前者称为NaCl Module。NaCl Module是Untrusted Code，它们以两种形式存在：Portable Executable（PEXE）和Native Executable（NEXE）。PEXE是跨平台的，编译一次，可以在所有平台运行。NEXE是平台相关的，只可以运行在指定的平台。实际上，PEXE在加载之前，会先被翻译成NEXE再加载和执行。

在网页中，可以通过<embed>标签使用一个NaCl模块，如下所示：

<embed name="NaCl_module"
  id="hello_world"
  width=200 height=200
  src="hello_world.nmf"
  type="application/x-NaCl" />

其中，src属性指定了一个NaCl Module清单文件。这个清单文件以json格式描述了它由哪些文件组成，如下所示：

{ "files": {
  "libgcc_s.so.1": { "x86-32": { "url": "lib32/libgcc_s.so.1" } },
  "main.nexe": { "x86-32": { "url": "hw.nexe" } },
  "libc.so.3c8d1f2e": { "x86-32": { "url": "lib32/libc.so.3c8d1f2e" } },
  "libpthread.so.3c8d1f2e": { "x86-32": { "url": "lib32/libpthread.so.3c8d1f2e" } } },
  "program": { "x86-32": { "url": "lib32/runnable-ld.so" } }
}

WebKit会将<embed>标签当作是一个Plugin，于是就会请求Chromium加载这个Plugin。Chromium发现要加载的Plugin的MIME Type为“application/x-NaCl”，于是就会在当前的Render进程中创建一个NaCl PPAPI Plugin。这个NaCl PPAPI Plugin将会负责去加载真正的NaCl Module，也就是<embed>标签的src属性指定的NaCl Module。

NaCl PPAPI Plugin首先会解析要加载的NaCl Module的清单文件，然后通过Chromium提供的PPAPI接口去下载清单文件里面指定的文件。随后，NaCl PPAPI Plugin又会请求Chromium的Browser进程（即图1中的Broker进程）为它创建一个sel_ldr进程。这个sel_ldr进程与Render进程一样，运行在一个同样的Sandbox中。这个Sandbox称为Outer Sandbox。

上述sel_ldr进程启动起来之后，会加载一个Service Runtime。这个Service Runtime会加载真正的NaCl Module。不过，在加载之前，Service Runtime会对NaCl Module的指令及其调用的API进行验证。如果NaCl Module违反规则，那么它就不会被加载。这样就可以解决我们前面提到的NaCl Module使用修改过的GCC编译之后又被Hacked的问题。

Service Runtime作为NaCl技术的一部分，它是Trusted Code。NaCl Module是Untrusted Code。Service Runtime除了负责加载NaCl Module之外，还会为NaCl Module提供一些服务。例如，NaCl Module在调用白名单允许的系统API时，它不是直接调用的，而是要通过Service Runtime进行调用。尽管NaCl Module与Service Runtime在同一个进程中，但是NaCl Module是不可以直接执行Service Runtime的代码的。

当NaCl Module要执行Service Runtime的代码时，需要通过Trampoline和Springboard间接执行。Trampoline和Springboard的作用有点类似x86的调用门（Call Gate），目的就是为了保护Service Runtime的代码不会被随意执行，就像User Space的代码不能随意执行Kernel Space的代码一样。这套保护机制，以及前面提到的对NaCl Module的指令限制和系统API调用限制，称为Inner Sandbox。

NaCl Module是以间接方式调用Chromium提供的PPAPI接口的，表现它要通过NaCl PPAPI Plugin来调用Chromium提供的PPAPI接口。这意味着NaCl Module与NaCl PPAPI Plugin之间需要有一种通信机制。这种通信机制使用的协议称为Simple-RPC（Remote Procedure Call）协议，简称SRPC。SRPC协议建立在Inter-Module Communication（IMC）之上。IMC又是什么呢？实际上就是Unix Socket。总结来说，就是NaCl Module通过Unix Socket请求NaCl PPAPI Plugin为它调用Chromium提供的PPAPI接口。当然，这些远程请求会被NaCl SDK封装为简单的函数调用，这也是SRPC的由来。

从前面的分析就可以知道，一个使用了NaCl技术的PPAPI Plugin在执行时，被限制在两个Sandbox中。一个是Inner Sandbox，另一个是Outer Sandbox。其中，Inner Sandbox施加了强有力的保护。即使这层强有力的保护被突破，还有Outer Sandbox继续保护着。这样就可以很大程度上保证系统的安全。与此相反的是，NPAPI Plugin缺乏Inner Sandbox这样强有力的保护，就会很容易出现安全问题。同样，IE浏览器的ActiveX Plugin，也面临着NPAPI Plugin同样的安全问题。

虽然前面我们一直把PPAPI Plugin和NaCl联系在一起，但事实上，PPAPI Plugin也可以完全脱离NaCl而存在，例如，图1所示的内置在Chromium中的NaCl PPAPI Plugin和PPAPI Flash Plugin。Chromium提供了一个PPAPI SDK。通过这个SDK，就可以开发与NaCl技术无关的PPAPI Plugin。不过，这些PPAPI Plugin是不能通过Web Store分发的，只能由用户在本地安装。

接下来，基于越简单越容易理解的原则，我们将忽略掉NaCl技术，分析Chromium的PPAPI Plugin机制，并且假设它们是运行在独立的Plugin进程中的，就如我们在前面Chromium的Plugin进程启动过程分析一文所述的。

从前面Chromium的Plugin进程启动过程分析一文可以知道，WebKit在解析网页时碰到<embed>标签时，就会请求Browser进程启动一个Plugin进程加载该<embed>标签描述的Plugin。Plugin进程启动起来之后，会通过Unix Socket分别与Browser进程以及负责加载网页的Render进程建立通信通道，如图2所示：

图2 Plugin进程、Render进程和Browser进程的关系

Plugin进程启动之后，主要涉及到的是它与Render进程之间的通信。首先，Render进程会请求Plugin进程加载指定的Plugin Module。Plugin Module加载完成之后，Render进程再请求Plugin进程创建Plugin Instance。Plugin Instance创建出来之后，就会进入运行状态。在运行的过程中，它会不断地通过Chromium提供的PPAPI接口请求Render进程执行相应的操作，从而完成自身的功能。

要理解Chromium的Plugin机制，重点在于掌握前面我们提到的两个基本概念Plugin Module和Plugin Instance，以及Plugin Instance调用PPAPI接口的过程。为了更好地理解Chromium的Plugin机制，我们结合Chromium在源码中提供的一个GLES2 Example进行说明。

每一个Plugin都对应有一个Module，每一个Module又可以创建多个Instance，如图3所示：

图3 Plugin Module与Plugin Instance的关系

网页中的每一个<embed>标签在Render进程中都对应有一个PepperPluginInstanceImpl对象。这些PepperPluginInstanceImpl对象在Plugin进程中又都会有一个对应的pp::Instance对象。这些PepperPluginInstanceImpl对象和pp::Instance对象就是用来描述Plugin Instance的。

当PepperPluginInstanceImpl与pp::Instance需要通信时，就会通过图2所示的Unix Socket相互发送IPC消息。这些IPC消息的发送与接收在Render进程一侧由一个HostDispatcher负责，而在Plugin进程一侧由一个PluginDispatcher负责。

具有相同src值的<embed>标签对应的Plugin Instance属于同一个Plugin Module。Render进程为<embed>标签创建Plugin Instance时，首先会检查要创建的Plugin Instance所对应的Plugin Module是否已经加载。如果还没有加载，那么就会按照图4所示的流程进行加载：

图4 Plugin Module的加载流程

为<embed>标签创建Plugin Instance的请求是由WebKit发起的。这个请求会交给Content层处理。Content层检测到要创建的Plugin Instance对应的Plugin Module还没有加载时，就会创建一个Out-of-Process Plugin Module。这里我们假设<embed>标签描述的Plugin是一个非内置Plugin，因此需要为它创建一个Out-of-Process Plugin Module。

Content层在创建Out-of-Process Plugin Module的过程中，会请求Browser进程创建一个Plugin进程，并且请求在该Plugin进程中加载Plugin Module。Plugin Module实际上就是一个SO文件。这个SO文件加载完成后，Plugin进程会调用由它导出的一个函数PPP_InitializeModule，用来对刚刚加载的Plugin Module进行初始化。

其中的一个初始化操作就是创建一个pp::Module对象。每一个Plugin都要在自己的Module文件中自定义一个pp::Module类。例如，GLES2 Example自定义的pp::Module类为GLES2DemoModule，如下所示：

// This object is the global object representing this plugin library as long
// as it is loaded.
class GLES2DemoModule : public pp::Module {
 public:
  GLES2DemoModule() : pp::Module() {}
  virtual ~GLES2DemoModule() {}

  virtual pp::Instance* CreateInstance(PP_Instance instance) {
    return new GLES2DemoInstance(instance, this);
  }
};

这个类定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

同时，每一个Plugin还必须要在自己的Module文件中定义一个函数CreateModule。这个函数就是用来创建自定义的pp::Module对象的。例如，GLES2 Example定义的函数CreateModule的实现如下所示：

namespace pp {
// Factory function for your specialization of the Module object.
Module* CreateModule() {
  return new GLES2DemoModule();
}
}  // namespace pp

这个函数定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

有了这个自定义的pp::Module对象之后，以后就可以调用它的成员函数CreateInstance创建Plugin Instance了。GLES2 Example用GLES2DemoInstance类来描述Plugin Instance。这个GLES2DemoInstance类必须要继承于pp::Instance类，它的定义如下所示：

class GLES2DemoInstance : public pp::Instance,
                          public pp::Graphics3DClient {

 public:
  GLES2DemoInstance(PP_Instance instance, pp::Module* module);
  virtual ~GLES2DemoInstance();

  ......
};

这个类定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

Plugin Module的其它初始化工作还包括初始化一系列的PPAPI接口。这些PPAPI接口可以被自定义的pp::Instance调用。

回到Render进程中，当Plugin Module加载完成后，Render进程就会基于刚刚加载的Plugin Module创建一个Plugin Instance，也就是一个PepperPluginInstanceImpl对象。这个PepperPluginInstanceImpl对象接下来会被初始化。在初始化的过程中，它会请求Plugin进程创建一个对应的pp::Instance对象，如图5所示：

图5 Plugin Instance的创建过程

Render进程存在一个PPP_INSTANCE_INTERFACE_1_1接口，PepperPluginInstanceImpl对象会通过该接口请求Plugin进程创建一个对应的pp::Instance对象。

PPP_INSTANCE_INTERFACE_1_1接口定义了一个DidCreate操作。执行该操作的时候，Render进程就会向Plugin进程发送一个类型PpapiMsg_PPPInstance_DidCreate的IPC消息。该IPC消息携带了一个API_ID_PPP_INSTANCE参数，表示需要将它分发给一个PPP_Instance_Proxy对象处理。

Plugin进程也存在一个PPP_INSTANCE_INTERFACE_1_1接口。PPP_Instance_Proxy对象接收到类型PpapiMsg_PPPInstance_DidCreate的IPC消息时，就会执行该接口的DidCreate操作。这个操作在执行的过程中，就会调用前面在加载Plugin Module时创建的自定义pp::Module对象的成员函数CreateInstance，结果就会获得一个自定义的pp::Instance对象。

从前面的分析可以知道，对于GLES2 Example来说，它自定义的pp::Instance对象是一个GLES2DemoInstance对象。这个GLES2DemoInstance对象会通过Chromium提供的OpenGL ES 2.0 PPAPI接口为<embed>标签上绘制内容。

Plugin进程在加载Module的时候，会初始化一个PPB_OPENGLES_INTERFACE接口。该接口描述的就是一个OpenGL ES 2.0 PPAPI接口，它定义了一系列的OpenGL操作。每一个操作都对应一个OpenGL函数，如图6所示：

图6 OpenGL ES 2.0 PPAPI接口的调用过程

这些OpenGL操作又是通过调用GLES2Implementation类的同名成员函数实现的。例如，PPB_OPENGLES_INTERFACE接口定义的ActiveTexture操作，是通过调用GLES2Implementation类的成员函数ActiveTexture实现的。

从前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文可以知道，GLES2Implementation类描述的是一个Comand Buffer OpenGL接口，它的成员函数被调用的时候，实际上只是将要执行的OpenGL命令写入到一个Command Buffer中去，然后通知GPU进程执行该Command Buffer中的OpenGL命令。

不过，图6所示的GLES2Implementation对象并不是将Command Buffer的OpenGL命令直接传递给GPU进程执行的，而通过一个PpapCommandBufferProxy对象传递给Render进程中的一个CommandBufferProxyImpl对象处理。这个CommandBufferProxyImpl对象又会将传递给它的OpenGL命令写入到自己的Command Buffer中去，然后再通知GPU进程中的一个GpuCommandBufferStub对象执行该Command Buffer中的OpenGL命令。

由此可见，Plugin通过PPB_OPENGLES_INTERFACE接口执行OpenGL命令时，要执行的OpenGL命令会先传递给Render进程，Render进程再传递给GPU进程执行。为什么Plugin不直接将OpenGL命令传递给GPU进程执行呢？这是因为Plugin在运行的过程中，只能够与Render进程交互。因此，当它需要请求其它进程执行某一个操作时，就需要通过Render进程间接执行。

Plugin在执行OpenGL命令之前，首先要初始化一个OpenGL环境。这个初始化操作发生在Plugin对应的<embed>标签的视图创建完成时。这时候<embed>标签在Render进程中对应的PepperPluginInstanceImpl对象就会通过PPP_INSTANCE_INTERFACE_1_1接口向它在Plugin进程中对应的pp::Instance对象发出通知，如图7所示：

图7 Plugin初始化OpenGL环境的过程

PPP_INSTANCE_INTERFACE_1_1接口定义了一个DidChangeView操作。当<embed>标签的视图第一次创建或者以后大小发生变化时，该操作都会被执行。在执行的时候，它会向Plugin进程发送一个类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息。这个IPC消息携带了一个APP_ID_PPP_INSTANCE参数，表示需要将它分发给一个PPP_Instance_Proxy对象处理。

前面提到，Plugin进程也存在一个PPP_INSTANCE_INTERFACE_1_1接口。PPP_Instance_Proxy对象接收到类型PpapiMsg_PPPInstance_DidChangeView的IPC消息时，就会执行该接口的DidChangeView操作。这个操作在执行的过程中，又会找到之前加载Plugin Instance时创建的一个自定义pp::Instance对象，并且调用它的成员函数DidChangeView，用来通知它<embed>标签的视图大小发生了变化。

在GLES2 Example中，自定义的pp::Instance对象是一个GLES2DemoInstance对象。当这个GLES2DemoInstance对象的成员函数DidChangeView第一次被调用的时候，会做两件事情。第一件事情是创建一个Graphics3D对象。这个Graphics3D对象在Plugin进程中用来描述一个OpenGL环境。第二件事情是将前面创建的OpenGL环境与当前正在处理的Plugin进行绑定。这两件事情完成之后，一个Plugin的OpenGL环境就创建和初始化完成了。

Plugin的OpenGL环境的创建过程如图8所示：

图8 Plugin的OpenGL环境的创建过程

Plugin进程存在一个PPB_GRAPHICS_3D_INTERFACE_1_0接口。PPB_GRAPHICS_3D_INTERFACE_1_0接口定义了一个Create操作。在Plugin进程中创建OpenGL环境，也就是一个Graphics3D对象的时候，上述的Create操作会被执行。在执行的过程中，它会通过一个APP_ID_RESOURCE_CREATION参数找到一个ResourceCreationProxy对象，然后再通过这个ResourceCreationProxy对象向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息。这个IPC消息携带了一个APP_ID_PPB_GRAPHICS_3D参数，表示要将它分发给一个PPB_Graphics3D_Proxy对象处理。

PPB_Graphics3D_Proxy对象在处理类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息时，会创建一个PPB_Graphics3D_Impl对象。这个PPB_Graphics3D_Impl对象在创建的过程中，会与GPU进程建立一个GPU通道。这个GPU通道建立起来之后，就会在GPU进程中获得一个OpenGL环境。这个OpenGL环境就是用来执行Plugin发出的OpenGL命令的。Render进程与GPU进程建立GPU通道的过程，可以参考前面Chromium硬件加速渲染的OpenGL上下文创建过程分析一文。

给Plugin绑定OpenGL环境的过程如图9所示：

图9 Plugin绑定OpenGL环境的过程

Plugin进程存在一个PPB_INSTANCE_INTERFACE_1_1接口。PPP_INSTANCE_INTERFACE_1_1接口定义了一个BindGraphics操作。该操作在执行的时候，会通过一个APP_ID_PPB_INSTANCE参数找到一个PPB_Instance_Proxy对象，然后再通过这个PPB_Instance_Proxy对象向Render进程发送一个类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息。这个IPC消息携带了一个APP_ID_PPB_INSTANCE参数，表示要将它分发给一个PPB_Instance_Proxy对象处理。

PPB_Instance_Proxy对象在处理类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息，会找到要绑定OpenGL环境的Plugin Instance，也就是一个PepperPluginInstanceImpl对象，然后调用这个PepperPluginInstanceImpl对象的成员函数BindToInstance，将其绑定到指定的OpenGL环境中去，也就是与前面创建的一个PPB_Graphics3D_Impl对象建立关联。

这样，我们就介绍完了Chromium的Plugin机制。由于Chromium已不再支持NPAPI Plugin，这里我们说的Plugin，指的是PPAPI Plugin，也称为Pepper Plugin。Pepper Plugin可以通过NaCl SDK开发，也可以通过PPAPI SDK开发。通过NaCl SDK开发的Pepper Plugin在NaCl环境中运行，受到两个Sandbox保护，因此它的安全性是非常高的。在Web Store中分发的Pepper Plugin必须要通过NaCl SDK开发，以及运行在NaCl环境中。内置的Pepper Plugin，或者仅仅在本地安装的Pepper Plugin，可以不运行在NaCl环境中，因此它们可以通过PPAPI SDK进行开发。

不管是否运行在NaCl环境中，Pepper Plugin使用Chromium提供的PPAPI接口的方式都是一样的。换句话说，就是NaCl环境对Pepper Plugin来说是透明的。为了简单起见，在接下来的文章中，我们假设Pepper Plugin是基于PPAPI SDK开发的，也就是它没有运行在NaCl环境中。

接下来，我们将结合文中提到的GLES2 Example，按照以下三个情景，对Chromium的Pepper Plugin机制进行更详细的分析：

1. Plugin Module的加载过程；

2. Plugin Instance的创建过程；

3. Pugin Instance的3D渲染过程。

其中，前面两个情景有助于我们理清Plugin Module与Plugin Instance的关系，第三个情景有助于我们理解Plugin调用PPAPI接口的过程，也就是Plugin与浏览器的交互过程。理解了这三个情景之后，我们就可以深刻理解Chromium的Pepper Plugin机制了。敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/10/24 0:59:13 原文链接

阅读：36546 评论：4 查看评论

↧

Chromium插件（Plugin）模块（Module）加载过程分析

October 31, 2016, 12:59 am

≫ Next: Chromium插件（Plugin）实例（Instance）创建过程分析

≪ Previous: Chromium插件（Plugin）机制简要介绍和学习计划

在Chromium中，每一个Plugin都对应一个Module，称为Plugin Module。一个Plugin Module可创建多个Plugin Instance。每一个Plugin Instance对应于网页中的一个<embed>标签。在为<embed>标签创建Plugin Instance之前，先要加载其对应的Plugin Module。本文接下来分析Plugin Module的加载过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

Plugin Module的加载过程如图1所示：

图1 Plugin Module的加载过程

WebKit请求Content层为网页中的<embed>标签创建Plugin Instance时，Content层会检查要创建的Plugin Instance对应的Plugin Module是否已经加载。如果还没有加载，那么通常就会创建一个Out-of-Process Plugin Module。这里说通常，是因为大部分Plugin都是运行在一个独立的进程中，只有内置Plugin才允许运行在Render进程中。本文我们只讨论Out-of-Process Plugin Module的情形。

Content层在创建Out-of-Process Plugin Module的过程中，会请求Browser进程创建一个Plugin进程，并且请求该Plugin进程加载指定的Plugin Module。每一个Plugin Module都会有一个导出函数PPP_InitializeModule。Plugin Module加载完成之后，它导出的函数PPP_InitializeModule就会被调用，用来执行初始化工作。

Plugin进程启动起来之后，它与Render进程之间的通信是通过一个PluginDispatcher对象进行的。与此同时，Render进程也会通过一个HostDispatcher对象与Plugin进程进行通信。例如，Content层请求Plugin进程加载指定的Plugin Module，就是通过Render进程中的HostDispatcher对象向Plugin进程中的PluginDispatcher对象发送IPC消息进行的。

Content层在请求Browser进程创建一个Plugin进程加载一个Plugin Module之前，必须要知道这个Plugin Module的信息，例如它的SO文件路径。用户当前安装的所有Plugin是由Chromium中的一个Plugin Service进行管理的，因此Content层可以通过这个Plugin Service获得要加载的Plugin Module的信息。

在分析Plugin Module的加载之前，我们先分析Plugin Service的启动过程。在启动的过程中，它就会注册所有内建（Built-In）的Plugin以及用户安装的Plugin在内部的一个List中。从前面Chromium扩展（Extension）加载过程分析一文可以知道，Chromium的Browser进程在启动的时候，会调用BrowserMainLoop类的成员函数CreateStartupTasks创建一系列的Startup Task。其中的一个Startup Task就是用来启动Plugin Service的，如下所示：

void BrowserMainLoop::CreateStartupTasks() {
  ......

  // First time through, we really want to create all the tasks
  if (!startup_task_runner_.get()) {
#if defined(OS_ANDROID)
    startup_task_runner_ = make_scoped_ptr(new StartupTaskRunner(
        base::Bind(&BrowserStartupComplete),
        base::MessageLoop::current()->message_loop_proxy()));
#else
    startup_task_runner_ = make_scoped_ptr(new StartupTaskRunner(
        base::Callback<void(int)>(),
        base::MessageLoop::current()->message_loop_proxy()));
#endif
    StartupTask pre_create_threads =
        base::Bind(&BrowserMainLoop::PreCreateThreads, base::Unretained(this));
    startup_task_runner_->AddTask(pre_create_threads);

    ......
  }
#if defined(OS_ANDROID)
  if (!BrowserMayStartAsynchronously()) {
    // A second request for asynchronous startup can be ignored, so
    // StartupRunningTasksAsync is only called first time through. If, however,
    // this is a request for synchronous startup then it must override any
    // previous call for async startup, so we call RunAllTasksNow()
    // unconditionally.
    startup_task_runner_->RunAllTasksNow();
  }
#else
  startup_task_runner_->RunAllTasksNow();
#endif
}

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

这个Startup Task绑定了BrowserMainLoop类的成员函数PreCreateThreads，在创建各种Browser线程之前执行，执行过程如下所示：

int BrowserMainLoop::PreCreateThreads() {
  ......

#if defined(ENABLE_PLUGINS)
  // Prior to any processing happening on the io thread, we create the
  // plugin service as it is predominantly used from the io thread,
  // but must be created on the main thread. The service ctor is
  // inexpensive and does not invoke the io_thread() accessor.
  {
    TRACE_EVENT0("startup", "BrowserMainLoop::CreateThreads:PluginService");
    PluginService::GetInstance()->Init();
  }
#endif

  ......
  return result_code_;
}

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

从这里可以看到，只有在编译时定义了宏ENABLE_PLUGINS，Chromium才会支持Plugin机制。在这种情况下，BrowserMainLoop类的成员函数PreCreateThreads首先会调用PluginService类的静态成员函数GetInstance获得一个PluginServiceImpl对象，如下所示：

PluginService* PluginService::GetInstance() {
  return PluginServiceImpl::GetInstance();
}

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

PluginService的静态成员函数GetInstance又是通过调用PluginServiceImpl类的静态成员函数GetInstance获得一个PluginServiceImpl对象的，如下所示：

PluginServiceImpl* PluginServiceImpl::GetInstance() {
  return Singleton<PluginServiceImpl>::get();
}

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

从这里可以看到，PluginServiceImpl类的静态成员函数GetInstance返回的PluginServiceImpl对象在当前进程（即Browser进程）是唯一的。这个PluginServiceImpl对象返回给BrowserMainLoop类的成员函数PreCreateThreads之后，后者会调用它的成员函数Init执行初始化工作，如下所示：

void PluginServiceImpl::Init() {
  ......

  RegisterPepperPlugins();

  ......
}

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

PluginServiceImpl类的成员函数Init会调用另外一个成员函数RegisterPepperPlugins注册那些Built-In Plugin以及用户安装的Plugin到Plugin Service中去，如下所示：

void PluginServiceImpl::RegisterPepperPlugins() {
  ComputePepperPluginList(&ppapi_plugins_);
  for (size_t i = 0; i < ppapi_plugins_.size(); ++i) {
    RegisterInternalPlugin(ppapi_plugins_[i].ToWebPluginInfo(), true);
  }
}

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

PluginServiceImpl类的成员函数RegisterPepperPlugins首先调用函数ComputePepperPluginList获得那些Built-In Plugin和用户安装的Plugin，如下所示：

void ComputePepperPluginList(std::vector<PepperPluginInfo>* plugins) {
  GetContentClient()->AddPepperPlugins(plugins);
  ComputePluginsFromCommandLine(plugins);
}

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

这里我们假设当前分析的是Chrome浏览器。在这种情况下，PluginServiceImpl类的成员函数RegisterPepperPlugins调用函数GetContentClient获得的是一个ChromeContentClient对象。调用这个ChromeContentClient对象的成员函数AddPepperPlugin即可以获得Built-In Plugin，如下所示：

void ChromeContentClient::AddPepperPlugins(
    std::vector<content::PepperPluginInfo>* plugins) {
  ComputeBuiltInPlugins(plugins);
  AddPepperFlashFromCommandLine(plugins);

  content::PepperPluginInfo plugin;
  if (GetBundledPepperFlash(&plugin))
    plugins->push_back(plugin);
}

这个函数定义在文件external/chromium_org/chrome/common/chrome_content_client.cc中。

ChromeContentClient类的成员函数AddPepperPlugin首先调用函数ComputeBuiltInPlugins获得一些重要的Built-In Plugin，例如NaCl Plugin和PDF Plugin，如下所示：

void ComputeBuiltInPlugins(std::vector<content::PepperPluginInfo>* plugins) {
  // PDF.
  //
  // Once we're sandboxed, we can't know if the PDF plugin is available or not;
  // but (on Linux) this function is always called once before we're sandboxed.
  // So the first time through test if the file is available and then skip the
  // check on subsequent calls if yes.
  static bool skip_pdf_file_check = false;
  base::FilePath path;
  if (PathService::Get(chrome::FILE_PDF_PLUGIN, &path)) {
    if (skip_pdf_file_check || base::PathExists(path)) {
      content::PepperPluginInfo pdf;
      pdf.path = path;
      pdf.name = ChromeContentClient::kPDFPluginName;
      if (CommandLine::ForCurrentProcess()->HasSwitch(
              switches::kOutOfProcessPdf)) {
        pdf.is_out_of_process = true;
        content::WebPluginMimeType pdf_mime_type(kPDFPluginOutOfProcessMimeType,
                                                 kPDFPluginExtension,
                                                 kPDFPluginDescription);
        pdf.mime_types.push_back(pdf_mime_type);
        // TODO(raymes): Make print preview work with out of process PDF.
      } else {
        content::WebPluginMimeType pdf_mime_type(kPDFPluginMimeType,
                                                 kPDFPluginExtension,
                                                 kPDFPluginDescription);
        content::WebPluginMimeType print_preview_pdf_mime_type(
            kPDFPluginPrintPreviewMimeType,
            kPDFPluginExtension,
            kPDFPluginDescription);
        pdf.mime_types.push_back(pdf_mime_type);
        pdf.mime_types.push_back(print_preview_pdf_mime_type);
      }
      pdf.permissions = kPDFPluginPermissions;
      plugins->push_back(pdf);

      skip_pdf_file_check = true;
    }
  }

  // Handle Native Client just like the PDF plugin. This means that it is
  // enabled by default for the non-portable case.  This allows apps installed
  // from the Chrome Web Store to use NaCl even if the command line switch
  // isn't set.  For other uses of NaCl we check for the command line switch.
  // Specifically, Portable Native Client is only enabled by the command line
  // switch.
  static bool skip_nacl_file_check = false;
  if (PathService::Get(chrome::FILE_NACL_PLUGIN, &path)) {
    if (skip_nacl_file_check || base::PathExists(path)) {
      content::PepperPluginInfo nacl;
      nacl.path = path;
      nacl.name = ChromeContentClient::kNaClPluginName;
      content::WebPluginMimeType nacl_mime_type(kNaClPluginMimeType,
                                                kNaClPluginExtension,
                                                kNaClPluginDescription);
      nacl.mime_types.push_back(nacl_mime_type);
      if (!CommandLine::ForCurrentProcess()->HasSwitch(
              switches::kDisablePnacl)) {
        content::WebPluginMimeType pnacl_mime_type(kPnaclPluginMimeType,
                                                   kPnaclPluginExtension,
                                                   kPnaclPluginDescription);
        nacl.mime_types.push_back(pnacl_mime_type);
      }
      nacl.permissions = kNaClPluginPermissions;
      plugins->push_back(nacl);

      skip_nacl_file_check = true;
    }
  }

  ......
}

这个函数定义在文件external/chromium_org/chrome/common/chrome_content_client.cc。

除了NaCl Plugin和PDF Plugin，还有一个重析Built-In Plugin，就是Flash Plugin。回到ChromeContentClient对象的成员函数AddPepperPlugin中，它首先调用函数AddPepperFlashFromCommandLine检查Browser进程的命令行参数是否包含了switches::kPpapiFlashPath（“ppapi-flash-path”）启动选项。如果包含了，那么该选项的值就指定了一个Flash Plugin作为Chromium默认使用的Flash Plugin，如下所示：

void AddPepperFlashFromCommandLine(
    std::vector<content::PepperPluginInfo>* plugins) {
  const CommandLine::StringType flash_path =
      CommandLine::ForCurrentProcess()->GetSwitchValueNative(
          switches::kPpapiFlashPath);
  if (flash_path.empty())
    return;

  // Also get the version from the command-line. Should be something like 11.2
  // or 11.2.123.45.
  std::string flash_version =
      CommandLine::ForCurrentProcess()->GetSwitchValueASCII(
          switches::kPpapiFlashVersion);

  plugins->push_back(
      CreatePepperFlashInfo(base::FilePath(flash_path), flash_version));
}

这个函数定义在文件external/chromium_org/chrome/common/chrome_content_client.cc。

如果Browser进程的命令行参数没有包含switches::kPpapiFlashPath启动选项，那么ChromeContentClient类的成员函数AddPepperPlugin将会调用另外一个函数GetBundledPepperFlash获得一个由Chromium自己实现的Flash Plugin，如下所示：

bool GetBundledPepperFlash(content::PepperPluginInfo* plugin) {
#if defined(FLAPPER_AVAILABLE)
  CommandLine* command_line = CommandLine::ForCurrentProcess();

  // Ignore bundled Pepper Flash if there is Pepper Flash specified from the
  // command-line.
  if (command_line->HasSwitch(switches::kPpapiFlashPath))
    return false;

  ......

  base::FilePath flash_path;
  if (!PathService::Get(chrome::FILE_PEPPER_FLASH_PLUGIN, &flash_path))
    return false;

  *plugin = CreatePepperFlashInfo(flash_path, FLAPPER_VERSION_STRING);
  return true;
#else
  return false;
#endif  // FLAPPER_AVAILABLE
}

这个函数定义在文件external/chromium_org/chrome/common/chrome_content_client.cc。

这个Flash Plugin称为Flapper。只有在编译Chromium时，定义了宏FLAPPER_AVAILABLE，Chromium才会包含这个名为Flapper的Flash Plugin。并且只有在Browser进程的命令行参数没有包含switches::kPpapiFlashPath启动选项时，这个名为Flapper的Flash Plugin才会被使用。

这一步执行完成后，Chromium就获得了所有的Built-In Plugin。回到前面分析的函数ComputePepperPluginList中，它接下来调用函数ComputePluginsFromCommandLine获得用户安装的Plugin，如下所示：

void ComputePluginsFromCommandLine(std::vector<PepperPluginInfo>* plugins) {
  ......

  bool out_of_process = true;
  if (CommandLine::ForCurrentProcess()->HasSwitch(switches::kPpapiInProcess))
    out_of_process = false;

  const std::string value =
      CommandLine::ForCurrentProcess()->GetSwitchValueASCII(
          switches::kRegisterPepperPlugins);
  if (value.empty())
    return;

  // FORMAT:
  // command-line = <plugin-entry> + *( LWS + "," + LWS + <plugin-entry> )
  // plugin-entry =
  //    <file-path> +
  //    ["#" + <name> + ["#" + <description> + ["#" + <version>]]] +
  //    *1( LWS + ";" + LWS + <mime-type> )
  std::vector<std::string> modules;
  base::SplitString(value, ',', &modules);
  ......

  for (size_t i = 0; i < plugins_to_register; ++i) {
    std::vector<std::string> parts;
    base::SplitString(modules[i], ';', &parts);
    ......

    std::vector<std::string> name_parts;
    base::SplitString(parts[0], '#', &name_parts);

    PepperPluginInfo plugin;
    plugin.is_out_of_process = out_of_process;  
#if defined(OS_WIN)
    // This means we can't provide plugins from non-ASCII paths, but
    // since this switch is only for development I don't think that's
    // too awful.
    plugin.path = base::FilePath(base::ASCIIToUTF16(name_parts[0]));
#else
    plugin.path = base::FilePath(name_parts[0]);
#endif

    ......

    plugins->push_back(plugin);
  }
}

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

如果Chromium允许加载Plugin，那么它的Browser进程在启动的时候，会将用户安装的Plugin收集起来，并且会将收集到的信息设置在一个switches::kRegisterPepperPlugins启动选项中。函数函数ComputePluginsFromCommandLine通过解析这个启动选项，就可以获得用户安装的Plugin了。

在默认情况下，用户安装的Plugin都是要运行在一个独立的Plugin进程中的。不过，如果Browser进程的命令行参数包含了switches::kPpapiInProcess启动选项，那么它们就不会运行在一个独立的Plugin进程中，而是直接运行在Render进程中。

这一步执行完成之后，Chromium就获得了所有的Built-In Plugin以及用户安装的Plugin。回到PluginServiceImpl类的成员函数RegisterPepperPlugins中，它接下来就会将前面获得每一个Built-In Plugin以及用户安装的Plugin注册在Plugin Service内部的一个List中。这是通过调用PluginServiceImpl类的成员函数RegisterInternalPlugin实现的，如下所示：

void PluginServiceImpl::RegisterInternalPlugin(
    const WebPluginInfo& info,
    bool add_at_beginning) {
  ......
  PluginList::Singleton()->RegisterInternalPlugin(info, add_at_beginning);
}

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

参数info指向的一个WebPluginInfo对象描述的就是前面获得的一个Built-In Plugin或者用户安装的Plugin。Browser进程存在一个PluginList单例对象。这个PluginList单例对象描述的就是Plugin Service内部用来保存Plugin信息的一个List。因此，调用这个PluginList单例对象的成员函数RegisterInternalPlugin就可以将参数info描述的Plugin注册在Plugin Service的内部，如下所示：

void PluginList::RegisterInternalPlugin(const WebPluginInfo& info,
                                        bool add_at_beginning) {
  base::AutoLock lock(lock_);

  internal_plugins_.push_back(info);
  if (add_at_beginning) {
    // Newer registrations go earlier in the list so they can override the MIME
    // types of older registrations.
    extra_plugin_paths_.insert(extra_plugin_paths_.begin(), info.path);
  } else {
    extra_plugin_paths_.push_back(info.path);
  }
}

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

从前面的分析可以知道，参数info描述的不管是Built-In Plugin还是用户安装的Plugin，它们都是Pepper Plugin。Pepper Plugin在PluginList类中称为Internal Plugin。这些Internal Plugin将会保存在成员变量internal_plugins_描述的一个std::vector中。如果Chromium支持NPAPI Plugin，则它们的信息就不会保存在这个std::vector中，而是保存在另外一个成员变量extra_plugin_paths_描述的一个std::vector中。

注意，Pepper Plugin的信息同样会保存在成员变量extra_plugin_paths_描述的std::vector中。这样，当Chromium需要获得一个Plugin的信息时，不管它是Pepper Plugin，还是NPAPI Plugin，均可以通过成员变量extra_plugin_paths_描述的std::vector获得。

这一步执行完成后，Chromium的Browser进程就初始化好了一个Plugin Service，并且将所有的Built-In Plugin和用户安装的Plugin注册在了这个Plugin Service内部的一个List中。这个List称为Plugin List。接下来，我们就继续分析Plugin Module的加载过程。

根据前面Chromium网页DOM Tree创建过程分析一文的分析，我们可以知道，WebKit在解析网页的时候，如果碰到一个<embed>标签，那么就会为它创建一个HTMLEmbedElement对象，作为网页DOM Tree中的一个DOM节点。当需要为<embed>标签创建Plugin Instance时，前面为其创建的HTMLEmbedElement对象的成员函数loadPlugin就会被调用。

HTMLEmbedElement类的成员函数loadPlugin是从父类HTMLPlugInElement继承下来的，它的实现如下所示：

bool HTMLPlugInElement::loadPlugin(const KURL& url, const String& mimeType, const Vector<String>& paramNames, const Vector<String>& paramValues, bool useFallback, bool requireRenderer)
{
    LocalFrame* frame = document().frame();
    ......

    RefPtr<Widget> widget = m_persistedPluginWidget;
    if (!widget) {
        ......
        widget = frame->loader().client()->createPlugin(this, url, paramNames, paramValues, mimeType, loadManually, policy);
    }

    ......

    return true;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp中。

HTMLEmbedElement类的成员函数loadPlugin首先调用成员函数document获得当前网页的Document对象。有了这个Document对象之后，就可以调用它的成员函数frame获得一个LocalFrame对象。调用这个LocalFrame对象的成员函数loader又可以获得一个FrameLoader对象。调用这个FrameLoader对象的成员函数client又可以获得一个FrameLoaderClientImpl对象。通过这个FrameLoaderClientImpl对象，WebKit可以请求它的使用者，即Chromium的Content层，执行指定的操作。例如，HTMLEmbedElement类的成员函数loadPlugin就是通过调用这个FrameLoaderClientImpl的成员函数createPlugin请求Content层为当前正在处理的<embed>标签创建一个Plugin Instance的。

注意，当HTMLEmbedElement类的成员变量m_persistedPluginWidget的值不等于NULL时，它指向的是一个Widget对象。在这种情况下，就表示WebKit已经为当前正在处理的<embed>标签创建过Plugin Instance了。这时候就不要重复创建。

接下来，我们继续分析WebKit为<embed>标签创建Plugin Instance的过程，也就是FrameLoaderClientImpl类的成员函数createPlugin的实现，如下所示：

PassRefPtr<Widget> FrameLoaderClientImpl::createPlugin(
    HTMLPlugInElement* element,
    const KURL& url,
    const Vector<String>& paramNames,
    const Vector<String>& paramValues,
    const String& mimeType,
    bool loadManually,
    DetachedPluginPolicy policy)
{
    ......

    WebPluginParams params;
    params.url = url;
    params.mimeType = mimeType;
    params.attributeNames = paramNames;
    params.attributeValues = paramValues;
    params.loadManually = loadManually;

    WebPlugin* webPlugin = m_webFrame->client()->createPlugin(m_webFrame, params);
    if (!webPlugin)
        return nullptr;

    // The container takes ownership of the WebPlugin.
    RefPtr<WebPluginContainerImpl> container =
        WebPluginContainerImpl::create(element, webPlugin);

    if (!webPlugin->initialize(container.get()))
        return nullptr;

    ......

    return container;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/web/FrameLoaderClientImpl.cpp中。

FrameLoaderClientImpl类的成员变量m_webFrame指向的是一个WebLocalFrameImpl对象。调用这个WebLocalFrameImpl对象的成员函数client可以获得一个WebFrameClient接口。这个WebFrameClient接口由WebKit的使用者实现的。在我们这个情景中，WebKit的使用者即为Chromium的Content层。调用这个WebFrameClient接口的成员函数createPlugin即可为参数element描述的<embed>标签创建一个Plugin Instance。

Content层的RenderFrameImpl类实现了WebFrameClient接口。因此，WebKit实际上是通过调用RenderFrameImpl类的成员函数createPlugin为网页的<embed>标签创建Plugin Instance。在创建Plugin Instance的过程中，如果发现Plugin Module还没有加载，那么就会进行加载。我们假设这个Plugin Module是加载在一个独立的Plugin进程中的。这时候这个Plugin Module在Render进程中使用一个PluginModule对象描述，而在Plugin进程中使用一个pp::Module对象描述。这个加载过程可以参考前面Chromium的Plugin进程启动过程分析一文。

Plugin Module加载完成之后，Content层就会请求创建它的一个Instance。从前面Chromium的Plugin进程启动过程分析一文可以知道，这个Plugin Instance在Render进程中使用一个PepperWebPluginImpl对象描述。

有了上述的PepperWebPluginImpl对象之后， FrameLoaderClientImpl类的成员函数createPlugin接下来会调用它的成员函数initialize对它进行初始化。在初始化的过程中，Render进程会请求Plugin进程创建一个真正的Plugin Instance。从前面Chromium插件（Plugin）机制简要介绍和学习计划一文可以知道，这个Plugin Instance使用一个pp::Instance对象描述。

在调用PepperWebPluginImpl类的成员函数initialize请求Plugin进程创建Plugin Instance之前，FrameLoaderClientImpl类的成员函数createPlugin会为参数element描述的<embed>标签创建一个类型为WebPluginContainerImpl的Widget。这个Widget用作<embed>标签的视图，最终会返回给FrameLoaderClientImpl类的成员函数createPlugin的调用者，即HTMLEmbedElement类的成员函数loadPlugin。

从前面Chromium的Plugin进程启动过程分析一文可以知道，Plugin进程在加载了Plugin Module之后，会对该Plugin Module进行初始化，这是通过调用Plugin Module导出的函数PPP_InitializeModule实现的。

函数PPP_InitializeModule的实现如下所示：

static pp::Module* g_module_singleton = NULL;
......

PP_EXPORT int32_t PPP_InitializeModule(PP_Module module_id,
                                       PPB_GetInterface get_browser_interface) {
  pp::Module* module = pp::CreateModule();
  if (!module)
    return PP_ERROR_FAILED;

  if (!module->InternalInit(module_id, get_browser_interface)) {
    delete module;
    return PP_ERROR_FAILED;
  }
  g_module_singleton = module;
  return PP_OK;
}

这个函数定义在文件external/chromium_org/ppapi/cpp/ppp_entrypoints.cc中。

Chromium要求每一个Pepper Plugin都要导出一个pp::CreateModule函数。例如，我们在Chromium插件（Plugin）机制简要介绍和学习计划一文提到的GLES2 Example导出的函数pp::CreateModule的实现如下所示：

namespace pp {
// Factory function for your specialization of the Module object.
Module* CreateModule() {
  return new GLES2DemoModule();
}
}  // namespace pp

这个函数定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

这个导出的函数pp::CreateModule所要做的事情就是创建一个自定义的pp::Module。对于GLES2 Example，它自定义的pp::Module为GLES2DemoModule，也就是GLES2DemoModule类是从pp::Module类继承下来的。

回到前面分析的函数PPP_InitializeModule中，通过Pepper Plugin导出的函数pp::CreateModule函数创建的自定义pp::Module将会保存在一个全局变量g_module_singleton中，以后通过这个全局变量就可以访问到Pepper Plugin自定义的pp::Module了。

函数PPP_InitializeModule在将自定义pp::Module保存在全局变量g_module_singleton之前，还会对其执行初始化操作。这是通过调用它从父类pp::Module继承下来的成员函数InternalInit实现的。初始化过程如下所示：

bool Module::InternalInit(PP_Module mod,
                          PPB_GetInterface get_browser_interface) {
  pp_module_ = mod;
  get_browser_interface_ = get_browser_interface;

  // Get the core interface which we require to run.
  const PPB_Core* core = reinterpret_cast<const PPB_Core*>(GetBrowserInterface(
      PPB_CORE_INTERFACE));
  if (!core)
    return false;
  core_ = new Core(core);

  return Init();
}

这个函数定义在文件external/chromium_org/ppapi/cpp/module.cc中。

参数mod的类型为PP_Module。PP_Module定义为一个int32_t，它是用来描述一个Plugin Module ID的。也就是说，每一个Plugin Module都有一个ID。这个ID将会保存在pp::Module类的成员变量pp_module_中。

从前面Chromium的Plugin进程启动过程分析一文可以知道，参数get_browser_interface指向的是一个函数。这个函数为PluginDispatcher类的静态成员函数GetBrowserInterface，它将会保存在pp::Module类的成员变量get_browser_interface_中。以后通过这个函数可以获得Chromium提供给Plugin使用的接口。例如，pp::Module类的成员函数InternalInit接下来就会通过这个函数获得一个类型为PPB_CORE_INTERFACE的接口。这个接口会封装在一个Core对象中，并且这个Core对象会保存在pp::Module类的成员变量core_中。

接下来，我们就继续分析Plugin获得类型为PPB_CORE_INTERFACE的接口的过程。从这个过程我们还可以看到Chromium提供给Plugin使用的其它类型的接口。pp::Module类的成员函数InternalInit获得类型为PPB_CORE_INTERFACE的接口是通过调用成员函数GetBrowserInterface实现的，如下所示：

const void* Module::GetBrowserInterface(const char* interface_name) {
  return get_browser_interface_(interface_name);
}

这个函数定义在文件external/chromium_org/ppapi/cpp/module.cc中。

pp:Module类的成员函数GetBrowserInterface通过调用成员变量get_browser_interface_描述的函数获取类型为PPB_CORE_INTERFACE的接口。前面提到，pp::Module类的成员变量get_browser_interface_为PluginDispatcher类的静态成员函数GetBrowserInterface。因此，接下来我们继续分析PluginDispatcher类的静态成员函数GetBrowserInterface的实现，如下所示：

// static
const void* PluginDispatcher::GetBrowserInterface(const char* interface_name) {
  ......

  return InterfaceList::GetInstance()->GetInterfaceForPPB(interface_name);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/plugin_dispatcher.cc中。

PluginDispatcher类的静态成员函数GetBrowserInterface首先调用InterfaceList类的静态成员函数GetInstance获得当前Plugin进程中的一个InterfaceList单例对象，如下所示：

// static
InterfaceList* InterfaceList::GetInstance() {
  return Singleton<InterfaceList>::get();
}

这个函数定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

InterfaceList类的静态成员函数GetInstance通过模板类Singleton<InterfaceList>的静态成员函数获得当前Plugin进程中的InterfaceList单例对象。这个InterfaceList单例对象如果还没有创建，那么此时就会进行创建。在创建的过程中，它将会初始化一系列的接口。这些接口都是Chromium提供给Plugin使用的，其中就包括前面提到的类型为PPB_CORE_INTERFACE的接口。

接下来，我们就继续分析InterfaceList单例对象在创建过程中初始化接口的过程，如下所示：

InterfaceList::InterfaceList() {
  ......

  // Register the API factories for each of the API types. This calls AddProxy
  // for each InterfaceProxy type we support.
  #define PROXIED_API(api_name) \
      AddProxy(PROXY_API_ID(api_name), &PROXY_FACTORY_NAME(api_name));
  ......

  #define PROXIED_IFACE(iface_str, iface_struct) \
      AddPPB(iface_str, \
             INTERFACE_THUNK_NAME(iface_struct)(), \
             current_required_permission);
  ......

  {
    Permission current_required_permission = PERMISSION_NONE;
    ......
    #include "ppapi/thunk/interfaces_ppb_public_stable.h"
  }

  AddProxy(API_ID_RESOURCE_CREATION, &ResourceCreationProxy::Create);
  ......
  AddPPB(PPB_CORE_INTERFACE_1_0,
         PPB_Core_Proxy::GetPPB_Core_Interface(), PERMISSION_NONE);
  ......
  AddPPB(PPB_OPENGLES2_INTERFACE_1_0,
         PPB_OpenGLES2_Shared::GetInterface(), PERMISSION_NONE);
  ......
  AddProxy(API_ID_PPP_INSTANCE, &ProxyFactory<PPP_Instance_Proxy>);  

  ......
}

这个函数定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

Chromium提供给Plugin使用的接口很多，这里我们只关注特定的几个接口。这几个接口与接下来我们分析Plugin Instance的创建以及Plugin的3D渲染有关。

第一个接口是一个Instance通信接口，接口ID为API_ID_PPB_INSTANCE。当Plugin进程中的Plugin Instance要与Render进程中对应的Plugin Instance通信时，就需要调用到该接口。这个接口是通过include文件interfaces_ppb_public_stable.h定义的，如下所示：

PROXIED_API(PPB_Instance);

这个接口定义在文件external/chromium_org/ppapi/thunk/interfaces_ppb_public_stable.h中。

PROXIED_API是一个宏，定义在前面分析的InterfaceList类的构造函数中，展开后为：

AddProxy(PROXY_API_ID(PPB_Instance), &PROXY_FACTORY_NAME(PPB_Instance));

PROXY_API_ID是一个宏，定义在为：

#define PROXY_API_ID(api_name) PROXY_CLASS_NAME(api_name)::kApiID

这个宏定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

PROXY_FACTORY_NAME也是一个宏，定义为：

#define PROXY_FACTORY_NAME(api_name) ProxyFactory<PROXY_CLASS_NAME(api_name)>

这个宏定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

对PROXY_API_ID和PROXY_FACTORY_NAME这两个宏进行展开，得到接口API_ID_PPB_INSTANCE的定义为：

AddProxy(PROXY_CLASS_NAME(PPB_Instance)::kApiID, &ProxyFactory<PROXY_CLASS_NAME(PPB_Instance)>)

PROXY_CLASS_NAME是一个宏，定义为：

#define PROXY_CLASS_NAME(api_name) api_name##_Proxy

这个宏定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

对PROXY_CLASS_NAME这个宏进行展开，得到接口API_ID_PPB_INSTANCE的定义为：

AddProxy(PPB_Instance_Proxy::kApiID, &ProxyFactory<PPB_Instance_Proxy>);

PPB_Instance_Proxy::kApiID定义在PPB_Instance_Proxy类内部的一个常量，如下所示：

class PPB_Instance_Proxy : public InterfaceProxy,
                           public PPB_Instance_Shared {
  ......

  static const ApiID kApiID = API_ID_PPB_INSTANCE;

  ......
};

这个常量定义在文件external/chromium_org/ppapi/proxy/ppb_instance_proxy.h中。

对PPB_Instance_Proxy::kApiID进行常量替换后，得到接口API_ID_PPB_INSTANCE的定义为：

AddProxy(PPB_Instance_Proxy::kApiID, &ProxyFactory<PPB_Instance_Proxy>);

实际上就是将其定义为一个模板函数ProxyFactory<PPB_Instance_Proxy>，以后调用这个模板函数将会得到一个PPB_Instance_Proxy对象，如下所示：

template<typename ProxyClass>
InterfaceProxy* ProxyFactory(Dispatcher* dispatcher) {
  return new ProxyClass(dispatcher);
}

这个模板函数定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

注意，这时候模板参数ProxyClass指定为PPB_Instance_Proxy，因此在调用模板函数ProxyFactory<PPB_Instance_Proxy>时，将会得到一个PPB_Instance_Proxy对象。

上述模板函数ProxyFactory<PPB_Instance_Proxy>将会通过InterfaceList类的成员函数AddProxy保存在内部一个InterfaceProxy::Factory数组中，如下所示：

void InterfaceList::AddProxy(ApiID id,
                             InterfaceProxy::Factory factory) {
  ......

  int index = static_cast<int>(id);
  ......

  id_to_factory_[index] = factory;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

相当于执行了以下操作：

id_to_factory_[API_ID_PPB_INSTANCE] = &ProxyFactory<PPB_Instance_Proxy>;

这样，我们就可以知道第一个接口API_ID_PPB_INSTANCE对应的函数为ProxyFactory<PPB_Instance_Proxy>，以后调用这个接口将会得到一个PPB_Instance_Proxy对象。

第二个接口是一个3D图形接口，接口ID为PPB_GRAPHICS_3D_INTERFACE_1_0。当Plugin进行3D渲染时，就需要调用到这个接口。这个接口也是通过include文件interfaces_ppb_public_stable.h定义的，如下所示：

PROXIED_IFACE(PPB_GRAPHICS_3D_INTERFACE_1_0, PPB_Graphics3D_1_0)

这个接口定义在文件external/chromium_org/ppapi/thunk/interfaces_ppb_public_stable.h中。

PROXIED_IFACE是一个宏，定义在前面分析的InterfaceList类的构造函数中，展开后为：

AddPPB(PPB_GRAPHICS_3D_INTERFACE_1_0, INTERFACE_THUNK_NAME(PPB_Graphics3D_1_0)(), PERMISSION_NONE);

INTERFACE_THUNK_NAME是一个宏，定义为：

#define INTERFACE_THUNK_NAME(iface_struct) thunk::Get##iface_struct##_Thunk

这个宏定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

对INTERFACE_THUNK_NAME这个宏进行展开，得到接口PPB_GRAPHICS_3D_INTERFACE_1_0的定义为：

AddPPB(PPB_GRAPHICS_3D_INTERFACE_1_0, thunk::GetPPB_Graphics3D_1_0_Thunk(), PERMISSION_NONE);

它会调用函数GetPPB_Graphics3D_1_0_Thunk获得一个PPB_Graphics3D_1_0对象，如下所示：

const PPB_Graphics3D_1_0 g_ppb_graphics3d_thunk_1_0 = {
  &GetAttribMaxValue,
  &Create,
  &IsGraphics3D,
  &GetAttribs,
  &SetAttribs,
  &GetError,
  &ResizeBuffers,
  &SwapBuffers
};

......

PPAPI_THUNK_EXPORT const PPB_Graphics3D_1_0* GetPPB_Graphics3D_1_0_Thunk() {
  return &g_ppb_graphics3d_thunk_1_0;
}

这个函数定义在文件external/chromium_org/ppapi/thunk/ppb_graphics_3d_thunk.cc中。

从这里我们就可以看到，接口PPB_GRAPHICS_3D_INTERFACE_1_0提供给Plugin使用的函数，例如函数SwapBuffers，是Plugin执行3D渲染时用到的，用来实现eglSwapBuffers的功能。

上述获得的PPB_Graphics3D_1_0对象将会通过InterfaceList类的成员函数AddPPB保存在内部一个std::map中，如下所示：

void InterfaceList::AddPPB(const char* name,
                           const void* iface,
                           Permission perm) {
  ......
  name_to_browser_info_[name] = InterfaceInfo(iface, perm);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

相当于执行了以下操作：

name_to_browser_info_[PPB_GRAPHICS_3D_INTERFACE_1_0] = InterfaceInfo(g_ppb_graphics3d_thunk_1_0, PERMISSION_NONE);

这样，我们就可以知道第二个接口PPB_GRAPHICS_3D_INTERFACE_1_0对应的是一个PPB_Graphics3D_1_0对象，以后调用这个接口将会执行该PPB_Graphics3D_1_0对象提供的相应函数。

第三个接口是一个Plugin Instance相关的接口，接口ID为PPB_INSTANCE_INTERFACE_1_0,。当Plugin进行3D渲染时，就需要调用到这个接口来执行一个OpenGL上下文绑定操作。这个接口也是通过include文件interfaces_ppb_public_stable.h定义的，如下所示：

PROXIED_IFACE(PPB_INSTANCE_INTERFACE_1_0, PPB_Instance_1_0)

这个接口定义在文件external/chromium_org/ppapi/thunk/interfaces_ppb_public_stable.h中。

从这里可以看出，接口PPB_INSTANCE_INTERFACE_1_0与接口PPB_GRAPHICS_3D_INTERFACE_1_0一样，都是通过宏PROXIED_IFACE定义的。因此我们就可以容易知道，接口PPB_INSTANCE_INTERFACE_1_0是通过一个PPB_Instance_1_0对象实现的。这个PPB_Instance_1_0对象可以通过调用函数GetPPB_Instance_1_0_Thunk获得，如下所示：

const PPB_Instance_1_0 g_ppb_instance_thunk_1_0 = {
  &BindGraphics,
  &IsFullFrame
};

......

PPAPI_THUNK_EXPORT const PPB_Instance_1_0* GetPPB_Instance_1_0_Thunk() {
  return &g_ppb_instance_thunk_1_0;
}

这个函数定义在文件external/chromium_org/ppapi/thunk/ppb_instance_thunk.cc中。

从这里我们就可以看到，接口PPB_INSTANCE_INTERFACE_1_0提供给Plugin使用的函数，例如函数BindGraphics，就是用来给一个Plugin Instance绑定OpenGL上下文的。

第四个接口是一个资源创建接口，接口ID为API_ID_RESOURCE_CREATION。Plugin进行3D渲染之前，需要请求Chromium为其创建一个3D上下文。3D上下文是一个资源对象，这时候就需要调用到这个接口进行创建。这个接口是通过调用前面分析的InterfaceList类的成员函数AddProxy定义的，即：

AddProxy(API_ID_RESOURCE_CREATION, &ResourceCreationProxy::Create);

相当于执行了以下操作：

id_to_factory_[API_ID_RESOURCE_CREATION] = &ResourceCreationProxy::Create;

这样，我们就可以知道第三个接口API_ID_RESOURCE_CREATION对应的函数是ResourceCreationProxy类的静态成员函数Create，以后调用这个接口就会调用到ResourceCreationProxy类的静态成员函数Create。

第五个接口提供给Plugin用来获取当前时间以及对资源进行管理等，接口ID为PPB_CORE_INTERFACE_1_0。这个接口是通过调用前面分析的InterfaceList类的成员函数AddPPB定义的，即：

AddPPB(PPB_CORE_INTERFACE_1_0, PPB_Core_Proxy::GetPPB_Core_Interface(), PERMISSION_NONE);

它会调用PPB_Core_Proxy类的静态成员函数GetPPB_Core_Interface获得一个PPB_Core对象，如下所示：

const PPB_Core core_interface = {
  &AddRefResource,
  &ReleaseResource,
  &GetTime,
  &GetTimeTicks,
  &CallOnMainThread,
  &IsMainThread
};

......

const PPB_Core* PPB_Core_Proxy::GetPPB_Core_Interface() {
  return &core_interface;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_core_proxy.cc中。

从这里我们就可以看到，接口PPB_CORE_INTERFACE_1_0提供给Plugin使用的函数，例如函数GetTime，用来获得当前的时间。

上述获得的PPB_Core对象将会通过前面分析的InterfaceList类的成员函数AddPPB保存在内部一个std::map中，即：

name_to_browser_info_[PPB_CORE_INTERFACE_1_0] = InterfaceInfo(core_interface, PERMISSION_NONE);

第六个接口提供给Plugin执行OpenGL函数，接口ID为PPB_OPENGLES2_INTERFACE_1_0。这个接口是通过调用前面分析的InterfaceList类的成员函数AddPPB定义的，即：

AddPPB(PPB_OPENGLES2_INTERFACE_1_0, PPB_OpenGLES2_Shared::GetInterface(), PERMISSION_NONE);

它会调用PPB_OpenGLES2_Shared类的静态成员函数Get_Interface获得一个PPB_OpenGLES2对象，如下所示：

const PPB_OpenGLES2* PPB_OpenGLES2_Shared::GetInterface() {
  static const struct PPB_OpenGLES2 ppb_opengles2 = {
      &ActiveTexture,                       &AttachShader,
      &BindAttribLocation,                  &BindBuffer,
      &BindFramebuffer,                     &BindRenderbuffer,
      &BindTexture,                         &BlendColor,
      &BlendEquation,                       &BlendEquationSeparate,
      &BlendFunc,                           &BlendFuncSeparate,
      &BufferData,                          &BufferSubData,
      &CheckFramebufferStatus,              &Clear,
      ......
      &UseProgram,                          &ValidateProgram,
      &VertexAttrib1f,                      &VertexAttrib1fv,
      &VertexAttrib2f,                      &VertexAttrib2fv,
      &VertexAttrib3f,                      &VertexAttrib3fv,
      &VertexAttrib4f,                      &VertexAttrib4fv,
      &VertexAttribPointer,                 &Viewport};
  return &ppb_opengles2;
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppb_opengles2_shared.cc中。

从这里我们就可以看到，接口PPB_OPENGLES2_INTERFACE_1_0提供给Plugin使用的函数，例如函数ActiveTexture，相当于就是OpenGL函数glActiveTexture。

上述获得的PPB_OpenGLES2对象将会通过前面分析的InterfaceList类的成员函数AddPPB保存在内部一个std::map中，即：

name_to_browser_info_[PPB_OPENGLES2_INTERFACE_1_0] = InterfaceInfo(ppb_opengles2, PERMISSION_NONE);

第七个接口是一个Plugin Instance通信接口，接口ID为API_ID_PPP_INSTANCE。通过这个接口，Render进程中的Plugin Instance可以它在Plugin进行中对应的Plugin Instance进行通信。这个接口是通过调用前面分析的InterfaceList类的成员函数AddProxy定义的，即：

AddProxy(API_ID_PPP_INSTANCE, &ProxyFactory<PPP_Instance_Proxy>);

从前面的分析可以知道，函数ProxyFactory<PPP_Instance_Proxy>是一个模板函数，当这个函数被调用的时候，将会返回一个PPP_Instance_Proxy对象。

上述模板函数ProxyFactory<PPP_Instance_Proxy>将会通过前面分析的InterfaceList类的成员函数AddProxy保存在内部一个InterfaceProxy::Factory数组中，即：

id_to_factory_[API_ID_PPP_INSTANCE] = ProxyFactory<PPP_Instance_Proxy>;

这样，我们就可以知道接口API_ID_PPP_INSTANCE对应的函数为ProxyFactory<PPB_Instance_Proxy>，以后调用这个接口将会得到一个PPP_Instance_Proxy对象。

这一步执行完成后，Plugin进程中的InterfaceList单例对象就在创建过程中初始化好了一系列的接口。这些接口可以被Plugin调用，用来与Chromium交互。其中，我们重点分析了以下七个接口的定义：

1. API_ID_PPB_INSTANCE

2. PPB_GRAPHICS_3D_INTERFACE_1_0

3. PPB_INSTANCE_INTERFACE_1_0

4. API_ID_RESOURCE_CREATION

5. PPB_CORE_INTERFACE_1_0

6. PPB_OPENGLES2_INTERFACE_1_0

7. API_ID_PPP_INSTANCE

在接下来的两篇文章中，我们会看到这些接口的详细调用过程。通过这些调用过程，我们就会对Chromium的Plugin机制会更深刻的认识。

现在回到前面分析的PluginDispatcher类的静态成员函数GetBrowserInterface，这时候它通过调用Plugin进程中的InterfaceList单例对象的成员函数GetInterfaceForPPB获得一个类型为PPB_CORE_INTERFACE的接口，如下所示：

const void* InterfaceList::GetInterfaceForPPB(const std::string& name) {
  NameToInterfaceInfoMap::iterator found =
      name_to_browser_info_.find(name);
  if (found == name_to_browser_info_.end())
    return NULL;

  if (g_process_global_permissions.Get().HasPermission(
          found->second.required_permission)) {
    ......
    return found->second.iface;
  }
  return NULL;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

InterfaceList类的成员函数GetInterfaceForPPB首先在成员变量name_to_browser_info_描述的一个std::map检查是否存在一个类型为name的接口。如果存在，那么会继续检查当前进程是否具有该接口的使用权限。只有在具有权限的情况下，前面查找到的接口才会返回给调用者。

在我们这个情景中，要获得的接口是PPB_CORE_INTERFACE。接口PPB_CORE_INTERFACE与前面我们分析的PPB_CORE_INTERFACE_1_0是一样的，这一点可以参考以下宏定义：

#define PPB_CORE_INTERFACE_1_0 "PPB_Core;1.0"
#define PPB_CORE_INTERFACE PPB_CORE_INTERFACE_1_0

这两个宏定义在文件external/chromium_org/ppapi/c/ppb_core.h中。

由于接口PPB_CORE_INTERFACE_1_0已经存在成员变量name_to_browser_info_描述的std::map中，并且它的使用权限为PERMISSION_NONE，即不需要请求权限，因此，InterfaceList类的成员函数GetInterfaceForPPB将会返回该接口给最初的调用者，即pp::Module类的成员函数InternalInit。后者获得这个接口后，会将其封装在一个Core对象中，并且将该Core对象保存在pp::Module类的成员变量core_中。

InterfaceList类还提供了另外一个成员函数GetFactoryForID，用来获得前面我们分析的那些保存在其成员变量id_to_factory_描述的InterfaceProxy::Factory数组中的接口，如下所示：

InterfaceProxy::Factory InterfaceList::GetFactoryForID(ApiID id) const {
  int index = static_cast<int>(id);
  COMPILE_ASSERT(API_ID_NONE == 0, none_must_be_zero);
  if (id <= 0 || id >= API_ID_COUNT)
    return NULL;
  return id_to_factory_[index];
}

这个函数定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

这意味着Plugin可以通过调用InterfaceList类的成员函数GetInterfaceForPPB和GetFactoryForID获得Chromium提供给它们的调用接口，也就是Chromium提供给Plugin的API。有了这些API之后，Plugin就可以完成自己的功能了。

至此，我们就分析完成了Plugin Module的加载过程和初始化过程。其中，加载过程的更详细分析可以参考前面Chromium的Plugin进程启动过程分析一文，初始化过程主要就是定义了一系列Plugin可以调用的API接口。在接下来的两篇文章中，我们将会逐步看到这些接口的调用过程。敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/10/31 0:59:29 原文链接

阅读：48487 评论：3 查看评论

↧

Chromium插件（Plugin）实例（Instance）创建过程分析

November 7, 2016, 12:59 am

≫ Next: Chromium插件（Plugin）执行3D渲染的过程分析

≪ Previous: Chromium插件（Plugin）模块（Module）加载过程分析

Chromium在解析网页时，每遇到一个<embed>标签，就会创建一个Plugin Instance。一般来说，Plugin Instance是在Plugin进程中创建和运行的。一个Plugin Module对应一个Plugin进程，同时可以创建多个不同的Plugin Instance。前面我们已经分析Plugin Module的加载过程了，本文继续分析Plugin Instance的创建过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

Plugin Instance在运行的过程中，需要调用Chromium提供的API。这些API是实现在Render进程中的。与此同时，Render进程也需要主动与Plugin Instance通信，例如当网页的<embed>标签发生变化时，需要向它对应的Plugin Instance发出通知。为了方便Plugin Instance与Render进程相互通信，每一个Plugin Instance在Render进程中都对应有一个Proxy。这些Proxy通过PepperPluginInstanceImpl类描述。

Plugin Instance的创建是由运行在Render进程中的WebKit发起的。WebKit又是通过请求Chromium的Content层创建Plugin Instance的。Content层在创建Plugin Instance之前，先会检查它对应的Plugin Module是否已经加载。如果还没有加载，那么就会先加载。这个加载过程可以参考前面Chromium插件（Plugin）模块（Module）加载过程分析一文。接下来，Content层又会创建一个Plugin Instance Proxy，即一个PepperPluginInstanceImpl对象，然后再通过个PepperPluginInstanceImpl对象请求在相应的Plugin进程中创建一个Plugin Instance。这个过程如图1所示：

图1 Plugin Instance的创建过程

在PepperPluginInstanceImpl对象的创建这程中，会初始化一系列的接口。以后PepperPluginInstanceImpl对象就是通这些接口与运行在Plugin进程的Plugin Instance通信的。其中的一个接口在创建Plugin Instance的过程中也会用到。这个接口称为PPP_INSTANCE_INTERFACE_1_1，它提供了一个DidCreate函数。通过这个函数，PepperPluginInstanceImpl对象就可以请求在指定的Plugin进程中创建一个Plugin Instance。

接口PPP_INSTANCE_INTERFACE_1_1提供的函数DidCreate会向Plugin进程发送一个类型为PpapiMsg_PPPInstance_DidCreate的IPC消息。这个IPC消息携带了一个参数API_ID_INSTANCE，表示该消息是分发给一个PPP_Instance_Proxy对象处理。这个PPP_Instance_Proxy对象又会在Plugin进程中获得一个PPP_INSTANCE_INTERFACE_1_1接口，并且调用该接品提供的函数DidCreate。后者在执行的过程中，就会创建一个pp::Instance对象。这个pp::Instance对象就是用来在Plugin对象中描述一个Plugin Instance的。

从前面Chromium的GPU进程启动过程分析和Chromium插件（Plugin）模块（Module）加载过程分析这两篇文章可以知道，WebKit请求Chromium的Content层为<embed>标签创建了一个PepperWebPluginImpl对象之后，就会调用这个PepperWebPluginImpl对象的成员函数initialize执行初始化工作。在初始化的过程中，就会创建Plugin Instance。因此，接下来我们就从PepperWebPluginImpl类的成员函数initialize开始，分析在Plugin Instance的创建过程.

PepperWebPluginImpl类的成员函数initialize的实现如下所示：

bool PepperWebPluginImpl::initialize(WebPluginContainer* container) {
  // The plugin delegate may have gone away.
  instance_ = init_data_->module->CreateInstance(
      init_data_->render_frame, container, init_data_->url);
  ......

  bool success = instance_->Initialize(
      init_data_->arg_names, init_data_->arg_values, full_frame_);
  ......

  return true;
}

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

PepperWebPluginImpl类的成员变量init_data_指向的是一个InitData对象。这个InitData对象的成员变量module指向的是一个PluginModule对象。这个PluginModule对象用来在Render进程中描述一个Plugin Module，它的创建过程可以参考前面Chromium的GPU进程启动过程分析一文。

有了上述PluginModule对象之后，PepperWebPluginImpl类的成员函数initialize就可以调用它的成员函数CreateInstance创建一个Plugin Instance Proxy，即一个PepperPluginInstanceImpl对象，并且接下来会调用这个PepperPluginInstanceImpl对象的成员函数Initialize执行进行初始化工作。在初始化的过程中，就会请求Plugin进程创建一个Plugin Instance。

接下来我们先分析Plugin Instance Proxy的创建这程，也就是PluginModule类的成员函数CreateInstance的实现，如下所示：

PepperPluginInstanceImpl* PluginModule::CreateInstance(
    RenderFrameImpl* render_frame,
    blink::WebPluginContainer* container,
    const GURL& plugin_url) {
  PepperPluginInstanceImpl* instance = PepperPluginInstanceImpl::Create(
      render_frame, this, container, plugin_url);
  ......
  return instance;
}

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

PluginModule类的成员函数CreateInstance通过调用PepperPluginInstanceImpl类的静态成员函数Create创建一个PepperPluginInstanceImpl对象，如下所示：

PepperPluginInstanceImpl* PepperPluginInstanceImpl::Create(
    RenderFrameImpl* render_frame,
    PluginModule* module,
    WebPluginContainer* container,
    const GURL& plugin_url) {
  base::Callback<const void*(const char*)> get_plugin_interface_func =
      base::Bind(&PluginModule::GetPluginInterface, module);
  PPP_Instance_Combined* ppp_instance_combined =
      PPP_Instance_Combined::Create(get_plugin_interface_func);
  if (!ppp_instance_combined)
    return NULL;
  return new PepperPluginInstanceImpl(
      render_frame, module, ppp_instance_combined, container, plugin_url);
}

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

PepperPluginInstanceImpl类的静态成员函数Create首先是将PluginModule类的成员函数GetPluginInterface封装在一个Callback中，然后再将这个Callback传递给PPP_Instance_Combined类的静态成员函数Create，用来创建一个PPP_Instance_Combined对象。有了这个PPP_Instance_Combined对象之后，就可以创建一个PepperPluginInstanceImpl对象了。

接下来，我们首先分析上述PPP_Instance_Combined对象的创建过程，也就是PPP_Instance_Combined类的静态成员函数Create的实现，如下所示：

PPP_Instance_Combined* PPP_Instance_Combined::Create(
    base::Callback<const void*(const char*)> get_interface_func) {
  // Try 1.1.
  const void* ppp_instance = get_interface_func.Run(PPP_INSTANCE_INTERFACE_1_1);
  if (ppp_instance) {
    const PPP_Instance_1_1* ppp_instance_1_1 =
        static_cast<const PPP_Instance_1_1*>(ppp_instance);
    return new PPP_Instance_Combined(*ppp_instance_1_1);
  }
  // Failing that, try 1.0.
  ppp_instance = get_interface_func.Run(PPP_INSTANCE_INTERFACE_1_0);
  if (ppp_instance) {
    const PPP_Instance_1_0* ppp_instance_1_0 =
        static_cast<const PPP_Instance_1_0*>(ppp_instance);
    return new PPP_Instance_Combined(*ppp_instance_1_0);
  }
  // No supported PPP_Instance version found.
  return NULL;
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppp_instance_combined.cc中。

PPP_Instance_Combined类的静态成员函数Create首先尝试通过参数get_interface_func描述的Callback获得一个1.1版本的PPP_INSTANCE_INTERFACE接口。如果能成功获得该接口，那么就使用它来创建一个PPP_Instance_Combined对象返回给调用者。

如果不能成功获得1.1版本的PPP_INSTANCE_INTERFACE接口，那么PPP_Instance_Combined类的静态成员函数Create接下来会尝试获得1.0版本的PPP_INSTANCE_INTERFACE接口。如果能成功获得该接口，那么同样会使用它来创建一个PPP_Instance_Combined对象返回给调用者。

我们假设1.1版本的PPP_INSTANCE_INTERFACE接口能够成功获取，接下来我们就分析它的获得过程。从前面的分析可以知道，参数get_interface_func描述的Callback描述的实际上是PluginModule类的成员函数GetPluginInterface，因此，1.1版本的PPP_INSTANCE_INTERFACE接口实际上是通过调用PluginModule类的成员函数GetPluginInterface获得的，如下所示：

const void* PluginModule::GetPluginInterface(const char* name) const {
  if (host_dispatcher_wrapper_)
    return host_dispatcher_wrapper_->GetProxiedInterface(name);

  ......
}

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

PluginModule类的成员变量host_dispatcher_wrapper_指向的是一个HostDispatcherWrapper对象。这个HostDispatcherWrapper对象是在Plugin Module加载的过程中创建的，它内部封装了一个HostDispatcher对象，通过这个HostDispatcher对象可以与Plugin Module所加载在的Plugin进程通信。

有了上述HostDispatcherWrapper对象之后，PluginModule类的成员函数GetPluginInterface就可以调用它的成员函数GetProxiedInterface获得版本为PPP_INSTANCE_INTERFACE接口，即PPP_INSTANCE_INTERFACE_1_1接口，如下所示：

const void* HostDispatcherWrapper::GetProxiedInterface(const char* name) {
  return dispatcher_->GetProxiedInterface(name);
}

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

HostDispatcherWrapper类的成员变量dispatcher_指向的就是一个HostDispacther对象。HostDispatcherWrapper类的成员函数GetProxiedInterface通过调用这个HostDispacther对象的成员函数GetProxiedInterface获得PPP_INSTANCE_INTERFACE_1_1接口，如下所示：

const void* HostDispatcher::GetProxiedInterface(const std::string& iface_name) {
  const void* proxied_interface =
      InterfaceList::GetInstance()->GetInterfaceForPPP(iface_name);
  if (!proxied_interface)
    return NULL;  // Don't have a proxy for this interface, don't query further.

  PluginSupportedMap::iterator iter(plugin_supported_.find(iface_name));
  if (iter == plugin_supported_.end()) {
    // Need to query. Cache the result so we only do this once.
    bool supported = false;

    bool previous_reentrancy_value = allow_plugin_reentrancy_;
    allow_plugin_reentrancy_ = true;
    Send(new PpapiMsg_SupportsInterface(iface_name, &supported));
    allow_plugin_reentrancy_ = previous_reentrancy_value;

    std::pair<PluginSupportedMap::iterator, bool> iter_success_pair;
    iter_success_pair = plugin_supported_.insert(
        PluginSupportedMap::value_type(iface_name, supported));
    iter = iter_success_pair.first;
  }
  if (iter->second)
    return proxied_interface;
  return NULL;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/host_dispatcher.cc中。

从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，Plugin进程中存在一个InterfaceList单例对象。这个InterfaceList单例对象在创建的过程中，会初始化一系列的接口。这些接口是提供给Plugin Instance调用的，以便Plugin Instance可以与它们在Render进程中的Proxy进行通信。

同样，在Render进程中，也存在一个InterfaceList单例对象。这个InterfaceList单例对象在创建的过程中，也会初始化一系列的接口，不过这些接口是提供给Plugin Instance Proxy调用的，以便Plugin Instance Proxy可以与它们在Plugin进程中的Plugin Instance进行通信。

HostDispacther对象的成员函数GetProxiedInterface所做的事情就是检查Render进程中的InterfaceList单例对象是否提供了PPP_INSTANCE_INTERFACE_1_1接口。如果有提供，并且Plugin进程支持该接口，那么就会将它返回给调用者。注意，检查Plugin进程是否支持某个接口，是通过向它发送一个类型为PpapiMsg_SupportsInterface的IPC消息实现的。这里我们假设Plugin进程支持PPP_INSTANCE_INTERFACE_1_1接口。

接下来我们先分析Render进程中的InterfaceList单例对象在创建过程中提供的三个Plugin Instance Proxy可以调用的接口，它们在接下来一篇文章分析Plugin Instance的3D渲染过程时将会使用到，如下所示：

InterfaceList::InterfaceList() {
  memset(id_to_factory_, 0, sizeof(id_to_factory_));

  // Register the API factories for each of the API types. This calls AddProxy
  // for each InterfaceProxy type we support.
  #define PROXIED_API(api_name) \
      AddProxy(PROXY_API_ID(api_name), &PROXY_FACTORY_NAME(api_name));

  // Register each proxied interface by calling AddPPB for each supported
  // interface. Set current_required_permission to the appropriate value for
  // the value you want expanded by this macro.
  #define PROXIED_IFACE(iface_str, iface_struct) \
      AddPPB(iface_str, \
             INTERFACE_THUNK_NAME(iface_struct)(), \
             current_required_permission);

  {
    Permission current_required_permission = PERMISSION_NONE;
    ......
    #include "ppapi/thunk/interfaces_ppb_public_stable.h"
  }

  ......

  AddPPP(PPP_INSTANCE_INTERFACE_1_1,
         PPP_Instance_Proxy::GetInstanceInterface());

  ......
}

这个函数定义在文件external/chromium_org/ppapi/proxy/interface_list.cc。

这三个接口分别是API_ID_PPB_INSTANCE、API_ID_PPB_GRAPHICS_3D和PPP_INSTANCE_INTERFACE_1_1。其中，API_ID_PPB_INSTANCE和API_ID_PPB_GRAPHICS_3D这两个接口是通过include文件interfaces_ppb_public_stable.h进行定义的，如下所示：

PROXIED_API(PPB_Graphics3D)
......
PROXIED_API(PPB_Instance)

这两个接口定义在文件external/chromium_org/ppapi/thunk/interfaces_ppb_public_stable.h中。

其中，接口API_ID_PPB_INSTANCE由语句PROXIED_API(PPB_Instance)定义。我们在前面Chromium插件（Plugin）模块（Module）加载过程分析一文已经分析过这个接口的定义了，因此这里不再复述。实现这个接口的是一个模板函数ProxyFactory<PPB_Instance_Proxy>。以后调用这个接口就相当于调用模板函数ProxyFactory<PPB_Instance_Proxy>，并且会在调用后得到一个PPB_Instance_Proxy对象。

接口API_ID_PPB_GRAPHICS_3D由语句PROXIED_API(PPB_Graphics3D)定义。它的定义过程与接口API_ID_PPB_INSTANCE是一样的，因此，我们容易知道，实现这个接口的是另外一个模板函数ProxyFactory<PPB_Graphics3D_Proxy>。以后调用这个接口就相当于调用模板函数ProxyFactory<PPB_Graphics3D_Proxy>，并且会在调用后得到一个PPB_Graphics3D_Proxy对象。

回到InterfaceList类的构造函数中，第三个接口PPP_INSTANCE_INTERFACE_1_1是由一个PPP_Instance_1_1对象实现的。这个PPP_Instance_1_1对象可以通过调用PPP_Instance_Proxy类的静态成员函数GetInstanceInterface获得，如下所示：

static const PPP_Instance_1_1 instance_interface = {
  &DidCreate,
  &DidDestroy,
  &DidChangeView,
  &DidChangeFocus,
  &HandleDocumentLoad
};

......

const PPP_Instance* PPP_Instance_Proxy::GetInstanceInterface() {
  return &instance_interface;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppp_instance_proxy.cc中。

从这里我们就可以看到，接口PPP_INSTANCE_INTERFACE_1_1提供给Plugin Instance Proxy使用的函数，例如函数DidCreate，是用来请求Plugin进程创建一个Plugin Instance的，接下来我们就会看到这个函数的使用过程。

分析到这里，我们就可以知道，HostDispacther类的成员函数GetProxiedInterface通过调用Render进程中的InterfaceList单例对象的成员函数GetInterfaceForPPP是可以获得PPP_INSTANCE_INTERFACE_1_1接口的。这个接口会沿着调用过程返回给PPP_Instance_Combined类的静态成员函数Create。

PPP_Instance_Combined类的静态成员函数Create获得了PPP_INSTANCE_INTERFACE_1_1接口之后，就会使用它来创建一个PPP_Instance_Combined对象，如下所示：

PPP_Instance_Combined::PPP_Instance_Combined(
    const PPP_Instance_1_1& instance_if)
    : instance_1_1_(instance_if), did_change_view_1_0_(NULL) {}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppp_instance_combined.cc中。

参数instance_if描述的就是前面获得的PPP_INSTANCE_INTERFACE_1_1接口。这个接口实际上是一个PPP_Instance_1_1对象。这个PPP_Instance_1_1对象将会保存在PPP_Instance_Combined类的成员变量instance_1_1_中。

这一步执行完成后，我们就获得了一个PPP_Instance_Combined对象。这个PPP_Instance_Combined对象将会返回给前面分析的PepperPluginInstanceImpl类的静态成员函数Create，后者将会使用前者创建一个PepperPluginInstanceImpl对象。这个PepperPluginInstanceImpl对象的创建过程如下所示：

PepperPluginInstanceImpl::PepperPluginInstanceImpl(
    RenderFrameImpl* render_frame,
    PluginModule* module,
    ppapi::PPP_Instance_Combined* instance_interface,
    WebPluginContainer* container,
    const GURL& plugin_url)
    : ......,
      module_(module),
      instance_interface_(instance_interface),
      ...... {
  ......

  RendererPpapiHostImpl* host_impl = module_->renderer_ppapi_host();
  resource_creation_ = host_impl->CreateInProcessResourceCreationAPI(this);

  ......
}

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

PepperPluginInstanceImpl类的构造函数首先将参数module和instance_interface指向的PluginModule对象和PPP_Instance_Combined对象分别保存在成员变量module_和instance_interface_，接下来又会通过参数module指向的PluginModule对象获得一个RendererPpapiHostImpl对象。这个RendererPpapiHostImpl对象是用来在Render进程中描述一个Plugin进程的，它是在Plugin Module的加载过程中创建的，具体可以参考前面Chromium的Plugin进程启动过程分析一文。有了这个RendererPpapiHostImpl对象之后，PepperPluginInstanceImpl类的构造函数就调用它的成员函数CreateInProcessResourceCreationAPI创建一个资源创建接口，如下所示：

scoped_ptr<ppapi::thunk::ResourceCreationAPI>
RendererPpapiHostImpl::CreateInProcessResourceCreationAPI(
    PepperPluginInstanceImpl* instance) {
  return scoped_ptr<ppapi::thunk::ResourceCreationAPI>(
      new PepperInProcessResourceCreation(this, instance));
}

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

从这里可以看到，这个资源创建接口是通过一个PepperInProcessResourceCreation对象描述的。这个PepperInProcessResourceCreation对象返回给PepperPluginInstanceImpl类的构造函数之后，将会保存在后者的成员变量resource_creation_中。在接下来一篇文章分析Plugin的3D渲染过程时，我们就会看到这个接口的使用过程。

这一步执行完成后，回到PepperWebPluginImpl类的成员函数initialize中，这时候它就创建了一个Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象。接下来PepperWebPluginImpl类的成员函数initialize又会调用上述PepperPluginInstanceImpl对象的成员函数Initialize对其进行初始化。在初始化的过程中，就会请求目标Plugin进程创建一个Plugin Instance，如下所示：

bool PepperPluginInstanceImpl::Initialize(
    const std::vector<std::string>& arg_names,
    const std::vector<std::string>& arg_values,
    bool full_frame) {
  ......

  argn_ = arg_names;
  argv_ = arg_values;
  scoped_ptr<const char * []> argn_array(StringVectorToArgArray(argn_));
  scoped_ptr<const char * []> argv_array(StringVectorToArgArray(argv_));
  bool success = PP_ToBool(instance_interface_->DidCreate(
      pp_instance(), argn_.size(), argn_array.get(), argv_array.get()));
  ......

  return success;
}

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

从前面的分析可以知道，PepperPluginInstanceImpl类的成员变量instance_interface_指向的是一个PPP_Instance_Combined对象。PepperPluginInstanceImpl类的成员函数Initialize主要是调用这个PPP_Instance_Combined对象的成员函数DidCreate请求在目标Plugin进程中创建一个Plugin Instance，如下所示：

PP_Bool PPP_Instance_Combined::DidCreate(PP_Instance instance,
                                         uint32_t argc,
                                         const char* argn[],
                                         const char* argv[]) {
  return CallWhileUnlocked(instance_1_1_.DidCreate, instance, argc, argn, argv);
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppp_instance_combined.cc中。

从前面的分析可以知道，PPP_Instance_Combined类的成员变量instance_1_1_指向的是一个PPP_Instance_1_1对象。这个PPP_Instance_1_1对象描述的是一个PPP_INSTANCE_INTERFACE_1_1接口。PPP_Instance_Combined类的成员函数DidCreate通过一个帮助函数CallWhilleUnlocked调用这个PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidCreate，以便请求目标Plugin进程创建一个Plugin Instance。

从前面的分析还可以知道，上述PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidCreate实现在ppp_instance_proxy.cc文件中，如下所示：

PP_Bool DidCreate(PP_Instance instance,
                  uint32_t argc,
                  const char* argn[],
                  const char* argv[]) {
  std::vector<std::string> argn_vect;
  std::vector<std::string> argv_vect;
  for (uint32_t i = 0; i < argc; i++) {
    argn_vect.push_back(std::string(argn[i]));
    argv_vect.push_back(std::string(argv[i]));
  }

  PP_Bool result = PP_FALSE;
  HostDispatcher::GetForInstance(instance)->Send(
      new PpapiMsg_PPPInstance_DidCreate(API_ID_PPP_INSTANCE, instance,
                                         argn_vect, argv_vect, &result));
  return result;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppp_instance_proxy.cc中。

函数DidCreate主要就是向目标Plugin进程发送一个类型为PpapiMsg_PPPInstance_DidCreate的IPC消息。这个IPC消息的Routing ID指定为API_ID_PPP_INSTANCE，表示它发送到目标Plugin进程后，要交给一个ID为API_ID_PPP_INSTANCE的PPAPI接口处理。

目标Plugin进程可以通过参数instance描述的一个PP_Instance对象获得。在Render进程中，每一个Plugin Instance Proxy都关联有一个PP_Instance对象。因此，通过这个PP_Instance对象就可以找到它对应的Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象。每一个PepperPluginInstanceImpl对象又对应有一个Plugin Moudle。该Plugin Module所加载在的Plugin进程即为目标进程。知道了目标Plugin进程之后，就可以通过之前它在启动时与Render进程建立的Plugin通道向它发送IPC消息了。

从前面Chromium的Plugin进程启动过程分析一文可以知道，每一个Plugin进程都存在一个PluginDispatcher对象。Plugin进程将会通过这个PluginDispatcher对象的成员函数OnMessageReceived接收Render进程发送过来的IPC消息。这意味着前面从Render进程发送过来的类型为PpapiMsg_PPPInstance_DidCreate的IPC消息是通过PluginDispatcher类的成员函数OnMessageReceived接收的。

PluginDispatcher类的成员函数OnMessageReceived是从父类Dispatcher继承下来的，它的实现如下所示：

bool Dispatcher::OnMessageReceived(const IPC::Message& msg) {
  ......

  InterfaceProxy* proxy = GetInterfaceProxy(
      static_cast<ApiID>(msg.routing_id()));
  ......

  return proxy->OnMessageReceived(msg);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/dispatcher.cc中。

从前面的分析可以知道，此时参数msg指向的Message对象描述的是一个类型为PpapiMsg_PPPInstance_DidCreate的IPC消息，该消息的Routing ID为API_ID_PPP_INSTANCE。这个Routing ID描述的实际上是一个接口ID，Dispatcher类的成员函数OnMessageReceived通过调用另外一个成员函数GetInterfaceProxy可以获得该接口，如下所示：

InterfaceProxy* Dispatcher::GetInterfaceProxy(ApiID id) {
  InterfaceProxy* proxy = proxies_[id].get();
  if (!proxy) {
    // Handle the first time for a given API by creating the proxy for it.
    InterfaceProxy::Factory factory =
        InterfaceList::GetInstance()->GetFactoryForID(id);
    ......
    proxy = factory(this);
    DCHECK(proxy);
    proxies_[id].reset(proxy);
  }
  return proxy;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/dispatcher.cc中。

Dispatcher类的成员函数GetInterfaceProxy首先在成员变量proxies_描述的数组中检查是否存在一个与ID为参数id的接口。如果存在，那么就直接将它返回给调用者。如果不存在，那么就会通过调用Plugin进程中的一个InterfaceList单例对象的成员函数GetFactoryForID检查它内部是否存在该接口。如果存在，那么就会获得一个类型为InterfaceProxy::Factory的函数。调用该函数将会获得一个InterfaceProxy对象。这个InterfaceProxy对象描述的就是一个ID为参数id的接口。

Dispatcher类的成员函数GetInterfaceProxy在将获得的PPAPI接口返回给调用者之前，还会将其缓存在成员变量proxies_描述的数组中，以便以后可以直接获得，而不用通过Plugin进程中的InterfaceList单例对象获得。

接下来，我们继续分析InterfaceList类的成员函数GetFactoryForID的实现，以便了解它返回的InterfaceProxy::Factory函数的实现，如下所示：

InterfaceProxy::Factory InterfaceList::GetFactoryForID(ApiID id) const {
  int index = static_cast<int>(id);
  ......
  return id_to_factory_[index];
}

这个函数定义在文件external/chromium_org/ppapi/proxy/interface_list.cc中。

从前面的分析可以知道，此时参数id的值等于API_ID_PPP_INSTANCE。从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，Plugin进程在加载Plugin Module的时候，会在InterfaceList类的成员变量id_to_factory_描述的数组中注册一个ID为API_ID_PPP_INSTANCE的模板函数ProxyFactory<PPP_Instance_Proxy>。因此，这时候InterfaceList类的成员函数GetFactoryForID将会返回模板函数ProxyFactory<PPP_Instance_Proxy>给调用者，也就是Dispatcher类的成员函数GetInterfaceProxy。

Dispatcher类的成员函数GetInterfaceProxy获得了模板函数ProxyFactory<PPP_Instance_Proxy>之后，就会调用它创建一个PPP_Instance_Proxy对象。这个PPP_Instance_Proxy对象以后就会负责处理Routing ID为API_ID_PPP_INSTANCE的IPC消息。

PPP_Instance_Proxy对象在创建的过程中，将会获得一个PPP_INSTANCE_INTERFACE_1_1接口。这个PPP_INSTANCE_INTERFACE_1_1接口在处理类型为PpapiMsg_PPPInstance_DidCreate的IPC消息的过程中将会使用到。

接下来，我们就继续分析PPP_Instance_Proxy对象的创建过程，也就是它的构造函数的实现，以便了解它获得PPP_INSTANCE_INTERFACE_1_1接口的过程，如下所示：

PPP_Instance_Proxy::PPP_Instance_Proxy(Dispatcher* dispatcher)
    : InterfaceProxy(dispatcher) {
  if (dispatcher->IsPlugin()) {
    ......
    combined_interface_.reset(PPP_Instance_Combined::Create(
        base::Bind(dispatcher->local_get_interface())));
  }
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppp_instance_proxy.cc中。

从前面的调用过程可以知道，参数dispatcher指向的实际上是一个PluginDispatcher对象。调用这个PluginDispatcher对象的成员函数isPlugin得到的返回值为true。这时候PPP_Instance_Proxy类的构造函数会继续调用这个PluginDispatcher对象的成员函数local_get_interface获得一个PPP_GetInterface接口。这个接口是从Plugin Module导出来的。它的获取过程可以参考前面Chromium的Plugin进程启动过程分析一文。

获得了从Plugin Module导出来的PPP_GetInterface接口之后，PPP_Instance_Proxy类的构造函数通过调用PPP_Instance_Combined类的静态成员函数Create将该接口封装在一个PPP_Instance_Combined对象中，如下所示：

PPP_Instance_Combined* PPP_Instance_Combined::Create(
    base::Callback<const void*(const char*)> get_interface_func) {
  // Try 1.1.
  const void* ppp_instance = get_interface_func.Run(PPP_INSTANCE_INTERFACE_1_1);
  if (ppp_instance) {
    const PPP_Instance_1_1* ppp_instance_1_1 =
        static_cast<const PPP_Instance_1_1*>(ppp_instance);
    return new PPP_Instance_Combined(*ppp_instance_1_1);
  }
  // Failing that, try 1.0.
  ppp_instance = get_interface_func.Run(PPP_INSTANCE_INTERFACE_1_0);
  if (ppp_instance) {
    const PPP_Instance_1_0* ppp_instance_1_0 =
        static_cast<const PPP_Instance_1_0*>(ppp_instance);
    return new PPP_Instance_Combined(*ppp_instance_1_0);
  }
  // No supported PPP_Instance version found.
  return NULL;
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppp_instance_combined.cc中。

前面我们已经分析过PPP_Instance_Combined类的静态成员函数Create的实现了。不过，这时候参数get_interface_func描述的是一个从Plugin Module导出来的PPP_GetInterface接口。从前面的分析可以知道，PPP_Instance_Combined类的静态成员函数Create最终会通过这个PPP_GetInterface接口获得另外一个类型为PPP_INSTANCE_INTERFACE_1_1的接口。

Plugin Module导出来的PPP_GetInterface接口的实现如下所示：

PP_EXPORT const void* PPP_GetInterface(const char* interface_name) {
  if (g_module_singleton)
    return g_module_singleton->GetPluginInterface(interface_name);
  ......
  return NULL;
}

这个函数定义在文件external/chromium_org/ppapi/cpp/ppp_entrypoints.cc中。

从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，g_module_singleton是一个全局变量，它指向的是一个pp::Module对象。这个pp::Module对象描述的就是在当前Plugin进程中加载的Plugin Module。对于我们在前面Chromium插件（Plugin）机制简要介绍和学习计划一文中提到的GLES2 Example来说，这个pp::Module对象的实际类型为GLES2DemoModule。

PPP_GetInterface接口主要就是调用上述pp::Module对象的成员函数GetPluginInterface获得与参数interface_name对应的接口。从前面的分析可以知道，此时参数interface_name的值等于PPP_INSTANCE_INTERFACE_1_1，也就是此时PPP_GetInterface接口是通过调用pp::Module类的成员函数GetPluginInterface获得PPP_INSTANCE_INTERFACE_1_1接口的，如下所示：

const void* Module::GetPluginInterface(const char* interface_name) {
  ......
  if (strcmp(interface_name, PPP_INSTANCE_INTERFACE) == 0)
    return &instance_interface;
  ......

  return NULL;
}

这个函数定义在文件external/chromium_org/ppapi/cpp/module.cc中。

PPP_INSTANCE_INTERFACE是一个宏，它的定义为：

#define PPP_INSTANCE_INTERFACE PPP_INSTANCE_INTERFACE_1_1

这个宏定义在文件external/chromium_org/ppap/c/ppp_instance.h

回到pp::Module类的成员函数GetPluginInterface中，由于此时参数interface_name的值等于PPP_INSTANCE_INTERFACE_1_1，因此这时候pp::Module类的成员函数GetPluginInterface会将全局变量instance_interface描述的一个PPP_Instance对象给调用者。这个PPP_Instance对象的定义如下所示：

static PPP_Instance instance_interface = {
  &Instance_DidCreate,
  &Instance_DidDestroy,
  &Instance_DidChangeView,
  &Instance_DidChangeFocus,
  &Instance_HandleDocumentLoad
};

这个PPP_Instance对象定义在文件external/chromium_org/ppapi/cpp/module.cc中。

从这里就可以看到，Plugin进程中的PPP_INSTANCE_INTERFACE_1_1接口的实现。例如，它的成员变量DidCreate是一个函数指针，指向的函数为Instance_DidCreate，它是用来在Plugin进程中创建一个Plugin Instance的。

这一步执行完成后，回到PPP_Instance_Combined类的静态成员函数Create中，这时候它就会将上述PPP_Instance对象封装在一个PPP_Instance_Combined对象中，并且将该PPP_Instance_Combined对象返回给调用者，即PPP_Instance_Proxy类的构造函数的实现，后者再将该PPP_Instance_Combined对象保存在成员变量combined_interface_中。

这样，我们就分析完成了Dispatcher类的成员函数GetInterfaceProxy通过模板函数ProxyFactory<PPP_Instance_Proxy>创建PPP_Instance_Proxy对象的过程。这个PPP_Instance_Proxy对象会返回给Dispatcher类的另外一个成员函数OnMessageReceived，后者会将前面从Render进程发送过来的类型为PpapiMsg_PPPInstance_DidCreate的IPC消息分发给该PPP_Instance_Proxy对象的成员函数OnMessageReceived处理，如下所示：

bool PPP_Instance_Proxy::OnMessageReceived(const IPC::Message& msg) {
  ......

  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPP_Instance_Proxy, msg)
    IPC_MESSAGE_HANDLER(PpapiMsg_PPPInstance_DidCreate,
                        OnPluginMsgDidCreate)
    ......
    IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()
  return handled;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppp_instance_proxy.cc中。

PPP_Instance_Proxy类的成员函数OnMessageReceived将类型为PpapiMsg_PPPInstance_DidCreate的IPC消息分发给成员函数OnPluginMsgDidCreate处理，如下所示：

void PPP_Instance_Proxy::OnPluginMsgDidCreate(
    PP_Instance instance,
    const std::vector<std::string>& argn,
    const std::vector<std::string>& argv,
    PP_Bool* result) {
  *result = PP_FALSE;
  ......

  // Make sure the arrays always have at least one element so we can take the
  // address below.
  std::vector<const char*> argn_array(
      std::max(static_cast<size_t>(1), argn.size()));
  std::vector<const char*> argv_array(
      std::max(static_cast<size_t>(1), argn.size()));
  for (size_t i = 0; i < argn.size(); i++) {
    argn_array[i] = argn[i].c_str();
    argv_array[i] = argv[i].c_str();
  }

  DCHECK(combined_interface_.get());
  *result = combined_interface_->DidCreate(instance,
                                           static_cast<uint32_t>(argn.size()),
                                           &argn_array[0], &argv_array[0]);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppp_instance_proxy.cc中。

从前面的分析可以知道，PPP_Instance_Proxy类的成员变量combined_interface_指向的一个PPP_Instance_Combined对象。PPP_Instance_Proxy类的成员函数OnPluginMsgDidCreate主要是调用这个PPP_Instance_Combined对象的成员函数DidCreate在当前进程（Plugin进程）中创建一个Plugin Instance，如下所示：

PP_Bool PPP_Instance_Combined::DidCreate(PP_Instance instance,
                                         uint32_t argc,
                                         const char* argn[],
                                         const char* argv[]) {
  return CallWhileUnlocked(instance_1_1_.DidCreate, instance, argc, argn, argv);
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppp_instance_combined.cc中。

从前面的分析可以知道，PPP_Instance_Combined类的成员变量instance_1_1_指向的是一个PPP_Instance对象。这个PPP_Instance对象的成员变量DidCreate是一个函数指针，它指向的函数为Instance_DidCreate。PPP_Instance_Combined类的成员函数DidCreate主要是调用这个函数来创建一个Plugin Instance。因此，接下来我们继续分析函数Instance_DidCreate的实现，如下所示：

PP_Bool Instance_DidCreate(PP_Instance pp_instance,
                           uint32_t argc,
                           const char* argn[],
                           const char* argv[]) {
  Module* module_singleton = Module::Get();
  if (!module_singleton)
    return PP_FALSE;

  Instance* instance = module_singleton->CreateInstance(pp_instance);
  if (!instance)
    return PP_FALSE;
  module_singleton->current_instances_[pp_instance] = instance;
  return PP_FromBool(instance->Init(argc, argn, argv));
}

这个函数定义在文件external/chromium_org/ppapi/cpp/module.cc中。

函数Instance_DidCreate首先调用Module类的静态成员函数Get获得当前Plugin进程中的一个pp::Module单例对象。从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，这个pp::Module单例对象描述的就是在当前Plugin进程中加载的Plugin Module。有了这个pp::Module对象之后，就可以调用它的成员函数CreateInstance创建一个Plugin Instance，即一个pp::Instance对象。

参数pp_instance的类型为PP_Instance。PP_Instance的实际类型为int32_t，也就是它描述的是一个有符号整数。这个有符号整数指定为当前创建的Plugin Instance的ID。与此同时，创建出来的Plugin Instance将会以它的ID为键值，保存在一个std::map中。这个std::map由上述获得的pp::Module单例对象的成员变量current_instances_描述。因此，通过这个std::map，我们就可以知道一个Plugin Module创建了多少个Plugin Instance。

我们在开发一个Plugin的时候，会自定义一个pp::Module类。例如，在前面Chromium插件（Plugin）机制简要介绍和学习计划一文提到的GLES2 Example，它自定义的pp::Module类为GLES2DemoModule。自定义的 GLES2DemoModule类是从pp::Module类继承下来的，并且会重写成员函数CreateInstance。这意味着前面所创建的Plugin Instance的实际类型由自定义的pp::Module类决定的。

例如，GLES2DemoModule类的成员函数CreateInstance创建的Plugin Instance的实际类型为GLES2DemoInstance，如下所示：

class GLES2DemoModule : public pp::Module {
 public:
  ......

  virtual pp::Instance* CreateInstance(PP_Instance instance) {
    return new GLES2DemoInstance(instance, this);
  }
};

这个函数定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

至此，Chromium的Render进程就请求目标Plugin进程创建了一个Plugin Instance。这个Plugin Instance的实际类型由开发者定义，只要它是从pp::Instance类继承下来即可。同时，在Render进程当中，存在一个对应的Plugin Instance Proxy。这个Plugin Instance Proxy是通过PepperPluginInstanceImpl类描述的。以后在Render进程中加载的网页需要使用Plugin Instance的功能时，就可以通过Plugin Instance Proxy实现，而在Plugin进程中创建的Plugin Instance需要使用Chromium提供的功能时，可以通过Chromium提供的接口（Browser Interface）实现。

在接下来一篇文章中，我们将以GLES2 Example为例，分析Plugin Instance通过Chromium提供的3D接口渲染自己的UI的过程。通过这个过程，我们就可以看到Plugin Instance与网页的交互过程，从而更好的理解Chromium的Plugin机制。敬请关注！更多的信息也可以关注老罗的新浪微薄：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/11/7 0:59:29 原文链接

阅读：32963 评论：2 查看评论

↧

Chromium插件（Plugin）执行3D渲染的过程分析

November 14, 2016, 1:00 am

≫ Next: Android WebView简要介绍和学习计划

≪ Previous: Chromium插件（Plugin）实例（Instance）创建过程分析

Chromium为网页的<embed>标签创建了Plugin之后，Plugin就负责渲染<embed>标签的内容。Chromium为Plugin提供了OpenGL接口，使得Plugin可在网页上渲染3D内容。当然，我们也可通过WebGL接口在网页上渲染3D内容。不过，前者渲染效率会更高些，因为它是Native接口，后者是JavaScript接口。本文接下来就详细分析Plugin执行3D渲染的过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

我们分析Plugin执行3D渲染的过程，更多的是为了理解Chromium与Plugin的交互过程，包括Chromium操作Plugin的过程，以及Plugin调用Chromium提供的接口的过程。接下来我们就以Chromium插件（Plugin）机制简要介绍和学习计划一文提到的GLES2 Example为例，分析Plugin执行3D渲染的过程。

从前面Chromium网页加载过程简要介绍和学习计划这个系列的文章可以知道，WebKit会将网页抽象为一个DOM Tree。网页中的每一个<embed>标签在这个DOM Tree中都会有一个对应的节点。从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章又可以知道，网页的DOM Tree又会被Chromium转化为一个CC Layer Tree。其中，DOM Tree中的<embed>节点将对应于CC Layer Tree中的一个Texture Layer，如图1所示：

图1 DOM Tree中的<embed>标签与CC Layer Tree中的Texture Layer

Plugin在调用Chromium提供的OpenGL接口的时候，实际上是将<embed>标签的内容渲染在它在CC Layer Tree中对应的Texture Layer上。当Chromium对网页的CC Layer Tree进行绘制的时候，它内部的Texture Layer的内容就会显示在屏幕上。Texture Layer描述的实际上是一个纹理。在前面Chromium硬件加速渲染的UI合成过程分析一文中，我们提到，网页的canvas标签在CC Layer Tree同样是对应有一个Texture Layer。因此，<embed>标签对应的Texture Layer与canvas标签对应的Texture Layer显示在屏幕上的过程是一样的。这一点可以参考前面Chromium硬件加速渲染的UI合成过程分析一文。

在Android平台上，Chromium提供给Plugin调用的OpenGL接口称为PPB_OPENGLES2_INTERFACE接口。PPB_OPENGLES2_INTERFACE接口提供了一系列的函数，每一个函数都对应于一个glXXX接口，如图2所示：

图2 Plugin调用OpenGL接口的过程

在调用PPB_OPENGLES2_INTERFACE接口提供的函数时，GLES2Implementation类的相应成员函数会被调用。例如，当PPB_OPENGLES2_INTERFACE接口提供的函数ActiveTexture被调用时，GLES2Implementation类的成员函数ActiveTexture。GLES2Implementation类的成员函数会将要执行的GPU命令写入到一个缓冲区中去，然后通过一个PpapiCommandBufferProxy对象通知Render进程执行缓冲区中的GPU命令。Render进程又会通过一个CommandBufferProxyImpl对象将要执行的GPU命令转发给GPU进程中的一个GpuCommandBufferStub处理。这意味Plugin最终是通过GPU进程执行GPU命令的。关于GLES2Implementation、CommandBufferProxyImpl和GpuCommandBufferStub这三类执行GPU命令的过程，可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

Plugin在通过PPB_OPENGLES2_INTERFACE接口执行OpenGL函数（GPU命令）之前，首先要初始化一个OpenGL环境。这个初始化操作发生在Plugin第一次知道自己的视图大小时，也就是知道它对应的<embed>标签的视图大小时。初始化过程如图3所示：

图3 Plugin的OpenGL环境初始化过程

Plugin的视图大小是由WebKit计算出来的。计算出来之后，WebKit会通过运行在Render进程中的Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象，向运行Plugin进程中的Plugin Instance发出通知。Plugin Instance获得了这个通知之后，就可以初始化一个OpenGL环境了。

Plugin Instance Proxy是通过调用PPP_INSTANCE_INTERFACE_1_1接口提供的一个函数DidChangeView向Plugin Instance发出通知的，后者又是通过向目标Plugin进程发送一个类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息发出该通知的。

类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息携带了一个参数PpapiMsg_PPPInstance_DidChangeView。这个参数描述的是一个Routing ID，表示Plugin进程要将类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息交给一个PPP_Instance_Proxy对象处理。这个PPP_Instance_Proxy对象获得该消息后，又会在当前Plugin进程中获得一个PPP_INSTANCE_INTERFACE_1_1接口，并且调用该接口提供的函数DidChangeView。该函数会找到目标Plugin Instance，并且调用它的成员函数DidChangeView。这样，Plugin Instance就可以初始化OpenGL环境了。以我们在前面Chromium插件（Plugin）机制简要介绍和学习计划一文提到的GLES2 Example为例，它的成员函数DidChangeView就通过调用另外一个成员函数InitGL初始化OpenGL环境的。

Plugin在初始化OpenGL环境的过程中，有两件重要的事情要做。第一件事情是创建一个OpenGL上下文，过程如图4所示：

图4 Plugin的OpenGL上文创建过程

在Plugin进程中，OpenGL上下文通过Graphics3D类描述。因此，创建OpenGL上下文意味着是创建一个Graphics3D对象。这个Graphics3D对象在创建的过程中，会调用PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的一个函数Create。该函数又会通过一个APP_ID_RESOURCE_CREATION接口向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息。在Plugin进程中，APP_ID_RESOURCE_CREATION接口是通过一个ResourceCreationProxy对象实现的，因此，Plugin进程实际上是通过ResourceCreationProxy类向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息的。

Plugin进程在向Render进程发送类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息时，会指定一个参数APP_ID_PPB_GRAPHICS_3D，表示Render进程在接收到该消息后，要将其分发给一个PPB_Graphics3D_Proxy对象处理。这个PPB_Graphics3D_Proxy对象又会通过调用PPB_Graphics3D_Impl类的静态成员函数CreateRaw创建一个PPB_Graphics3D_Impl对象。这个PPB_Graphics3D_Impl对象在Render进程描述的就是一个OpenGL上下文。

Plugin在初始化OpenGL环境的过程中做的第二件事情就是将刚刚创建出来的OpenGL上下文指定为当前要使用的OpenGL上下文。这个过程称为OpenGL上下文绑定，如图5所示：

图5 Plugin绑定OpenGL上下文的过程

Plugin是通过调用PPB_INSTANCE_INTERFACE_1_0接口提供的函数BindGraphics进行OpenGL上下文绑定的。该函数又会通过一个APP_ID_PPB_INSTANCE接口向Render进程发送一个类型为PpapiHostMsg_PPBIntance_BindGraphics的IPC消息。在Plugin进程中，APP_ID_PPB_INSTANCE接口是通过一个PPB_Instance_Proxy对象实现的，因此，Plugin进程实际上是通过PPB_Instance_Proxy类向Render进程发送一个类型为PpapiHostMsg_PPBIntance_BindGraphics的IPC消息的。

Plugin进程在向Render进程发送类型为PpapiHostMsg_PPBIntance_BindGraphics的IPC消息时，会指定一个参数APP_ID_PPB_INSTANCE，表示Render进程在接收到该消息后，要将其分发给一个PPB_Instance_Proxy对象处理。这个PPB_Instance_Proxy对象又会找到目标Plugin Instance在Render进程中对应的Proxy，也就是一个PepperPluginInstanceImpl对象，并且调用该PepperPluginInstanceImpl对象的成员函数BindGraphics。

PepperPluginInstanceImpl类的成员函数BindGraphics在执行的过程中，会将指定的OpenGL上下文，也就是前面创建一个PPB_Graphics3D_Impl对象标记为被绑定，这样它接下来就会作为Plugin当前使用的OpenGL上下文了。

OpenGL环境初始化完成之后，Plugin就可以使用图2所示的PPB_OPENGLES2_INTERFACE接口来执行3D渲染了。一帧渲染完毕，Plugin需要交换当前使用的OpenGL上下文的前后两个缓冲区，也就是执行一个SwapBuffers操作。这个操作的执行过程如图6所示：

图6 Plugin执行SwapBuffers操作的过程

前面提到，在Plugin进程中，OpenGL上下文是通过一个Graphics3D对象描述的。这个Graphics3D对象可以通过PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的成员函数SwapBuffers完成SwapBuffers操作。

PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的成员函数SwapBuffers在执行的过程中，会向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_SwapBuffers的IPC消息。这个消息携带了一个参数API_ID_PPB_GRAPHICS_3D，表示Render进程需要将该消息分发给一个PPB_Graphics3D_Proxy对象处理。这个PPB_Graphics3D_Proxy对象会找到Plugin当前绑定的OpenGL上下文，也就是一个PPB_Graphics3D_Impl对象，并且调用该PPB_Graphics3D_Impl对象的成员函数DoSwapBuffers。这时候就可以完成一个SwapBuffers操作，从而也完成一个帧的渲染流程。

接下来，我们就从WebKit通知Plugin视图大小开始，分析Plugin执行3D渲染的完整流程。从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，WebKit为<embed>标签创建了一个Plugin Instance之后，会将其放在一个由WebPluginContainerImpl类描述的Plugin View中。当<embed>标签的视图大小发生变化时，WebPluginContainerImpl类的成员函数reportGeometry就会被调用，它的实现如下所示：

void WebPluginContainerImpl::reportGeometry()
{
    ......

    IntRect windowRect, clipRect;
    Vector<IntRect> cutOutRects;
    calculateGeometry(frameRect(), windowRect, clipRect, cutOutRects);

    m_webPlugin->updateGeometry(windowRect, clipRect, cutOutRects, isVisible());

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/web/WebPluginContainerImpl.cpp中。

WebPluginContainerImpl类的成员函数reportGeometry首先是调用成员函数calulateGeometry计算<embed>标签的视图大小，然后再将计算得到的信息告知Content层，这是通过成员变量m_webPlugin指向的一个PepperWebPluginImpl对象的成员函数updateGeometry实现的。这个PepperWebPluginImpl对象的创建过程可以参考前面Chromium的Plugin进程启动过程分析一文。

接下来我们继续分析PepperWebPluginImpl类的成员函数updateGeometry的实现，以便了解Render进程通知Plugin它描述的<embed>标签的大小的过程，如下所示：

void PepperWebPluginImpl::updateGeometry(
    const WebRect& window_rect,
    const WebRect& clip_rect,
    const WebVector<WebRect>& cut_outs_rects,
    bool is_visible) {
  plugin_rect_ = window_rect;
  if (!instance_->FlashIsFullscreenOrPending()) {
    std::vector<gfx::Rect> cut_outs;
    for (size_t i = 0; i < cut_outs_rects.size(); ++i)
      cut_outs.push_back(cut_outs_rects[i]);
    instance_->ViewChanged(plugin_rect_, clip_rect, cut_outs);
  }
}

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

PepperWebPluginImpl类的成员变量instance_指向的是一个PepperPluginInstanceImpl对象。从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，这个PepperPluginInstanceImpl对象是用来在Render进程中描述一个Plugin Instance Proxy的。

PepperWebPluginImpl类的成员函数updateGeometry首先调用上述PepperPluginInstanceImpl对象的成员函数FlashIsFullscreenOrPending判断当前正在处理的Plugin是否是一个Flash Plugin。如果是一个Flash Plugin，并且它当前处于全屏状态或者即将进入全屏状态，那么PepperWebPluginImpl类的成员函数updateGeometry就不会通知Plugin它描述的<embed>标签的视图大小发生了变化。

我们假设当前正在处理的Plugin不是一个Flash Plugin。这时候PepperWebPluginImpl类的成员函数updateGeometry就会调用上述PepperPluginInstanceImpl对象的成员函数ViewChanged通知Plugin它描述的<embed>标签的视图大小发生了变化。

PepperPluginInstanceImpl类的成员函数ViewChanged的实现如下所示：

void PepperPluginInstanceImpl::ViewChanged(
    const gfx::Rect& position,
    const gfx::Rect& clip,
    const std::vector<gfx::Rect>& cut_outs_rects) {
  ......

  view_data_.rect = PP_FromGfxRect(position);
  view_data_.clip_rect = PP_FromGfxRect(clip);
  ......

  SendDidChangeView();
}

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

PepperPluginInstanceImpl类的成员函数ViewChanged首先将当前正在处理的Plugin描述的<embed>标签的视图大小信息保存在成员变量view_data_描述的一个ppapi::ViewData对象中，然后再调用另外一个成员函数SendDidChangeView向运行在Plugin进程中的Plugin Instance发送一个视图大小变化通知。

PepperPluginInstanceImpl类的成员函数SendDidChangeView的实现如下所示：

void PepperPluginInstanceImpl::SendDidChangeView() {
  ......

  ScopedPPResource resource(
      ScopedPPResource::PassRef(),
      (new PPB_View_Shared(ppapi::OBJECT_IS_IMPL, pp_instance(), view_data_))
          ->GetReference());
  ......

  if (instance_interface_) {
    instance_interface_->DidChangeView(
        pp_instance(), resource, &view_data_.rect, &view_data_.clip_rect);
  }
}

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

PepperPluginInstanceImpl类的成员函数SendDidChangeView首先是将成员变量view_data_描述的ppapi::ViewData对象封装在一个PPB_View_Shared对象。从前面的分析可以知道，被封装的ppapi::ViewData对象描述的当前正在处理的Plugin描述的<embed>标签的视图大小信息。封装得到的PPB_View_Shared对象接下来会传递给PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidChangeView使用。

从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，PepperPluginInstanceImpl类的成员变量instance_interface_指向的是一个PPP_Instance_Combined对象。这个PPP_Instance_Combined对象描述的是一个PPP_INSTANCE_INTERFACE_1_1接口。运行在Render进程中的Plugin Instance Proxy可以通过这个接口与运行在Plugin进程中的Plugin Instance通信。

PepperPluginInstanceImpl类的成员函数SendDidChangeView主要就是调用上述PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidChangeView通知运行在Plugin进程中的Plugin Instance，它描述的<embed>标签的视图大小发生了变化，也就是通过调用成员变量instance_interface_指向的PPP_Instance_Combined对象的成员函数DidChangeView进行通知。

PPP_Instance_Combined类的成员函数DidChangeView的实现如下所示：

void PPP_Instance_Combined::DidChangeView(PP_Instance instance,
                                          PP_Resource view_changed_resource,
                                          const struct PP_Rect* position,
                                          const struct PP_Rect* clip) {
  if (instance_1_1_.DidChangeView) {
    CallWhileUnlocked(
        instance_1_1_.DidChangeView, instance, view_changed_resource);
  } 

  ......
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppp_instance_combined.cc中。

从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，PPP_Instance_Combined类的成员变量instance_1_1_描述的是一个PPP_Instance_1_1对象。这个PPP_Instance_1_1对象描述的就是上述的PPP_INSTANCE_INTERFACE_1_1接口。PPP_Instance_Combined类的成员函数DidChangeView通过一个帮助函数CallWhilleUnlocked调用这个PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidChangeView，以便向运行在Plugin进程中的Plugin Instance发出一个视图大小变化通知。

从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文还可以知道，上述PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidChangeView实现在ppp_instance_proxy.cc文件中，如下所示：

void DidChangeView(PP_Instance instance, PP_Resource view_resource) {
  HostDispatcher* dispatcher = HostDispatcher::GetForInstance(instance);

  EnterResourceNoLock<PPB_View_API> enter_view(view_resource, false);
  ......

  dispatcher->Send(new PpapiMsg_PPPInstance_DidChangeView(
      API_ID_PPP_INSTANCE, instance, enter_view.object()->GetData(),
      flash_fullscreen));
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppp_instance_proxy.cc中。

参数instance的类型为PP_Instance。PP_Instance描述的实际上是一个32位的有符号整数。这个32位的有符号整数是用来描述一个Plugin的ID。通过这个ID，运行在Render进程中的Plugin Instance Proxy与运行在Plugin进程中的Plugin Instance就能一一对应起来的。

函数DidChangeView首先通过调用HostDispatcher类的静态成员函数GetForInstance获得一个HostDispatcher对象。从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，每一个Plugin进程在Render进程中都有一个对应的HostDispatcher对象。这个HostDispatcher对象就是用来与它对应的Plugin进程通信的。给出一个PP_Instance，HostDispatcher类的静态成员函数GetForInstance就可以获得这个PP_Instance描述的Plugin Instance所运行在的Plugin进程对应的HostDispatcher对象。

获得了目标Plugin进程对应的HostDispatcher对象之后，就可以向它发送一个类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息。这个IPC消息携带了四个参数：

1. API_ID_PPP_INSTANCE，要求Plugin进程将该IPC消息分发给API_ID_PPP_INSTANCE接口处理。

2. instance，表示目标Plugin Instance。

3. ppapi::ViewData，表示目标Plugin Instance的当前视图大小。

4. flash_fullscreen，表示目标Plugin Instance是否处于全屏状态。

其中，第3个参数描述的ppapi::ViewData对象来自于前面在PepperPluginInstanceImpl类的成员函数SendDidChangeView中封装的PPB_View_Shared对象。这个PPB_View_Shared对象对象是通过函数DidChangeView的第2个参数view_resource传递进来的。

函数DidChangeView首先将上述PPB_View_Shared对象封装在一个EnterResourceNoLock<PPB_View_API>对象中。接下来通过调用这个EnterResourceNoLock<PPB_View_API>对象的成员函数object就可以获得它封装的PPB_View_Shared对象。再调用这个PPB_View_Shared对象的成员函数GetData即可以获得它内部封装的一个ppapi::ViewData对象。这个ppapi::ViewData对象内部保存了目标Plugin Instance的当前视图大小信息，因此可以作为上述IPC消息的第3个参数。

从前面Chromium的Plugin进程启动过程分析一文可以知道，每一个Plugin进程都存在一个PluginDispatcher对象。Plugin进程将会通过这个PluginDispatcher对象的成员函数OnMessageReceived接收Render进程发送过来的IPC消息。这意味着前面从Render进程发送过来的类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息是通过PluginDispatcher类的成员函数OnMessageReceived接收的。

PluginDispatcher类的成员函数OnMessageReceived是从父类Dispatcher继承下来的，它的实现如下所示：

bool Dispatcher::OnMessageReceived(const IPC::Message& msg) {  
  ......  
  
  InterfaceProxy* proxy = GetInterfaceProxy(  
      static_cast<ApiID>(msg.routing_id()));  
  ......  
  
  return proxy->OnMessageReceived(msg);  
}

这个函数定义在文件external/chromium_org/ppapi/proxy/dispatcher.cc中。

从前面的分析可以知道，此时参数msg指向的Message对象描述的是一个类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息，该消息的Routing ID为API_ID_PPP_INSTANCE，表示要将该消息分发给一个API_ID_PPP_INSTANCE接口处理。这个API_ID_PPP_INSTANCE接口可以通过调用调用另外一个成员函数GetInterfaceProxy获得。

在前面Chromium插件（Plugin）实例（Instance）创建过程分析一文中，我们已经分析过Dispatcher类的成员函数GetInterfaceProxy的实现，因此这里不再复述。再结合前面Chromium插件（Plugin）模块（Module）加载过程分析一文，我们可以知道，在Plugin进程中，API_ID_PPP_INSTANCE接口是由一个PPP_Instance_Proxy对象实现的，Dispatcher类的成员函数GetInterfaceProxy接下来会将参数msg描述的类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息分发给它处理，也就是调用它的成员函数OnMessageReceived。

PPP_Instance_Proxy类的成员函数OnMessageReceived的实现如下所示：

bool PPP_Instance_Proxy::OnMessageReceived(const IPC::Message& msg) {
  ......

  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPP_Instance_Proxy, msg)
    ......
    IPC_MESSAGE_HANDLER(PpapiMsg_PPPInstance_DidChangeView,
                        OnPluginMsgDidChangeView)
    ......
    IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()
  return handled;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppp_instance_proxy.cc中。

从这里可以看到，PPP_Instance_Proxy类的成员函数OnMessageReceived将类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息分发给另外一个成员函数OnPluginMsgDidChangeView处理，如下所示：

void PPP_Instance_Proxy::OnPluginMsgDidChangeView(
    PP_Instance instance,
    const ViewData& new_data,
    PP_Bool flash_fullscreen) {
  ......

  combined_interface_->DidChangeView(instance, resource,
                                     &new_data.rect,
                                     &new_data.clip_rect);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppp_instance_proxy.cc中。

从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，PPP_Instance_Proxy类的成员变量combined_interface_指向的是一个PPP_Instance_Combined对象。PPP_Instance_Proxy类的成员函数OnPluginMsgDidChangeView主要是调用这个PPP_Instance_Combined对象的成员函数DidChangeView通知参数instance描述的Plugin Instance，它的视图大小发生了变化。

PPP_Instance_Combined类的成员函数DidChangeView的实现如下所示：

void PPP_Instance_Combined::DidChangeView(PP_Instance instance,
                                          PP_Resource view_changed_resource,
                                          const struct PP_Rect* position,
                                          const struct PP_Rect* clip) {
  if (instance_1_1_.DidChangeView) {
    CallWhileUnlocked(
        instance_1_1_.DidChangeView, instance, view_changed_resource);
  } 
  ......
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppp_instance_combined.cc中。

从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，PPP_Instance_Combined类的成员变量instance_1_1_指向的是一个PPP_Instance对象。这个PPP_Instance对象的成员变量DidChangeView是一个函数指针，它指向的函数为Instance_DidChangeView。PPP_Instance_Combined类的成员函数DidCreate主要是调用这个函数通知参数instance描述的Plugin Instance，它的视图大小发生了变化。

函数Instance_DidChangeView的实现，如下所示：

void Instance_DidChangeView(PP_Instance pp_instance,
                            PP_Resource view_resource) {
  Module* module_singleton = Module::Get();
  ......
  Instance* instance = module_singleton->InstanceForPPInstance(pp_instance);
  ......
  instance->DidChangeView(View(view_resource));
}

这个函数定义在文件external/chromium_org/ppapi/cpp/module.cc中。

函数Instance_DidChangeView首先调用Module类的静态成员函数Get获得当前Plugin进程中的一个pp::Module单例对象。从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，这个pp::Module单例对象描述的就是在当前Plugin进程中加载的Plugin Module。

从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，一个Plugin Module创建的所有Plugin Instance都会以它们的ID为键值，保存在一个std::map中。因此，函数Instance_DidChangeView可以在这个std::map中找到与参数pp_instance对应的Plugin Instance，即一个pp::Instance对象。这个通过调用前面获得的pp::Module单例对象的成员函数InstanceForPPInstance实现的。获得了目标pp::Instance对象之后，就可以调用它的成员函数DidChangeView，以便通知它视图大小发生了变化。

我们在开发一个Plugin的时候，会自定义一个pp::Instance类。例如，在前面Chromium插件（Plugin）机制简要介绍和学习计划一文提到的GLES2 Example，它自定义的pp::Instance类为GLES2DemoInstance。自定义的GLES2DemoInstance类是从pp::Instance类继承下来的，并且会重写成员函数DidChangeView。这意味着接下来GLES2DemoInstance类的成员函数DidChangeView会被调用。

GLES2DemoInstance类的成员函数DidChangeView的实现如下所示：

void GLES2DemoInstance::DidChangeView(
    const pp::Rect& position, const pp::Rect& clip_ignored) {
  ......
  plugin_size_ = position.size();

  // Initialize graphics.
  InitGL(0);
}

这个函数定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

参数position描述的一个pp::Rect对象记录了当前正在处理的Plugin Instance的当前视图大小。GLES2DemoInstance类的成员函数DidChangeView首先将这个视图大小记录在成员变量plugin_size_中，接下来又调用另外一个成员函数InitGL初始化一个OpenGL环境。

GLES2DemoInstance类的成员函数InitGL的实现如下所示：

void GLES2DemoInstance::InitGL(int32_t result) {
  ......

  if (context_) {
    context_->ResizeBuffers(plugin_size_.width(), plugin_size_.height());
    return;
  }
  int32_t context_attributes[] = {
    PP_GRAPHICS3DATTRIB_ALPHA_SIZE, 8,
    PP_GRAPHICS3DATTRIB_BLUE_SIZE, 8,
    PP_GRAPHICS3DATTRIB_GREEN_SIZE, 8,
    PP_GRAPHICS3DATTRIB_RED_SIZE, 8,
    PP_GRAPHICS3DATTRIB_DEPTH_SIZE, 0,
    PP_GRAPHICS3DATTRIB_STENCIL_SIZE, 0,
    PP_GRAPHICS3DATTRIB_SAMPLES, 0,
    PP_GRAPHICS3DATTRIB_SAMPLE_BUFFERS, 0,
    PP_GRAPHICS3DATTRIB_WIDTH, plugin_size_.width(),
    PP_GRAPHICS3DATTRIB_HEIGHT, plugin_size_.height(),
    PP_GRAPHICS3DATTRIB_NONE,
  };
  context_ = new pp::Graphics3D(this, context_attributes);
  ......
  assert(BindGraphics(*context_));

  ......

  FlickerAndPaint(0, true);
}

这个函数定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

初始化Plugin的OpenGL环境需要执行两个操作：

1. 创建一个OpenGL上下文。这个OpenGL上下文用一个pp::Graphics3D对象描述。

2. 将创建出来的OpenGL上下文与Plugin进行绑定，也就是将它指定为Plugin当前使用的OpenGL上下文。这可以通过调用父类pp::Instance继承下来的成员函数BindGraphics来完成。

GLES2DemoInstance类的成员变量context_就是用来描述Plugin当前使用的OpenGL上下文。如果这个OpenGL上下文还没有创建，那么GLES2DemoInstance类的成员函数InitGL就会根据Plugin当前的视图大小进行创建。否则的话，就只会改变这个OpenGL上下文描述的绘图缓冲区的大小。

完成以上两个操作之后，GLES2DemoInstance类的成员函数InitGL就会调用另外一个成员函数FlickerAndPaint渲染Plugin的视图。渲染出来的内容最后就会合成在网页的UI中显示出来。

接下来我们先分析OpenGL上下文的创建过程，也就是一个pp::Graphics3D对象的创建过程，我们pp::Graphics3D类的构造函数开始分析，它的实现如下所示：

Graphics3D::Graphics3D(const InstanceHandle& instance,
                       const int32_t attrib_list[]) {
  if (has_interface<PPB_Graphics3D_1_0>()) {
    PassRefFromConstructor(get_interface<PPB_Graphics3D_1_0>()->Create(
        instance.pp_instance(), 0, attrib_list));
  }
}

这个函数定义在文件external/chromium_org/ppapi/cpp/graphics_3d.cc中。

pp::Graphics3D类的构造函数首行调用模板函数has_interface<PPB_Graphics3D_1_0>检查在当前Plugin进程中加载的Plugin Module是否支持PPB_GRAPHICS_3D_INTERFACE_1_0。如果支持的话，那么就会再调用另外一个模板函数get_interface<PPB_Graphics3D_1_0>获得这个PPB_GRAPHICS_3D_INTERFACE_1_0接口。获得了PPB_GRAPHICS_3D_INTERFACE_1_0接口之后，就可以调用它提供的函数Create请求Render进程创建一个OpenGL上下文了。

从后面的分析我们可以知道，PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的函数Create创建出来的OpenGL上下文用一个proxy::proxy::Graphics3D对象描述，不过它返回给调用者的是分配给proxy::proxy::Graphics3D对象的一个资源ID。pp::Graphics3D类的构造函数会调用从父类pp::Resource继承下来的成员函数PassRefFromConstructor将这个资源ID保存在成员变量pp_resource_中，如下所示：

void Resource::PassRefFromConstructor(PP_Resource resource) {
  PP_DCHECK(!pp_resource_);
  pp_resource_ = resource;
}

这个函数定义在文件external/chromium_org/ppapi/cpp/resource.cc中。

以后通过调用pp::Resource类的成员函数pp_resource即可以获得这个资源ID，如下所示：

class Resource {
 public:
  ......

  PP_Resource pp_resource() const { return pp_resource_; }

  ......
};

这个函数定义在文件external/chromium_org/ppapi/cpp/resource.h中。

回到 pp::Graphics3D类的构造函数中，接下来我们首先分析PPB_GRAPHICS_3D_INTERFACE_1_0接口的获取过程，也就是模板函数get_interface<PPB_Graphics3D_1_0>的实现，如下所示：

template <typename T> inline T const* get_interface() {
  static T const* funcs = reinterpret_cast<T const*>(
      pp::Module::Get()->GetBrowserInterface(interface_name<T>()));
  return funcs;
}

这个模板函数定义在文件external/chromium_org/ppapi/cpp/module_impl.h中。

这里的模板参数T为PPB_Graphics3D_1_0，展开后得到模板函数get_interface<PPB_Graphics3D_1_0>的具体实现为：

inline PPB_Graphics3D_1_0 const* get_interface() {
  static PPB_Graphics3D_1_0 const* funcs = reinterpret_cast<PPB_Graphics3D_1_0 const*>(
      pp::Module::Get()->GetBrowserInterface(interface_name<PPB_Graphics3D_1_0>()));
  return funcs;
}

它首先会调用另外一个模板函数interface_name<PPB_Graphics3D_1_0>获得要获取的接口名称，接着再调用前面提到的pp::Module类的静态成员函数Get获得当前Plugin进程中的一个pp::Module单例对象。有了这个pp::Module单例对象之后，就可以调用它的成员函数GetBrowserInterface根据名称获得接口。

我们首先分析模板函数interface_name<PPB_Graphics3D_1_0>的实现，以便知道要获取的接口名称是什么，如下所示：

template <> const char* interface_name<PPB_Graphics3D_1_0>() {
  return PPB_GRAPHICS_3D_INTERFACE_1_0;
}

这个模板函数定义在文件ppapi/cpp/graphics_3d.cc中。

从这里可以看到，要获取的接口名称为PPB_GRAPHICS_3D_INTERFACE_1_0，也就我们要获取的是PPB_GRAPHICS_3D_INTERFACE_1_0接口。这个接口可以通过调用前面获得的pp::Module单例对象的GetBrowserInterface获得。

在前面Chromium插件（Plugin）模块（Module）加载过程分析一文中，我们已经分析过了pp::Module类的GetBrowserInterface的实现，并且我们也知道，在Plugin进程中，PPB_GRAPHICS_3D_INTERFACE_1_0接口是由一个PPB_Graphics3D_1_0对象实现的。这个PPB_Graphics3D_1_0对象的定义如下所示：

const PPB_Graphics3D_1_0 g_ppb_graphics3d_thunk_1_0 = {  
  &GetAttribMaxValue,  
  &Create,  
  &IsGraphics3D,  
  &GetAttribs,  
  &SetAttribs,  
  &GetError,  
  &ResizeBuffers,  
  &SwapBuffers  
};

这个对象定义在文件external/chromium_org/ppapi/thunk/ppb_graphics_3d_thunk.cc中。

这个PPB_Graphics3D_1_0对象的成员变量Create是一个函数指针。这个函数指针指向了函数Create。这个函数也是定义在文件ppb_graphics_3d_thunk.cc中。

回到Graphics3D类的构造函数中，现在我们就可以知道，它实际上是通过调用上述函数Create请求Render进程为当前正在处理的Plugin创建一个OpenGL上下文的，如下所示：

PP_Resource Create(PP_Instance instance,
                   PP_Resource share_context,
                   const int32_t attrib_list[]) {
  ......
  EnterResourceCreation enter(instance);
  ......
  return enter.functions()->CreateGraphics3D(instance,
                                             share_context,
                                             attrib_list);
}

这个函数定义在文件external/chromium_org/ppapi/thunk/ppb_graphics_3d_thunk.cc中。

OpenGL上下文属于一种资源。在Plugin中，创建资源要使用到接口API_ID_RESOURCE_CREATION。函数Create通过构造一个EnterResourceCreation对象来封装对接口API_ID_RESOURCE_CREATION的调用。封装过程如下所示：

EnterResourceCreation::EnterResourceCreation(PP_Instance instance)
    : EnterBase(),
      functions_(PpapiGlobals::Get()->GetResourceCreationAPI(instance)) {
  ......
}

这个函数定义在文件external/chromium_org/ppapi/thunk/enter.cc中。

在Plugin进程中，存在一个PluginGlobals单例对象。这个PluginGlobals单例对象可以通过调用PpapiGlobals类的静态成员函数获得。注意，PluginGlobals类是从PpapiGlobals继承下来的。

获得上述PluginGlobals单例对象之后，EnterResourceCreation类的构造函数就调用它的成员函数GetResourceCreationAPI获得一个API_ID_RESOURCE_CREATION接口，如下所示：

thunk::ResourceCreationAPI* PluginGlobals::GetResourceCreationAPI(
    PP_Instance instance) {
  PluginDispatcher* dispatcher = PluginDispatcher::GetForInstance(instance);
  if (dispatcher)
    return dispatcher->GetResourceCreationAPI();
  return NULL;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/plugin_globals.cc中。

从前面Chromium的Plugin进程启动过程分析一文可以知道，在Plugin进程中加载的Plugin Module对应有一个PluginDispatcher对象。这个PluginDispatcher对象与运行在Render进程中的HostDispatcher对象对应。所有属于该Plugin Module的Instance都使用相同的PluginDispatcher对象与Render进程通信。

PluginGlobals类的成员函数GetResourceCreationAPI首先调用PluginDispatcher类的静态成员函数GetForInstance获得与参数instance描述的Plugin Instance对应的PluginDispatcher对象。有了这个PluginDispatcher对象之后，就可以调用它的成员函数GetResourceCreationAPI获得一个API_ID_RESOURCE_CREATION接口，如下所示：

thunk::ResourceCreationAPI* PluginDispatcher::GetResourceCreationAPI() {
  return static_cast<ResourceCreationProxy*>(
      GetInterfaceProxy(API_ID_RESOURCE_CREATION));
}

这个函数定义在文件external/chromium_org/ppapi/proxy/plugin_dispatcher.cc中。

PluginDispatcher类的成员函数GetResourceCreationAPI调用另外一个成员函数GetInterfaceProxy获得一个API_ID_RESOURCE_CREATION接口。PluginDispatcher类的成员函数GetInterfaceProxy是从父类Dispatcher继承下来的，在前面Chromium插件（Plugin）实例（Instance）创建过程分析一文中，我们已经分析过它的实现了。

结合前面Chromium插件（Plugin）模块（Module）加载过程分析一文，我们可以知道，在Plugin进程中，API_ID_RESOURCE_CREATION接口被指定为ResourceCreationProxy类的静态成员函数Create，Dispatcher类的成员函数GetInterfaceProxy将会调用这个函数创建一个ResourceCreationProxy对象，如下所示：

InterfaceProxy* ResourceCreationProxy::Create(Dispatcher* dispatcher) {
  return new ResourceCreationProxy(dispatcher);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/resource_creation_proxy.cc中。

参数dispatcher指向的是一个PluginDispatcher对象。这个PluginDispatcher对象就是在前面分析的PluginGlobals类的成员函数GetResourceCreationAPI中获取的PluginDispatcher对象。ResourceCreationProxy类的静态成员函数Create使用该PluginDispatcher对象创建了一个ResourceCreationProxy对象，并且返回给最初的调用者，也就是EnterResourceCreation类的构造函数。EnterResourceCreation类的构造函数又会将这个ResourceCreationProxy对象保存在成员变量functions_中。

这一步执行完成后，回到前面分析的函数Create中。这时候就它构造了一个EnterResourceCreation对象，并且这个EnterResourceCreation对象的成员变量functions_指向了一个ResourceCreationProxy对象。

函数Create接下来会调用上述EnterResourceCreation对象的成员函数functions它的成员变量functions_指向的ResourceCreationProxy对象。有了这个ResourceCreationProxy对象之后，就可以调用它的成员函数CreateGraphics3D请求Render进程为当前正在处理的Plugin Instance创建一个OpenGL上下文了。

ResourceCreationProxy类的成员函数CreateGraphics3D的实现如下所示：

PP_Resource ResourceCreationProxy::CreateGraphics3D(
    PP_Instance instance,
    PP_Resource share_context,
    const int32_t* attrib_list) {
  return PPB_Graphics3D_Proxy::CreateProxyResource(
      instance, share_context, attrib_list);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/resource_creation_proxy.cc中。

ResourceCreationProxy类的成员函数CreateGraphics3D调用PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource请求Render进程为当前正在处理的Plugin Instance创建一个OpenGL上下文，如下所示：

PP_Resource PPB_Graphics3D_Proxy::CreateProxyResource(
    PP_Instance instance,
    PP_Resource share_context,
    const int32_t* attrib_list) {
  PluginDispatcher* dispatcher = PluginDispatcher::GetForInstance(instance);
  ......

  HostResource share_host;
  gpu::gles2::GLES2Implementation* share_gles2 = NULL;
  if (share_context != 0) {
    EnterResourceNoLock<PPB_Graphics3D_API> enter(share_context, true);
    if (enter.failed())
      return PP_ERROR_BADARGUMENT;

    PPB_Graphics3D_Shared* share_graphics =
        static_cast<PPB_Graphics3D_Shared*>(enter.object());
    share_host = share_graphics->host_resource();
    share_gles2 = share_graphics->gles2_impl();
  }

  std::vector<int32_t> attribs;
  if (attrib_list) {
    for (const int32_t* attr = attrib_list;
         attr[0] != PP_GRAPHICS3DATTRIB_NONE;
         attr += 2) {
      attribs.push_back(attr[0]);
      attribs.push_back(attr[1]);
    }
  }
  attribs.push_back(PP_GRAPHICS3DATTRIB_NONE);

  HostResource result;
  dispatcher->Send(new PpapiHostMsg_PPBGraphics3D_Create(
      API_ID_PPB_GRAPHICS_3D, instance, share_host, attribs, &result));
  ......

  scoped_refptr<Graphics3D> graphics_3d(new Graphics3D(result));
  if (!graphics_3d->Init(share_gles2))
    return 0;
  return graphics_3d->GetReference();
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_graphics_3d_proxy.cc中。

PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource首先调用PluginDispatcher类的静态成员函数GetForInstance获得与参数instance描述的Plugin Instance对应的一个PluginDispatcher对象。后面将会通过这个PluginDispatcher对象向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息，用来请求Render进程创建一个OpenGL上下文了。

类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息传递了4个参数给Render进程，分别是：

1. API_ID_PPB_GRAPHICS_3D，表示Render进程要将该IPC消息分发给API_ID_PPB_GRAPHICS_3D接口处理。

2. instance，描述要创建OpenGL上下文的Plugin Instance。

3. share_host，描述另外一个OpenGL上下文，新创建的OpenGL上下文要与它在同一个共享组中。

4. attribs，描述新创建的OpenGL上下文应具有的属性。

Render进程根据要求为目标Plugin Instance创建了一个OpenGL上下文之后，会为该OpenGL上下文分配一个ID，并且会将该ID返回给Plugin进程。Plugin进程再将这个ID封装在一个HostResource对象，然后将这个HostResource对象返回给PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource。

PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource再根据获得的HostResource对象创建一个ppapi::proxy::Graphics3D对象，并且调用它的成员函数Init对它进行初始化，相当于是对新创建的OpenGL上下文进行初始化。初始化完成后，就可以进行使用了。

新创建的Graphics3D对象初始化完成之后，PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource再调用它的成员函数GetReference获得一个类型为PP_Resource的引用。以后通过这个引用就可以使用该Graphics3D对象，也就是新创建的OpenGL上下文。

接下来，我们首先分析Render进程为目标Plugin Instance创建OpenGL上下文的过程，即处理类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息的过程，然后再分析新创建的OpenGL上下文在Plugin进程的初始化过程。

前面提到，Render进程会将类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息分发给API_ID_PPB_GRAPHICS_3D接口处理。从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，在Render进程中，API_ID_PPB_GRAPHICS_3D接口是由一个PPB_Graphics3D_Proxy对象实现的，也就是Render进程会将类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息分发给该PPB_Graphics3D_Proxy对象处理，这是通过调用它的成员函数OnMessageReceived实现的。

类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息在Render进程中的分发过程类似我们在前面Chromium插件（Plugin）实例（Instance）创建过程分析一文提到的类型为PpapiMsg_PPPInstance_DidCreate的IPC消息在Plugin进程中的分发过程，因此这里不再详细描述。

接下来我们继续分析PPB_Graphics3D_Proxy类的成员函数OnMessageReceived处理类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息的过程，如下所示：

bool PPB_Graphics3D_Proxy::OnMessageReceived(const IPC::Message& msg) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPB_Graphics3D_Proxy, msg)
#if !defined(OS_NACL)
    IPC_MESSAGE_HANDLER(PpapiHostMsg_PPBGraphics3D_Create,
                        OnMsgCreate)
    ......
#endif  // !defined(OS_NACL)

    ......
    IPC_MESSAGE_UNHANDLED(handled = false)

  IPC_END_MESSAGE_MAP()
  // FIXME(brettw) handle bad messages!
  return handled;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_graphics_3d_proxy.cc中。

从这里可以看到，PPB_Graphics3D_Proxy类的成员函数OnMessageReceived将类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息分发给另外一个成员函数OnMsgCreate处理，如下所示：

void PPB_Graphics3D_Proxy::OnMsgCreate(PP_Instance instance,
                                       HostResource share_context,
                                       const std::vector<int32_t>& attribs,
                                       HostResource* result) {
  ......

  thunk::EnterResourceCreation enter(instance);

  if (enter.succeeded()) {
    result->SetHostResource(
      instance,
      enter.functions()->CreateGraphics3DRaw(instance,
                                             share_context.host_resource(),
                                             &attribs.front()));
  }
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_graphics_3d_proxy.cc中。

参数instance要描述的是要创建OpenGL上下文的Plugin Instance在Render进程中对应的Proxy，也就是一个PepperPluginInstanceImpl对象。PPB_Graphics3D_Proxy类的成员函数OnMsgCreate首先是使用它构造一个EnterResourceCreation对象。前面提到，EnterResourceCreation类是用来封装资源创建接口API_ID_RESOURCE_CREATION的。因此，有了前面构造的EnterResourceCreation对象之后，PPB_Graphics3D_Proxy类的成员函数OnMsgCreate就可以使用API_ID_RESOURCE_CREATION接口来为参数instance描述的Plugin Instance创建一个OpenGL上下文了。

EnterResourceCreation对象在Render进程的构造过程与在Plugin进程的构造过程是不一样的。前面我们已经分析过EnterResourceCreation对象在Plugin进程的构造过程，接下来我们继续分析EnterResourceCreation对象在Render进程的构造过程，以便了解Render进程是如何实现API_ID_RESOURCE_CREATION接口的。

我们从EnterResourceCreation类的构造函数开始分析EnterResourceCreation对象在Render进程的构造过程，它的实现如下所示：

EnterResourceCreation::EnterResourceCreation(PP_Instance instance)
    : EnterBase(),
      functions_(PpapiGlobals::Get()->GetResourceCreationAPI(instance)) {
  ......
}

这个函数定义在文件external/chromium_org/ppapi/thunk/enter.cc中。

在Render进程中，存在一个HostGlobals单例对象。这个HostGlobals单例对象可以通过调用PpapiGlobals类的静态成员函数Get获得。HostGlobals类与前面提到的PluginGlobals类一样，都是从PpapiGlobals类继承下来的。

获得上述HostGlobals单例对象之后，EnterResourceCreation类的构造函数就调用它的成员函数GetResourceCreationAPI获得一个API_ID_RESOURCE_CREATION接口，如下所示：

ppapi::thunk::ResourceCreationAPI* HostGlobals::GetResourceCreationAPI(
    PP_Instance pp_instance) {
  PepperPluginInstanceImpl* instance = GetInstance(pp_instance);
  if (!instance)
    return NULL;
  return &instance->resource_creation();
}

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

HostGlobals类的成员函数GetResourceCreationAPI首先调用成员函数GetInstance获得参数pp_instance描述的一个Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象。有了这个PepperPluginInstanceImpl对象之后，就可以调用它的成员函数resource_creation获得一个API_ID_RESOURCE_CREATION接口，如下所示：

class CONTENT_EXPORT PepperPluginInstanceImpl
    : public base::RefCounted<PepperPluginInstanceImpl>,
      public NON_EXPORTED_BASE(PepperPluginInstance),
      public ppapi::PPB_Instance_Shared,
      public NON_EXPORTED_BASE(cc::TextureLayerClient),
      public RenderFrameObserver {
 public:
  ......

  ppapi::thunk::ResourceCreationAPI& resource_creation() {
    return *resource_creation_.get();
  }

  ......

 private:
  ......

  scoped_ptr<ppapi::thunk::ResourceCreationAPI> resource_creation_;

  ......
};

这个函数定义在文件external/chromium_org/content/renderer/pepper/pepper_plugin_instance_impl.h中。

PepperPluginInstanceImpl类的成员变量resource_creation_指向的是一个PepperInProcessResourceCreation对象。PepperPluginInstanceImpl类的成员函数resource_creation将这个PepperInProcessResourceCreation对象返回给调用者。这意味在Render进程中，API_ID_RESOURCE_CREATION接口是通过PepperInProcessResourceCreation类实现的。

这一步执行完成后，回到前面分析的PPB_Graphics3D_Proxy类的成员函数OnMsgCreate中。这时候就它构造了一个EnterResourceCreation对象，并且这个EnterResourceCreation对象的成员变量functions_指向了一个PepperInProcessResourceCreation对象。

PPB_Graphics3D_Proxy类的成员函数OnMsgCreate接下来会调用上述EnterResourceCreation对象的成员函数functions它的成员变量functions_指向的PepperInProcessResourceCreation对象。有了这个PepperInProcessResourceCreation对象之后，就可以调用它的成员函数CreateGraphics3DRaw为参数pp_instance描述的Plugin Instance创建一个OpenGL上下文。

PepperInProcessResourceCreation类的成员函数CreateGraphics3DRaw是从父类ResourceCreationImpl继承下来的，它的实现如下所示：

PP_Resource ResourceCreationImpl::CreateGraphics3DRaw(
    PP_Instance instance,
    PP_Resource share_context,
    const int32_t* attrib_list) {
  return PPB_Graphics3D_Impl::CreateRaw(instance, share_context, attrib_list);
}

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

ResourceCreationImpl类的成员函数CreateGraphics3DRaw调用PPB_Graphics3D_Impl类的静态成员函数CreateRaw为参数pp_instance描述的Plugin Instance创建一个OpenGL上下文，如下所示：

PP_Resource PPB_Graphics3D_Impl::CreateRaw(PP_Instance instance,
                                           PP_Resource share_context,
                                           const int32_t* attrib_list) {
  PPB_Graphics3D_API* share_api = NULL;
  if (share_context) {
    EnterResourceNoLock<PPB_Graphics3D_API> enter(share_context, true);
    if (enter.failed())
      return 0;
    share_api = enter.object();
  }
  scoped_refptr<PPB_Graphics3D_Impl> graphics_3d(
      new PPB_Graphics3D_Impl(instance));
  if (!graphics_3d->InitRaw(share_api, attrib_list))
    return 0;
  return graphics_3d->GetReference();
}

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

在Render进程中，Plugin使用的OpenGL上下文通过一个PPB_Graphics3D_Impl对象描述。因此，PPB_Graphics3D_Impl类的静态成员函数CreateRaw会创建一个PPB_Graphics3D_Impl对象，并且调用它的成员函数InitRaw对它进行初始化，也就是对它描述的OpenGL上下文进行初始化。初始化完成后，就会获得它的一个PP_Resource引用。这个引用将会返回给Plugin进程。Plugin进程以后就可以通过这个引用来使用前面创建出来的OpenGL上下文了。

接下来我们继续分析Render进程为Plugin创建的OpenGL上下文的初始化过程，也就是PPB_Graphics3D_Impl类的成员函数InitRaw的实现，如下所示：

bool PPB_Graphics3D_Impl::InitRaw(PPB_Graphics3D_API* share_context,
                                  const int32_t* attrib_list) {
  ......

  RenderThreadImpl* render_thread = RenderThreadImpl::current();
  ......

  channel_ = render_thread->EstablishGpuChannelSync(
      CAUSE_FOR_GPU_LAUNCH_PEPPERPLATFORMCONTEXT3DIMPL_INITIALIZE);
  ......

  command_buffer_ = channel_->CreateOffscreenCommandBuffer(
      surface_size, share_buffer, attribs, GURL::EmptyGURL(), gpu_preference);
  ......

  return true;
}

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

PPB_Graphics3D_Impl类的成员函数InitRaw首先调用RenderThreadImpl类的静态成员函数current获得一个RenderThreadImpl对象。这个RenderThreadImpl对象描述的是当前Render进程的Render线程。有了这个RenderThreadImpl对象之后，就可以调用它的成员函数EstablishGpuChannelSync创建一个GPU通道，也就是一个GpuChannelHost对象。这个GPU通道的详细创建过程，可以参考前面Chromium的GPU进程启动过程分析一文。

PPB_Graphics3D_Impl类的成员函数InitRaw接下来又会调用前面创建出来的GpuChannelHost对象的成员函数CreateOffscreenCommandBuffer请求GPU进程为其创建一个离屏渲染类型的OpenGL上下文。这个离屏渲染类型的OpenGL上下文是通过一个CommandBufferProxyImpl对象描述的。Render进程请求GPU进程创建OpenGL上下文的过程，可以参考前面Chromium硬件加速渲染的OpenGL上下文创建过程分析一文。以后Plugin执行GPU命令时，将会作用在上述离屏渲染的OpenGL上下文中。

这一步执行完成后，Render进程就为Plugin创建了一个OpenGL上下文。这个OpenGL上下文通过一个PPB_Graphics3D_Impl对象描述。这个PPB_Graphics3D_Impl对象会被分配一个ID，并且这个ID会返回给Plugin进程。如前所述，Plugin进程获得了这个ID之后，就会将其封装在一个Graphics3D对象中。这个Graphics3D对象是用来Plugin进程描述一个OpenGL上下文的。

回到前面分析的PPB_Graphics3D_Proxy类的成员函数CreateProxyResource中，这时候它就获得了一个OpenGL上下文之后。这个OpenGL上下文在Plugin进程中同样需要进行初始化。如前所述，这是通过调用ppapi::proxy::Graphics3D类的成员函数Init实现的。接下我们就继续分析Plugin进程初始化一个OpenGL上下文的过程，也就是分析ppapi::proxy::Graphics3D类的成员函数Init的实现，如下所示：

bool Graphics3D::Init(gpu::gles2::GLES2Implementation* share_gles2) {
  ......

  command_buffer_.reset(
      new PpapiCommandBufferProxy(host_resource(), dispatcher));

  return CreateGLES2Impl(kCommandBufferSize, kTransferBufferSize,
                         share_gles2);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_graphics_3d_proxy.cc中。

ppapi::proxy::Graphics3D类的成员函数Init首先会创建一个PpapiCommandBufferProxy对象。这个PpapiCommandBufferProxy对象是用来与前面在Render进程中创建的CommandBufferProxyImpl对象通信的，也就是前者会将提交给它的GPU命令转发给后者处理，后者又会将接收到的GPU命令发送给GPU进程执行。

ppapi::proxy::Graphics3D类的成员函数Init接下来又会调用成员函数CreateGLES2Impl根据上述PpapiCommandBufferProxy对象创建一个Command Buffer GL接口。有了这个Command Buffer GL接口之后，Plugin就可以调用它提供的OpenGL函数执行3D渲染了。

ppapi::proxy::Graphics3D类的成员函数CreateGLES2Impl是从父类PPB_Graphics3D_Shared继承下来的，它的实现如下所示：

bool PPB_Graphics3D_Shared::CreateGLES2Impl(
    int32 command_buffer_size,
    int32 transfer_buffer_size,
    gpu::gles2::GLES2Implementation* share_gles2) {
  gpu::CommandBuffer* command_buffer = GetCommandBuffer();
  DCHECK(command_buffer);

  // Create the GLES2 helper, which writes the command buffer protocol.
  gles2_helper_.reset(new gpu::gles2::GLES2CmdHelper(command_buffer));
  if (!gles2_helper_->Initialize(command_buffer_size))
    return false;

  // Create a transfer buffer used to copy resources between the renderer
  // process and the GPU process.
  const int32 kMinTransferBufferSize = 256 * 1024;
  const int32 kMaxTransferBufferSize = 16 * 1024 * 1024;
  transfer_buffer_.reset(new gpu::TransferBuffer(gles2_helper_.get()));
  ......

  // Create the object exposing the OpenGL API.
  gles2_impl_.reset(new gpu::gles2::GLES2Implementation(
      gles2_helper_.get(),
      share_gles2 ? share_gles2->share_group() : NULL,
      transfer_buffer_.get(),
      bind_creates_resources,
      lose_context_when_out_of_memory,
      GetGpuControl()));

  if (!gles2_impl_->Initialize(
           transfer_buffer_size,
           kMinTransferBufferSize,
           std::max(kMaxTransferBufferSize, transfer_buffer_size),
           gpu::gles2::GLES2Implementation::kNoLimit)) {
    return false;
  }

  ......

  return true;
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppb_graphics_3d_shared.cc。

在Chromium中，Command Buffer GL接口是通过GLES2Implementation类描述的。因此，PPB_Graphics3D_Shared类的成员函数CreateGLES2Impl将会创建一个GLES2Implementation对象，并且保存在成员变量gles2_impl_中。

创建这个GLES2Implementation对象需要一个Command Buffer和一个Transfer Buffer。前者通过一个GLES2CmdHelper对象描述，后者通过一个TransferBuffer对象描述的。在创建GLES2CmdHelper对象的过程中，又需要用到前面创建的一个PpapiCommandBufferProxy对象，以便可以将Plugin要执行的GPU命令转发给Render进程处理。这个PpapiCommandBufferProxy对象可以通过调用PPB_Graphics3D_Shared类的成员函数GetCommandBuffer获得。关于Command Buffer GL接口的创建和使用，可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

这一步执行完成后，回到前面分析的GLES2DemoInstance类的成员函数InitGL中，这时候它就创建了一个OpenGL上下文，并且这个OpenGL上下文已经初始化完成。接下来，GLES2DemoInstance类的成员函数InitGL会将前面创建出来的OpenGL上下文绑定到当前正在处理的Plugin Instance中去。执行了这个操作之后，Plugin Instance才可以在该OpenGL上下文中执行GPU命令。

给一个Plugin Instance绑定OpenGL上下文是通过调用pp::Instance类的成员函数BindGraphics实现的，如下所示：

bool Instance::BindGraphics(const Graphics3D& graphics) {
  if (!has_interface<PPB_Instance_1_0>())
    return false;
  return PP_ToBool(get_interface<PPB_Instance_1_0>()->BindGraphics(
      pp_instance(), graphics.pp_resource()));
}

这个函数定义在文件external/chromium_org/ppapi/cpp/instance.cc中。

pp::Instance类的成员函数BindGraphics需要通过PPB_INSTANCE_INTERFACE_1_0接口为当前正在处理的Plugin Instance绑定一个OpenGL上下文。这个OpenGL上下文由参数graphics指向的一个Graphics3D对象描述。

因此，pp::Instance类的成员函数BindGraphics首先会检查当前的Plugin进程是否支持PPB_INSTANCE_INTERFACE_1_0接口。如果支持的话，那么就会通过一个模板函数get_interface<PPB_Instance_1_0>获得该PPB_INSTANCE_INTERFACE_1_0接口，如下所示：

template <typename T> inline T const* get_interface() {
  static T const* funcs = reinterpret_cast<T const*>(
      pp::Module::Get()->GetBrowserInterface(interface_name<T>()));
  return funcs;
}

这个模板函数定义在文件external/chromium_org/ppapi/cpp/module_impl.h中。

这里的模板参数T为PPB_Instance_1_0，展开后得到模板函数get_interface<PPB_Instance_1_0>的具体实现为：

inline PPB_Instance_1_0 const* get_interface() {
  static PPB_Instance_1_0 const* funcs = reinterpret_cast<PPB_Instance_1_0 const*>(
      pp::Module::Get()->GetBrowserInterface(interface_name<PPB_Instance_1_0>()));
  return funcs;
}

它首先会调用另外一个模板函数interface_name<PPB_Instance_1_0>获得要获取的接口名称，接着再调用前面提到的pp::Module类的静态成员函数Get获得当前Plugin进程中的一个pp::Module单例对象。有了这个pp::Module单例对象之后，就可以调用它的成员函数GetBrowserInterface根据名称获得接口。

我们首先分析模板函数interface_name<PPB_Instance_1_0>的实现，以便知道要获取的接口名称是什么，如下所示：

template <> const char* interface_name<PPB_Instance_1_0>() {
  return PPB_INSTANCE_INTERFACE_1_0;
}

这个函数定义在文件external/chromium_org/ppapi/cpp/instance.cc中。

从这里可以看到，要获取的接口名称为PPB_INSTANCE_INTERFACE_1_0，也就我们要获取的是PPB_INSTANCE_INTERFACE_1_0接口。这个接口可以通过调用前面获得的pp::Module单例对象的GetBrowserInterface获得。

在前面Chromium插件（Plugin）模块（Module）加载过程分析一文中，我们已经分析过了pp::Module类的GetBrowserInterface的实现，并且我们也知道，在Plugin进程中，PPB_INSTANCE_INTERFACE_1_0接口是由一个PPB_Instance_1_0对象实现的。这个PPB_Graphics3D_1_0对象的定义如下所示：

const PPB_Instance_1_0 g_ppb_instance_thunk_1_0 = {
  &BindGraphics,
  &IsFullFrame
};

这个对象定义在文件external/chromium_org/ppapi/thunk/ppb_instance_thunk.cc中。

这个PPB_Instance_1_0对象的成员变量BindGraphics是一个函数指针。这个函数指针指向了函数BindGraphics。这个函数也是定义在文件ppb_instance_thunk.cc中。

回到pp::Instance类的成员函数BindGraphics中，现在我们就可以知道，它实际上是通过调用上述函数BindGraphics请求Render进程为当前正在处理的Plugin绑定一个OpenGL上下文的，如下所示：

PP_Bool BindGraphics(PP_Instance instance, PP_Resource device) {
  ......
  EnterInstance enter(instance);
  ......
  return enter.functions()->BindGraphics(instance, device);
}

这个函数定义在文件external/chromium_org/ppapi/thunk/ppb_instance_thunk.cc中。

函数BindGraphics需要通过另外一个接口API_ID_PPB_INSTANCE向Render进程发送一个IPC消息，以便请求后者为参数instance描述的Plugin Instance绑定另外一个参数device描述的OpenGL上下文。

函数BindGraphics是通过EnterInstance类来使用接口API_ID_RESOURCE_CREATION，因此它首先会构造一个EnterInstance对象，如下所示：

EnterInstance::EnterInstance(PP_Instance instance)
    : EnterBase(),
      functions_(PpapiGlobals::Get()->GetInstanceAPI(instance)) {
  ......
}

这个函数定义在文件external/chromium_org/ppapi/thunk/enter.cc中。

前面提到，在Plugin进程中，存在一个PluginGlobals单例对象。这个PluginGlobals单例对象可以通过调用PpapiGlobals类的静态成员函数获得。获得了这个PluginGlobals单例对象之后，EnterInstance类的构造函数就调用它的成员函数GetInstanceAPI获得一个API_ID_PPB_INSTANCE接口，如下所示：

thunk::PPB_Instance_API* PluginGlobals::GetInstanceAPI(PP_Instance instance) {
  PluginDispatcher* dispatcher = PluginDispatcher::GetForInstance(instance);
  if (dispatcher)
    return dispatcher->GetInstanceAPI();
  return NULL;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/plugin_globals.cc中。

PluginGlobals类的成员函数GetInstanceAPI首先调用PluginDispatcher类的静态成员函数GetForInstance获得一个与参数instance描述的Plugin Instance对应的PluginDispatcher对象。有了这个PluginDispatcher对象之后，再调用它的成员函数GetInstanceAPI获得一个API_ID_PPB_INSTANCE接口，如下所示：

thunk::PPB_Instance_API* PluginDispatcher::GetInstanceAPI() {
  return static_cast<PPB_Instance_Proxy*>(
      GetInterfaceProxy(API_ID_PPB_INSTANCE));
}

这个函数定义在文件external/chromium_org/ppapi/proxy/plugin_dispatcher.cc中。

PluginDispatcher类的成员函数GetInstanceAPI调用另外一个成员函数GetInterfaceProxy获得一个API_ID_PPB_INSTANCE接口。PluginDispatcher类的成员函数GetInterfaceProxy是从父类Dispatcher继承下来的。Dispatcher类的成员函数GetInterfaceProxy的实现，可以参考前面Chromium插件（Plugin）实例（Instance）创建过程分析一文中。

再结合前面Chromium插件（Plugin）模块（Module）加载过程分析一文，我们可以知道，在Plugin进程中，API_ID_PPB_INSTANCE接口被指定为模板函数ProxyFactory<PPB_Instance_Proxy>。Dispatcher类的成员函数GetInterfaceProxy将会调用这个函数创建一个PPB_Instance_Proxy对象。这意味着在Plugin进程中，API_ID_PPB_INSTANCE接口是通过一个PPB_Instance_Proxy对象实现的。这个PPB_Instance_Proxy对象会返回给EnterInstance类的构造函数。

回到前面分析的函数BindGraphics，这时候就它构造了一个EnterInstance对象，并且这个EnterInstance对象的成员变量functions_指向了一个PPB_Instance_Proxy对象。这个PPB_Instance_Proxy对象可以通过调用上述构造的EnterInstance对象的成员函数functions获得。有了这个PPB_Instance_Proxy对象之后，函数BindGraphics就可以调用它的成员函数BindGraphics向Render进程发送一个IPC消息，以便请求它为当前正在处理的Plugin绑定一个OpenGL上下文，如下所示：

PP_Bool PPB_Instance_Proxy::BindGraphics(PP_Instance instance,
                                         PP_Resource device) {
  // If device is 0, pass a null HostResource. This signals the host to unbind
  // all devices.
  HostResource host_resource;
  PP_Resource pp_resource = 0;
  if (device) {
    Resource* resource =
        PpapiGlobals::Get()->GetResourceTracker()->GetResource(device);
    if (!resource || resource->pp_instance() != instance)
      return PP_FALSE;
    host_resource = resource->host_resource();
    pp_resource = resource->pp_resource();
  } else {
    // Passing 0 means unbinding all devices.
    dispatcher()->Send(new PpapiHostMsg_PPBInstance_BindGraphics(
        API_ID_PPB_INSTANCE, instance, 0));
    return PP_TRUE;
  }

  // We need to pass different resource to Graphics 2D and 3D right now.  Once
  // 3D is migrated to the new design, we should be able to unify this.
  EnterResourceNoLock<PPB_Compositor_API> enter_compositor(device, false);
  EnterResourceNoLock<PPB_Graphics2D_API> enter_2d(device, false);
  EnterResourceNoLock<PPB_Graphics3D_API> enter_3d(device, false);
  if (enter_compositor.succeeded() || enter_2d.succeeded()) {
    dispatcher()->Send(new PpapiHostMsg_PPBInstance_BindGraphics(
        API_ID_PPB_INSTANCE, instance, pp_resource));
    return PP_TRUE;
  } else if (enter_3d.succeeded()) {
    dispatcher()->Send(new PpapiHostMsg_PPBInstance_BindGraphics(
        API_ID_PPB_INSTANCE, instance, host_resource.host_resource()));
    return PP_TRUE;
  }
  return PP_FALSE;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_instance_proxy.cc中。

PPB_Instance_Proxy类的成员函数BindGraphics首先判断参数device的值是否不等于NULL。如果不等于NULL，那么它描述的就是一个OpenGL上下文，并且这个OpenGL上下文要与参数instance描述的Plugin Instance进行绑定。否则的话，就说明要将参数instance描述的Plugin Instance当前使用的OpenGL上下文设置为NULL。

在我们这个情景中，参数device的值不等于NULL。在这种情况下，PPB_Instance_Proxy类的成员函数BindGraphics首先会根据这个参数获得一个Resource对象。这个Resource对象描述的就是一个OpenGL上下文。这个OpenGL上下文可能是用来执行2D渲染的，也可能是用来执行3D渲染的。PPB_Instance_Proxy类的成员函数BindGraphics会对这两种情况进行区别，不过最终都会向Render进程发送一个类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息。这个IPC消息携带了3个参数：

1. API_ID_PPB_INSTANCE，要求Render进程将该IPC消息分发给API_ID_PPB_INSTANCE接口处理。

2. instance，表示目标Plugin Instance。

3. 通过参数device获得一个PP_Resource对象，描述的是一个要与目标Plugin Instance进行绑定的OpenGL上下文。

Render进程接收类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息的过程与前面分析的类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息是类似的，只不过前者最后会分发给API_ID_PPB_INSTANCE接口处理，而后者会分发给API_ID_PPB_GRAPHICS_3D接口处理。它们在Render进程的分发过程都可以参考在前面Chromium插件（Plugin）实例（Instance）创建过程分析一文提到的类型为PpapiMsg_PPPInstance_DidCreate的IPC消息在Plugin进程的分发过程。

从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文还可以知道，在Render进程中，API_ID_PPB_INSTANCE接口是由一个PPB_Instance_Proxy对象实现的，也就是Render进程会将类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息分发给该PPB_Instance_Proxy对象处理，这是通过调用它的成员函数OnMessageReceived实现的，如下所示：

bool PPB_Instance_Proxy::OnMessageReceived(const IPC::Message& msg) {
  ......

  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPB_Instance_Proxy, msg)
#if !defined(OS_NACL)
    ......
    IPC_MESSAGE_HANDLER(PpapiHostMsg_PPBInstance_BindGraphics,
                        OnHostMsgBindGraphics)
    ......
#endif  // !defined(OS_NACL)

    ......

    IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()
  return handled;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_instance_proxy.cc中。

从这里可以看到，PPB_Instance_Proxy类的成员函数OnMessageReceived会将类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息分发给另外一个成员函数OnHostMsgBindGraphics处理，如下所示：

void PPB_Instance_Proxy::OnHostMsgBindGraphics(PP_Instance instance,
                                               PP_Resource device) {
  // Note that we ignroe the return value here. Otherwise, this would need to
  // be a slow sync call, and the plugin side of the proxy will have already
  // validated the resources, so we shouldn't see errors here that weren't
  // already caught.
  EnterInstanceNoLock enter(instance);
  if (enter.succeeded())
    enter.functions()->BindGraphics(instance, device);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_instance_proxy.cc中。

参数instance要描述的是要绑定OpenGL上下文的Plugin Instance在Render进程中对应的Proxy，也就是一个PepperPluginInstanceImpl对象。PPB_Instance_Proxy类的成员函数OnHostMsgBindGraphics首先是使用它构造一个EnterInstanceNoLock对象。这个EnterInstanceNoLock对象是用来封装一个Instance API的。这个Instance API可以用来给一个Plugin Instance Proxy绑定一个OpenGL上下文。

接下来我们从EnterInstanceNoLock类的构造函数开始分析一个EnterInstanceNoLock对象的构造过程，如下所示：

EnterInstanceNoLock::EnterInstanceNoLock(PP_Instance instance)
    : EnterBase(),
      functions_(PpapiGlobals::Get()->GetInstanceAPI(instance)) {
  ......
}

这个函数定义在文件external/chromium_org/ppapi/thunk/enter.cc中。

前面提到，在Render进程中，存在一个HostGlobals单例对象。这个HostGlobals单例对象可以通过调用PpapiGlobals类的静态成员函数Get获得。获得了这个HostGlobals单例对象之后，EnterInstanceNoLock类的构造函数就调用它的成员函数GetInstanceAPI获得一个Instance API，如下所示：

ppapi::thunk::PPB_Instance_API* HostGlobals::GetInstanceAPI(
    PP_Instance instance) {
  // The InstanceAPI is just implemented by the PluginInstance object.
  return GetInstance(instance);
}

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

HostGlobals类的成员函数GetInstanceAPI调用另外一个成员函数GetInstance获得参数instance描述的一个Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象，如下所示：

PepperPluginInstanceImpl* HostGlobals::GetInstance(PP_Instance instance) {
  ......
  InstanceMap::iterator found = instance_map_.find(instance);
  if (found == instance_map_.end())
    return NULL;
  return found->second;
}

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

在Render进程中，每一个Plugin Instance Proxy都会以分配给它的ID保存在HostGlobals类的成员变量instance_map_描述的一个std::map中。因此，给出一个ID，就可以在这个std::map中找到它对应的Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象。

在Render进程中，Instance API是通过PPB_Instance_API类描述的。PepperPluginInstanceImpl类又是从PPB_Instance_API类继承下来的。因此，一个PepperPluginInstanceImpl对象可以当作一个Instance API使用。这个PepperPluginInstanceImpl对象将会返回给EnterInstanceNoLock类的构造函数，并且保存在EnterInstanceNoLock类的成员变量functions_中。

这一步执行完成后，回到前面分析的PPB_Instance_Proxy类的成员函数OnMessageReceived中。这时候就它构造了一个EnterInstanceNoLock对象，并且这个EnterInstanceNoLock对象的成员变量functions_指向了一个PepperInProcessResourceCreation对象。注意，这个PepperPluginInstanceImpl对象在用作Instance API的同时，也是即将要绑定OpenGL上下文的Plugin Instance Proxy。这个绑定操作是通过调用它的成员函数BindGraphics实现的，如下所示：

PP_Bool PepperPluginInstanceImpl::BindGraphics(PP_Instance instance,
                                               PP_Resource device) {
  ......

  scoped_refptr<ppapi::Resource> old_graphics = bound_graphics_3d_.get();
  if (bound_graphics_3d_.get()) {
    bound_graphics_3d_->BindToInstance(false);
    bound_graphics_3d_ = NULL;
  }
  if (bound_graphics_2d_platform_) {
    bound_graphics_2d_platform_->BindToInstance(NULL);
    bound_graphics_2d_platform_ = NULL;
  }
  if (bound_compositor_) {
    bound_compositor_->BindToInstance(NULL);
    bound_compositor_ = NULL;
  }

  ......

  const ppapi::host::PpapiHost* ppapi_host =
      RendererPpapiHost::GetForPPInstance(instance)->GetPpapiHost();
  ppapi::host::ResourceHost* host = ppapi_host->GetResourceHost(device);
  PepperGraphics2DHost* graphics_2d = NULL;
  PepperCompositorHost* compositor = NULL;
  if (host) {
    if (host->IsGraphics2DHost()) {
      graphics_2d = static_cast<PepperGraphics2DHost*>(host);
    } else if (host->IsCompositorHost()) {
      compositor = static_cast<PepperCompositorHost*>(host);
    } 
    ......
  }

  EnterResourceNoLock enter_3d(device, false);
  PPB_Graphics3D_Impl* graphics_3d =
      enter_3d.succeeded()
          ? static_cast(enter_3d.object())
          : NULL;
  
  if (compositor) {
    if (compositor->BindToInstance(this)) {
      bound_compositor_ = compositor;
      ......
      return PP_TRUE;
    }
  } else if (graphics_2d) {
    if (graphics_2d->BindToInstance(this)) {
      bound_graphics_2d_platform_ = graphics_2d;
      ......
      return PP_TRUE;
    }
  } else if (graphics_3d) {
    // Make sure graphics can only be bound to the instance it is
    // associated with.
    if (graphics_3d->pp_instance() == pp_instance() &&
        graphics_3d->BindToInstance(true)) {
      bound_graphics_3d_ = graphics_3d;
      ......
      return PP_TRUE;
    }
  }

  // The instance cannot be bound or the device is not a valid resource type.
  return PP_FALSE;
}

这个函数定义在文件external/chromium_org/content/renderer/pepper/pepper_plugin_instance_impl.cpp。

Plugin Instance不仅可以将UI渲染在一个2D上下文或者一个3D上下文中，还可以渲染在一个Compositor上下文中。一个2D上下文和一个3D上下文描述的都只是一个Layer，而一个Compositor上下文可以描述多个Layer。也就是说，Plugin Instance可以通过Compositor上下文将自己的UI划分为多个Layer进行渲染。Chromium提供了一个PPB_COMPOSITOR_INTERFACE_0_1接口，Plugin Instance可以通过这个接口为自己创建一个Compositor上下文。

其中，2D上下文通过一个PepperGraphics2DHost类描述，3D上下文通过PPB_Graphics3D_Impl类描述，而Compositor上下文通过PepperCompositorHost类描述。PepperPluginInstanceImpl类分别通过bound_graphics_2d_platform_、bound_graphics_3d_和bound_compositor_三个成员变量描述上述三种不同的绘图上下文。

PepperPluginInstanceImpl类的成员函数BindGraphics主要做的工作就是将参数device描述的绘图上下文绑定为当前正在处理的Plugin Instance Proxy的绘图上下文。如果当前正在处理的Plugin Instance Proxy以前绑定过其它的绘图上下文，那么PepperPluginInstanceImpl类的成员函数BindGraphics就会先解除对它们的绑定。

PepperPluginInstanceImpl类的成员函数BindGraphics接下来再判断参数device描述的绘图上下文是2D上下文、3D上下文，还是Compositor上下文，并且获取它所对应的PepperGraphics2DHost对象、PPB_Graphics3D_Impl对象和PepperCompositorHost对象，然后保存在对应的成员变量中。这样，当前正在处理的Plugin Instance Proxy就知道了自己最新绑定的绘图上下文是什么。最后，这些获得的PepperGraphics2DHost对象、PPB_Graphics3D_Impl对象和PepperCompositorHost对象的成员函数BindToInstance也会被调用，表示它们当前处于被绑定状态。

在我们这个情景中，参数device描述的绘图上下文是一个3D上下文，也就是一个3D的OpenGL上下文。因此， PepperPluginInstanceImpl类的成员函数BindGraphics最终会获得一个PPB_Graphics3D_Impl对象，并且保存在成员变量bound_graphics_3d_中。最后，这个PPB_Graphics3D_Impl对象的成员函数BindToInstance会被调用，表示它当前处于被绑定的状态，如下所示：

bool PPB_Graphics3D_Impl::BindToInstance(bool bind) {
  bound_to_instance_ = bind;
  return true;
}

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

从前面的调用过程可以知道，参数bind的值等于true。这时候PPB_Graphics3D_Impl类的成员变量bound_to_instance_的值也会被设置为true，表示当前正在处理的PPB_Graphics3D_Impl对象描述的3D上下文处于被绑定状态。

这一步执行完成后，GLES2DemoInstance类就通过PPB_GRAPHICS_3D_INTERFACE_1_0和PPB_INSTANCE_INTERFACE_1_0这两个接口创建和绑定了一个OpenGL上下文，也就是初始化好一个OpenGL环境。接下来，GLES2DemoInstance类就可以通过PPB_OPENGLES2_INTERFACE接口进行3D渲染了。这个PPB_OPENGLES2_INTERFACE接口是在GLES2DemoInstance类的构造函数中获取的，如下所示：

GLES2DemoInstance::GLES2DemoInstance(PP_Instance instance, pp::Module* module)
    : pp::Instance(instance), pp::Graphics3DClient(this),
      callback_factory_(this),
      module_(module),
      context_(NULL),
      fullscreen_(false) {
  assert((gles2_if_ = static_cast<const PPB_OpenGLES2*>(
      module->GetBrowserInterface(PPB_OPENGLES2_INTERFACE))));
  ......
}

这个函数定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

GLES2DemoInstance类的构造函数是通过调用参数module指向的一个pp::Module对象的成员函数GetBrowserInterface获取PPB_OPENGLES2_INTERFACE接口的。在前面Chromium插件（Plugin）模块（Module）加载过程分析一文中，我们已经分析过了pp::Module类的GetBrowserInterface的实现，并且我们也知道，在Plugin进程中，PPB_OPENGLES2_INTERFACE接口是由一个PPB_OpenGLES2对象实现的。这个PPB_OpenGLES2对象的定义如下所示：

  static const struct PPB_OpenGLES2 ppb_opengles2 = {  
      &ActiveTexture,                       &AttachShader,  
      &BindAttribLocation,                  &BindBuffer,  
      &BindFramebuffer,                     &BindRenderbuffer,  
      &BindTexture,                         &BlendColor,  
      &BlendEquation,                       &BlendEquationSeparate,  
      &BlendFunc,                           &BlendFuncSeparate,  
      &BufferData,                          &BufferSubData,  
      &CheckFramebufferStatus,              &Clear,  
      ......  
      &UseProgram,                          &ValidateProgram,  
      &VertexAttrib1f,                      &VertexAttrib1fv,  
      &VertexAttrib2f,                      &VertexAttrib2fv,  
      &VertexAttrib3f,                      &VertexAttrib3fv,  
      &VertexAttrib4f,                      &VertexAttrib4fv,  
      &VertexAttribPointer,                 &Viewport};

这个对象定义在文件这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppb_opengles2_shared.cc中。

从这里我们就可以看到PPB_OPENGLES2_INTERFACE接口提供的函数，例如函数Clear，就相当于是OpenGL函数glClear。

有了这个PPB_OPENGLES2_INTERFACE接口之后，GLES2DemoInstance类就会在成员函数FlickerAndPaint中调用它提供的函数进行3D渲染，如下所示：

void GLES2DemoInstance::FlickerAndPaint(int32_t result, bool paint_blue) {
  ......

  float r = paint_blue ? 0 : 1;
  float g = 0;
  float b = paint_blue ? 1 : 0;
  float a = 0.75;
  gles2_if_->ClearColor(context_->pp_resource(), r, g, b, a);
  gles2_if_->Clear(context_->pp_resource(), GL_COLOR_BUFFER_BIT);
  ......

  context_->SwapBuffers(cb);
  ......
}

这个函数定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

GLES2DemoInstance类的成员函数FlickerAndPaint执行的3D渲染很简单，仅仅是调用PPB_OPENGLES2_INTERFACE接口提供的函数ClearColor和Clear绘制一个背景色，相当于是调用了OpenGL函数glClearColor和glClear绘制一个背景色。在实际开发中，我们可以调用PPB_OPENGLES2_INTERFACE接口提供的其它函数完成更复杂的3D渲染效果。

从前面的分析可以知道，GLES2DemoInstance类的成员变量context_指向的是一个pp::Graphics3D对象。这个Graphics3D描述的是一个OpenGL上下文。每完成一帧渲染，GLES2DemoInstance类的成员函数FlickerAndPaint都需要调用这个pp::Graphics3D对象的成员函数SwapBuffers，用来交换当前使用的OpenGL上下文的前后两个缓冲区，相当于是调用了EGL函数eglSwapBuffers。

接下来，我们就以PPB_OPENGLES2_INTERFACE接口提供的函数Clear的执行过程为例，分析Plugin是如何通过PPB_OPENGLES2_INTERFACE接口执行3D渲染操作的，它的实现如下所示：

void Clear(PP_Resource context_id, GLbitfield mask) {
  Enter3D enter(context_id, true);
  if (enter.succeeded()) {
    ToGles2Impl(&enter)->Clear(mask);
  }
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppb_opengles2_shared.cc中。

Enter3D定义为一个thunk::EnterResource<thunk::PPB_Graphics3D_API>类，如下所示：

typedef thunk::EnterResource<thunk::PPB_Graphics3D_API> Enter3D;

这个类定义在文件external/chromium_org/ppapi/shared_impl/ppb_opengles2_shared.cc中。

回到函数Clear中，它的参数context_id描述的是一个OpenGL上下文资源ID。函数Clear首先将这个资源ID封装在一个EnterResource<thunk::PPB_Graphics3D_API>对象中，如下所示：

template<typename ResourceT, bool lock_on_entry = true>
class EnterResource
    : public subtle::LockOnEntry<lock_on_entry>,  // Must be first; see above.
      public subtle::EnterBase {
 public:
  EnterResource(PP_Resource resource, bool report_error)
      : EnterBase(resource) {
    Init(resource, report_error);
  }
  ......
};

这个函数定义在文件external/chromium_org/ppapi/thunk/enter.h中。

EnterResource<thunk::PPB_Graphics3D_API>类的构造函数首先会调用父类EnterBase的构造函数。在调用的时候，会将参数resource描述的资源ID传递进去。EnterBase的构造函数通过这个资源ID获得对应的资源对象，保存在成员变量resource_中，如下所示：

EnterBase::EnterBase(PP_Resource resource)
    : resource_(GetResource(resource)),
      retval_(PP_OK) {
  PpapiGlobals::Get()->MarkPluginIsActive();
}

这个函数定义在文件external/chromium_org/ppapi/thunk/enter.cc中。

从前面的分析可以知道，这个资源对象实际上就是一个ppapi::proxy::Graphics3D对象。与此同时，EnterBase的构造函数会通过调用Plugin进程的一个PluginGlobals单例对象的成员函数MarkPluginIsActive将当前正在执行3D渲染操作的Plugin标记为Active状态。

回到EnterResource<thunk::PPB_Graphics3D_API>类的构造函数中，它接下来又会调用另外一个成员函数Init执行其它的初始化工作，如下所示：

template<typename ResourceT, bool lock_on_entry = true>
class EnterResource
    : public subtle::LockOnEntry<lock_on_entry>,  // Must be first; see above.
      public subtle::EnterBase {
 public:
  .......

  ResourceT* object() { return object_; }
  ......

 private:
  void Init(PP_Resource resource, bool report_error) {
    if (resource_)
      object_ = resource_->GetAs<ResourceT>();
    ......
  }

  ResourceT* object_;

  ......
};

这个函数定义在文件external/chromium_org/ppapi/thunk/enter.h中。

EnterResource<thunk::PPB_Graphics3D_API>类的成员函数Init主要是将从父类EnterBase继承下来的成员变量resource_指向的ppapi::proxy::Graphics3D对象转换为一个thunk::PPB_Graphics3D_API对象，并且保存在成员变量object_中。这个thunk::PPB_Graphics3D_API对象以后可以通过调用EnterResource<thunk::PPB_Graphics3D_API>类的成员函数object获得。

注意，ppapi::proxy::Graphics3D类是从ppapi::PPB_Graphics3D_Shared类继承下来的，ppapi::PPB_Graphics3D_Shared类又是从thunk::PPB_Graphics3D_API类继承下来的，因此，我们可以将ppapi::proxy::Graphics3D对象转换为一个thunk::PPB_Graphics3D_API对象。

这一步执行完成后，回到前面分析的函数函数Clear中，这时候它就构造了一个EnterResource<thunk::PPB_Graphics3D_API>对象，并且这个EnterResource<thunk::PPB_Graphics3D_API>对象的成员变量object_指向了一个thunk::PPB_Graphics3D_API对象。函数Clear接下来又会调用另外一个函数ToGles2Impl从前面构造的EnterResource<thunk::PPB_Graphics3D_API>对象中获得一个GLES2Implementation对象，如下所示：

gpu::gles2::GLES2Implementation* ToGles2Impl(Enter3D* enter) {
  ......
  return static_cast<PPB_Graphics3D_Shared*>(enter->object())->gles2_impl();
}

这个函数定义在文件ternal/chromium_org/ppapi$ vi shared_impl/ppb_opengles2_shared.cc中。

函数ToGles2Impl首先调用参数enter指向的EnterResource<thunk::PPB_Graphics3D_API>对象的成员函数object获得它的成员变量object_所指向的一个thunk::PPB_Graphics3D_API对象。

前面提到，由于EnterResource<thunk::PPB_Graphics3D_API>类的成员变量object_指向的实际上是一个ppapi::proxy::Graphics3D对象，并且ppapi::proxy::Graphics3D类是从ppapi::PPB_Graphics3D_Shared类继承下来的。因此函数ToGles2Impl又可以将它获得的thunk::PPB_Graphics3D_API对象转换为一个ppapi::PPB_Graphics3D_Shared对象。

有了这个ppapi::PPB_Graphics3D_Shared对象之后，函数ToGles2Impl就可以调用它的成员函数gles2_impl获得它内部维护的一个GLES2Implementation对象。这个GLES2Implementation对象就是在前面分析的ppapi::proxy::Graphics3D类的成员函数CreateGLES2Impl中创建的。

函数ToGles2Impl最后会将获得的GLES2Implementation对象返回给函数Clear。函数Clear获得了这个GLES2Implementation对象之后，就会调用它的成员函数Clear给参数context_id描述的OpenGL上下文设置一个背景色。

从前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文可以知道，当我们调用GLES2Implementation类的成员函数执行GPU命令时，这些GPU命令实际上只是写入到了一个Command Buffer中。这个Command Buffer在合适的时候将会调用它的成员函数WaitForGetOffsetInRange通知GPU进程执行它里面的GPU命令。

从前面的分析可以知道，为Plugin创建的GLES2Implementation对象所用的Command Buffer是通过一个PpapiCommandBufferProxy对象描述的。当这个WaitForGetOffsetInRange对象的成员函数WaitForGetOffsetInRange被调用的时候，它实际上只是向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange的IPC消息，如下所示：

void PpapiCommandBufferProxy::WaitForTokenInRange(int32 start, int32 end) {
  ......

  bool success;
  gpu::CommandBuffer::State state;
  if (Send(new PpapiHostMsg_PPBGraphics3D_WaitForTokenInRange(
          ppapi::API_ID_PPB_GRAPHICS_3D,
          resource_,
          start,
          end,
          &state,
          &success)))
    UpdateState(state, success);
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppapi_command_buffer_proxy.cc中。

这个类型为PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange的IPC消息携带了一个参数ppapi::API_ID_PPB_GRAPHICS_3D，表示Render进程接收到这个IPC消息之后，要分发一个API_ID_PPB_GRAPHICS_3D接口处理。

前面提到，在Render进程中，API_ID_PPB_GRAPHICS_3D接口是由一个PPB_Graphics3D_Proxy对象实现的，也就是Render进程会将类型为PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange的IPC消息分发给该PPB_Graphics3D_Proxy对象处理，这是通过调用它的成员函数OnMessageReceived实现的，如下所示：

bool PPB_Graphics3D_Proxy::OnMessageReceived(const IPC::Message& msg) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPB_Graphics3D_Proxy, msg)
#if !defined(OS_NACL)
    ......
    IPC_MESSAGE_HANDLER(PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange,
                        OnMsgWaitForGetOffsetInRange)
    ......
#endif  // !defined(OS_NACL)

    ......
    IPC_MESSAGE_UNHANDLED(handled = false)

  IPC_END_MESSAGE_MAP()
  // FIXME(brettw) handle bad messages!
  return handled;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_graphics_3d_proxy.cc。

从这里可以看到，PPB_Graphics3D_Proxy类的成员函数OnMessageReceived会将类型为PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange的IPC消息分发给另外一个成员函数OnMsgWaitForGetOffsetInRange处理，如下所示：

void PPB_Graphics3D_Proxy::OnMsgWaitForGetOffsetInRange(
    const HostResource& context,
    int32 start,
    int32 end,
    gpu::CommandBuffer::State* state,
    bool* success) {
  EnterHostFromHostResource<PPB_Graphics3D_API> enter(context);
  ......
  *state = enter.object()->WaitForGetOffsetInRange(start, end);
  *success = true;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_graphics_3d_proxy.cc。

从前面的分析可以知道，参数context描述的OpenGL上下文在Render进程中用一个PPB_Graphics3D_Impl对象描述。PPB_Graphics3D_Proxy类的成员函数OnMsgWaitForGetOffsetInRange会通过构造一个EnterHostFromHostResource<PPB_Graphics3D_API>对象来获得这个PPB_Graphics3D_Impl对象，并且会调用这个PPB_Graphics3D_Impl对象的成员函数WaitForGetOffsetInRange，用来通知它将Plugin写入在Command Buffer中的GPU命令发送给GPU进程处理。

PPB_Graphics3D_Impl类的成员函数WaitForGetOffsetInRange的实现如下所示：

gpu::CommandBuffer::State PPB_Graphics3D_Impl::WaitForGetOffsetInRange(
    int32_t start,
    int32_t end) {
  GetCommandBuffer()->WaitForGetOffsetInRange(start, end);
  return GetCommandBuffer()->GetLastState();
}

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

PPB_Graphics3D_Impl类的成员函数WaitForGetOffsetInRange首先调用成员函数GetCommandBuffer获得一个CommandBuffer对象，如下所示：

gpu::CommandBuffer* PPB_Graphics3D_Impl::GetCommandBuffer() {
  return command_buffer_;
}

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

PPB_Graphics3D_Impl类的成员函数GetCommandBuffer返回的是成员变量command_buffer_指向的一个CommandBuffer对象。从前面的分析可以知道，这个CommandBuffer对象实现上是一个CommandBufferProxyImpl对象，它是在前面分析的PPB_Graphics3D_Impl类的成员函数InitRaw中创建的。

回到PPB_Graphics3D_Impl类的成员函数WaitForGetOffsetInRange中，它获得了一个CommandBufferProxyImpl对象之后，就会调用它的成员函数WaitForGetOffsetInRange通知GPU进程执行Plugin写入在Command Buffer中的GPU命令。这个通知过程可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

这一步执行完成后，回到前面分析的GLES2DemoInstance类的成员函数FlickerAndPaint中，它通过PPB_OPENGLES2_INTERFACE接口提供的函数渲染好一帧后，就会调用其成员变量context_指向的一个pp::Graphics3D对象的成员函数SwapBuffers交换Plugin当前使用的OpenGL上下文的前后两个缓冲区，也就是相当于是执行EGL函数eglSwapBuffers。

接下来，我们就从pp::Graphics3D类的成员函数SwapBuffers开始，分析Plugin交换当前使用的OpenGL上下文的前后两个缓冲区的过程，如下所示：

int32_t Graphics3D::SwapBuffers(const CompletionCallback& cc) {
  ......

  return get_interface<PPB_Graphics3D_1_0>()->SwapBuffers(
      pp_resource(),
      cc.pp_completion_callback());
}

这个函数定义在文件external/chromium_org/ppapi/cpp/graphics_3d.cc中。

pp::Graphics3D类的成员函数SwapBuffers首先调用我们前面分析过的模板函数get_interface<PPB_Graphics3D_1_0>获得一个PPB_GRAPHICS_3D_INTERFACE_1_0接口。获得了PPB_GRAPHICS_3D_INTERFACE_1_0接口之后，再调用它提供的函数SwapBuffers请求Render进程交换正在处理的pp::Graphics3D对象描述的OpenGL上下文的前后缓冲区。

PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的函数SwapBuffers的实现如下所示：

int32_t SwapBuffers(PP_Resource context,
                    struct PP_CompletionCallback callback) {
  ......
  EnterResource<PPB_Graphics3D_API> enter(context, callback, true);
  if (enter.failed())
    return enter.retval();
  return enter.SetResult(enter.object()->SwapBuffers(enter.callback()));
}

这个函数定义在文件external/chromium_org/ppapi/thunk/ppb_graphics_3d_thunk.cc中。

与前面分析的PPB_OPENGLES2_INTERFACE接口提供的函数Clear类似，PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的函数SwapBuffers也是通过构造一个EnterResource<thunk::PPB_Graphics3D_API>对象来获得参数context描述的一个OpenGL上下文资源对象，也就是一个ppapi::proxy::Graphics3D对象。有了这个ppapi::proxy::Graphics3D对象之后，就可以调用它的成员函数SwapBuffers请求Render进程交换它描述的OpenGL上下文的前后缓冲区了。

ppapi::proxy::Graphics3D类的成员函数SwapBuffers是从父类ppapi::PPB_Graphics3D_Shared继承下来的，它的实现如下所示：

int32_t PPB_Graphics3D_Shared::SwapBuffers(
    scoped_refptr<TrackedCallback> callback) {
  ......
  return DoSwapBuffers();
}

这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppb_graphics_3d_shared.cc中。

ppapi::proxy::Graphics3D类的成员函数SwapBuffers又会调用由子类实现的成员函数DoSwapBuffers请求Render进程交换当前正在处理的ppapi::proxy::Graphics3D对象描述的OpenGL上下文的前后缓冲区。

在我们这个情景中，这个子类即为ppapi::proxy::Graphics3D，因此接下来ppapi::proxy::Graphics3D类的成员函数DoSwapBuffers会被调用，它的实现如下所示：

int32 Graphics3D::DoSwapBuffers() {
  gles2_impl()->SwapBuffers();
  IPC::Message* msg = new PpapiHostMsg_PPBGraphics3D_SwapBuffers(
      API_ID_PPB_GRAPHICS_3D, host_resource());
  msg->set_unblock(true);
  PluginDispatcher::GetForResource(this)->Send(msg);

  return PP_OK_COMPLETIONPENDING;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_graphics_3d_proxy.cc中。

ppapi::proxy::Graphics3D类的成员函数DoSwapBuffers首先是通过调用成员函数gles2_impl获得前面为Plugin创建的一个Command Buffer GL接口。有了这个Command Buffer GL接口之后，就可以调用它的成员函数SwapBuffers向Command Buffer写入一个gles2::cmds::SwapBuffers命令。GPU进程在执行这个命令的时候，就会交换当前正在处理的ppapi::proxy::Graphics3D对象描述的OpenGL上下文的前后缓冲区。

ppapi::proxy::Graphics3D类的成员函数DoSwapBuffers接下来又会调用PluginDispatcher类的静态成员函数GetForResource获得与当前正在处理的Plugin对应的一个PluginDispatcher对象，并且通过这个PluginDispatcher对象向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_SwapBuffers的IPC消息，用来通知Render进程更新当前正在处理的Plugin在网页上的视图。这个IPC消息包含两个参数：

1. API_ID_PPB_GRAPHICS_3D，表示Render进程要将该IPC消息分发给API_ID_PPB_GRAPHICS_3D接口处理。

2. 通过调用成员函数host_resource获得的一个HostResource对象，这个HostResource对象描述的就是要交换前面缓冲区的OpenGL上下文。

前面提到，在Render进程中，API_ID_PPB_GRAPHICS_3D接口是由一个PPB_Graphics3D_Proxy对象实现的，也就是Render进程会将类型为PpapiHostMsg_PPBGraphics3D_SwapBuffers的IPC消息分发给该PPB_Graphics3D_Proxy对象处理，这是通过调用它的成员函数OnMessageReceived实现的，如下所示：

bool PPB_Graphics3D_Proxy::OnMessageReceived(const IPC::Message& msg) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPB_Graphics3D_Proxy, msg)
#if !defined(OS_NACL)
    ......
    IPC_MESSAGE_HANDLER(PpapiHostMsg_PPBGraphics3D_SwapBuffers,
                        OnMsgSwapBuffers)
    ......
#endif  // !defined(OS_NACL)

    ......
    IPC_MESSAGE_UNHANDLED(handled = false)

  IPC_END_MESSAGE_MAP()
  // FIXME(brettw) handle bad messages!
  return handled;
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_graphics_3d_proxy.cc中。

从这里可以看到，PPB_Graphics3D_Proxy类的成员函数OnMessageReceived会将类型为PpapiHostMsg_PPBGraphics3D_SwapBuffers的IPC消息分发给另外一个成员函数OnMsgSwapBuffers处理，如下所示：

void PPB_Graphics3D_Proxy::OnMsgSwapBuffers(const HostResource& context) {
  EnterHostFromHostResourceForceCallback<PPB_Graphics3D_API> enter(
      context, callback_factory_,
      &PPB_Graphics3D_Proxy::SendSwapBuffersACKToPlugin, context);
  if (enter.succeeded())
    enter.SetResult(enter.object()->SwapBuffers(enter.callback()));
}

这个函数定义在文件external/chromium_org/ppapi/proxy/ppb_graphics_3d_proxy.cc中。

参数context描述的是一个要交换前后缓冲区的OpenGL上下文。从前面的分析可以知道，在Render进程中，这个OpenGL上下文是通过一个PPB_Graphics3D_Impl对象描述的。PPB_Graphics3D_Proxy类的成员函数OnMsgSwapBuffers通过构造一个EnterHostFromHostResourceForceCallback<PPB_Graphics3D_API>来获得这个PPB_Graphics3D_Impl对象，并且调用这个PPB_Graphics3D_Impl对象的成员函数SwapBuffers更新当前正在处理的Plugin在网页上的视图。

PPB_Graphics3D_Impl类的成员函数SwapBuffers是从父类ppapi::PPB_Graphics3D_Shared继承下来的。前面我们已经分析过ppapi::PPB_Graphics3D_Shared类的成员函数SwapBuffers的实现了，它最终会调用由子类实现的成员函数DoSwapBuffers，即PPB_Graphics3D_Impl类的成员函数DoSwapBuffers。

PPB_Graphics3D_Impl类的成员函数DoSwapBuffers的实现如下所示：

int32 PPB_Graphics3D_Impl::DoSwapBuffers() {
  ......

  if (bound_to_instance_) {
    // If we are bound to the instance, we need to ask the compositor
    // to commit our backing texture so that the graphics appears on the page.
    // When the backing texture will be committed we get notified via
    // ViewFlushedPaint().
    //
    // Don't need to check for NULL from GetPluginInstance since when we're
    // bound, we know our instance is valid.
    HostGlobals::Get()->GetInstance(pp_instance())->CommitBackingTexture();
    commit_pending_ = true;
  } 

  ......

  return PP_OK_COMPLETIONPENDING;
}

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

从前面的分析可以知道，当前正在处理的PPB_Graphics3D_Impl对象描述的OpenGL上下文此时处于绑定状态，也就是它的成员变量bound_to_instance_的值等于true。在这种情况下，PPB_Graphics3D_Impl类的成员函数DoSwapBuffers首先会通过HostGlobals类的静态成员函数Get获得当前Render进程中的一个HostGlobals单例对象。有了这个HostGlobals单例对象之后，就可以调用它的成员函数GetInstance获得与当前正在处理的PPB_Graphics3D_Impl对象进行绑定的一个Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象。

有了上述PepperPluginInstanceImpl对象之后，PPB_Graphics3D_Impl类的成员函数DoSwapBuffers就可以调用它的成员函数CommitBackingTexture更新它在网页上的视图，如下所示：

void PepperPluginInstanceImpl::CommitBackingTexture() {
  ......
  gpu::Mailbox mailbox;
  uint32 sync_point = 0;
  bound_graphics_3d_->GetBackingMailbox(&mailbox, &sync_point);
  ......
  texture_layer_->SetTextureMailboxWithoutReleaseCallback(
      cc::TextureMailbox(mailbox, GL_TEXTURE_2D, sync_point));
  texture_layer_->SetNeedsDisplay();
}

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

从前面的分析可以知道，PepperPluginInstanceImpl类的成员变量bound_graphics_3d_指向的是一个PPB_Graphics3D_Impl对象。这个PPB_Graphics3D_Impl对象描述的是一个OpenGL上下文。这个OpenGL上下文就是当前正在处理的PepperPluginInstanceImpl对象绑定的OpenGL上下文。

PepperPluginInstanceImpl类的另外一个成员变量texture_layer_指向的是一个cc::TextureLayer对象。前面提到，网页中的每一个<embed>标签在网页的CC Layer Tree中都对应有一个Texture Layer。这个Texture Layer就是通过上述cc::TextureLayer对象描述的。

有了上述PPB_Graphics3D_Impl对象之后，PepperPluginInstanceImpl类的成员函数CommitBackingTexture就可以调用它的成员函数GetBackingMailbox获得已经被交换到后端的缓冲区。这个缓冲区实际上是一个纹理缓冲区。这个纹理缓冲区将会作为<embed>标签的内容，因此PepperPluginInstanceImpl类的成员函数CommitBackingTexture就会将它设置上述cc::TextureLayer对象所要绘制的内容。这是通过调用该cc::TextureLayer对象的成员函数SetTextureMailboxWithoutReleaseCallback实现的。

最后，PepperPluginInstanceImpl类的成员函数CommitBackingTexture调用上述cc::TextureLayer对象的成员函数SetNeedsDisplay将自己标记为需要更新。这样在下一个VSync信号到来的时候，前面设置为它的内容的纹理缓冲区就会被渲染和合成在网页的UI上。这个渲染和合成过程可以参考前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章。

这样，我们就分析完成了Plugin执行3D渲染的过程，也就是Plugin为<embed>标签绘制3D视图的过程，这是通过调用Chromium提供的PPB_OPENGLES2_INTERFACE接口完成的。从这个过程我们就可以看到Plugin和Chromium的交互过程，也就是它们可以互相调用对方提供的接口，从而使得Plugin可以像我们在前面Chromium扩展（Extension）机制简要介绍和学习计划这个系列的文章提到的Extension一样，增强网页的功能。

至此，我们也分析完成了Chromium的Plugin机制。重新学习可以参考前面Chromium插件（Plugin）机制简要介绍和学习计划一文。更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/11/14 1:00:15 原文链接

阅读：35533 评论：4 查看评论

↧

Android WebView简要介绍和学习计划

November 21, 2016, 12:59 am

≫ Next: Android WebView加载Chromium动态库的过程分析

≪ Previous: Chromium插件（Plugin）执行3D渲染的过程分析

我们通常会在App的UI中嵌入WebView，用来实现某些功能的动态更新。在4.4版本之前，Android WebView基于WebKit实现。不过，在4.4版本之后，Android WebView就换成基于Chromium的实现了。基于Chromium实现，使得WebView可以更快更流畅地显示网页。本文接下来就介绍Android WebView基于Chromium的实现原理，以及制定学习计划。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

通过前面几个系列文章的学习，我们知道，Chromium的实现是相当复杂的。这种复杂可以体现在编译出来的动态库的大小上，带符号版本1.3G左右，去掉符号后还有27M左右。编译过AOSP源码的都知道，在整个编译过程中，Chromium库占用了大部分的时间，尤其是在生成上述1.3G文件时，电脑几乎卡住了。因此，在使用Chromium实现WebView时，第一个要解决的问题就是它的动态库加载问题。

Android系统的动态库是ELF文件结构。ELF文件由ELF Header、Program Header Table、Section以及Section Header Table组成。ELF Header位于文件的开头，它同时描述了Program Header Table和Section Header Table在文件中的偏移位置。Section Header Table描述了动态库由哪些Section组成，典型的Section有.text、.data、.bss和.rodata等。这些Section描述的要么是程序代码，要么是程序数据。Program Header Table描述了动态库由哪些Segment组成。一个Segment又是由一个或者若干个Section组成的。Section信息是在程序链接期间用到的，而Segment信息是在程序加载期间用到的。关于ELF文件格式的更详细描述，可以参考Executable and Linkable Format。

对于动态库来说，它的程序代码是只读的。这意味着一个动态库不管被多少个进程加载，它的程序代码都是只有一份。但是，动态库的程序数据，链接器在加载的时候，会为每一个进程都独立加载一份。对于Chromium动态库来说，它的程序代码占据了95%左右的大小，也就是25.65M左右。剩下的5%，也就是1.35M，是程序数据。假设有N个App使用了WebView，并且这个N个App的进程都存在系统中，那么系统就需要为Chromium动态库分配（25.65 + 1.35 × N）M内存。这意味着，N越大，Chromium动态库就占用越多的系统内存。

在Chromium动态库1.35M的程序数据中，大概有1.28M在加载后经过一次重定位操作之后就不会发生变化。这些数据包含C++虚函数表，以及所有指针类型的常量。它们会被链接器放在一个称为GNU_RELRO Section中，如图1所示：

图1 App进程间不共享GNU_RELRO Section

如果我们将Chromium动态库的GNU_RELRO Section看成是普通的程序数据，那么Android系统就需要为每一个使用了WebView的App进程都分配1.28M的内存。这将会造成内存浪费。如果我们能App进程之间共享Chromium动态库的GNU_RELRO Section，那么不管有多少个App进程使用了WebView，它占用的内存大小都是1.28M，如图2所示：

图2 App进程间共享GNU_RELRO Section

这是有可能做到的，毕竟它与程序代码类似，在运行期间都是只读的。不同的地方在于，程序代码在加载后自始至终都不用修改，而GNU_RELRO Section的内容在重定位期间，是需要进行一次修改的，之后才是只读的。但是修改的时候，Linux的COW（Copy On Write）机制就会使得它不能再在各个App进程之间实现共享。

为了使得Chromium动态库能在不同的App进程之间共享，Android系统执行了以下操作：

1. Zygote进程在启动的过程中，为Chromium动态库保留了一段足够加载它的虚拟地址内间。我们假设这个虚拟地址空间的起始地址为gReservedAddress，大小为gReservedSize。

2. System进程在启动的过程中，会请求Zygote进程fork一个子进程，并且在上述保留的虚拟地址空间[gReservedAddress, gReservedAddress + gReservedSize)中加载Chromium动态库。Chromium动态库的Program Header指定了它的GNU_RELRO Section的加载位置。这个位置是相对基地址gReservedAddress的一个偏移量。我们假设这个偏移量为gRelroOffset。上述子进程完成Chromium动态库的GNU_RELRO Section的重定位操作之后，会将它的内容写入到一个RELRO文件中去。

3. App进程在创建WebView的时候，Android系统也会在上述保留的虚拟地址空间[gReservedAddress, gReservedAddress + gReservedSize)中加载Chromium动态库，并且会直接将第2步得到的RELRO文件内存映射到虚拟地址空间[gReservedAddress + gRelroOffset, gReservedAddress + gRelroOffset + 1.28)去。

关于Zygote进程、System进程和App进程的启动过程，可以参考Android系统进程Zygote启动过程的源代码分析和Android应用程序进程启动过程的源代码分析这两篇文章。

Android 5.0的Linker提供了一个新的动态库加载函数android_dlopen_ext。这个函数不仅可以将一个动态库加载在指定的虚拟地址空间中，还可以在该动态库重定位操作完成后，将其GNU_RELRO Section的内容写入到指定的RELRO文件中去，同时还可以在加载一个动态库时，使用指定的RELRO文件内存映射为它的GNU_RELRO Section。因此，上述的第2步和第3步可以实现。函数android_dlopen_ext还有另外一个强大的功能，它可以从一个指定的文件描述符中读入要加载的动态库内容。通常我们是通过文件路径指定要加载的动态库，有了函数android_dlopen_ext之后，我们就不再受限于从本地文件加载动态库了。

接下来，我们进一步分析为什么上述3个操作可以使得Chromium动态库能在不同的App进程之间共享。

首先，第2步的子进程、第3步的App进程都是由第1步的Zygote进程fork出来的，因此它们都具有一段保留的虚拟地址空间[gReservedAddress, gReservedAddress + gReservedSize)。

其次，第2步的子进程和第3步的App进程，都是将Chromium动态库加载在相同的虚拟地址空间中，因此，可以使用前者生成的RELRO文件内存映射为后者的GNU_RELRO Section。

第三，所有使用了WebView的App进程，都将相同的RELRO文件内存映射为自己加载的Chromium动态库的GNU_RELRO Section，因此就实现了共享。

App进程加载了Chromium动态库之后，就可以启动Chromium渲染引擎了。Chromium渲染引擎实际上是由Browser进程、Render进程和GPU进程组成的。其中，Browser进程负责将网页的UI合成在屏幕上，Render进程负责加载和渲染网页的UI，GPU进程负责执行Browser进程和Render进程发出的GPU命令。由于Chromium也支持单进程架构（在这种情况下，它的Browser进程、Render进程和GPU进程都是通过线程模拟的），因此接下来我们将它的Browser进程、Render进程和GPU进程统称为Browser端、Render端和GPU端。相应地，启动Chromium渲染引擎，就是要启动它的Browser端、Render端和GPU端。

对于Android WebView来说，它启动Chromium渲染引擎的过程如图3所示：

图3 Android WebView启动Chromium渲染引擎的过程

当我们在App的UI中嵌入一个WebView时，WebView内部会创建一个WebViewChromium对象。从名字就可以看出，WebViewChromium是基于Chromium实现的WebView。Chromium里面有一个android_webview模块。这个模块提供了两个类AwBrowserProcess和AwContents，分别用来封装Chromium的Content层提供的两个类BrowserStartupController和ContentViewCore。

从前面Chromium硬件加速渲染的OpenGL上下文绘图表面创建过程分析一文可以知道，通过Chromium的Content层提供的BrowserStartupController类，可以启动Chromium的Browser端。不过，对于Android WebView来说，它并没有单独的Browser进程，它的Browser端是通过App进程的主线程（即UI线程）实现的。

Chromium的Content层会通过BrowserStartupController类在App进程的UI线程中启动一个Browser Main Loop。以后需要请求Chromium的Browser端执行某一个操作时，就向这个Browser Main Loop发送一个Task即可。这个Browser Main Loop最终会在App进程的UI线程中执行请求的Task。

从前面Chromium网页Frame Tree创建过程分析一文可以知道，通过Chromium的Content层提供的ContentViewCore类，可以创建一个Render进程，并且在这个Render进程中加载指定的网页。不过，对于Android WebView来说，它是一个单进程架构，也就是它没有单独的Render进程用来加载网页。这时候ContentViewCore类将会创建一个线程来模拟Render进程。也就是说，Android WebView的Render端是通过在App进程中创建的一个线程实现的。这个线程称为In-Process Renderer Thread。

现在，Android WebView具有Browser端和Render端了，它还需要有一个GPU端。从前面Chromium的GPU进程启动过程分析一文可以知道，在Android平台上，Chromium的GPU端是通过在Browser进程中创建一个GPU线程实现的。不过，对于Android WebView来说，它并没有一个单独的GPU线程。那么，Chromium的GPU命令由谁来执行呢？

我们知道，从Android 3.0开始，App的UI就支持硬件加速渲染了，也就是支持通过GPU来渲染。到了Android 4.0，App的UI默认就是硬件加速渲染了。这时候App的UI线程就是一个OpenGL线程，也就是它可以用来执行GPU命令。再到Android 5.0，App的UI线程只负责收集UI渲染操作，也就是构建一个Display List。保存在这个Display List中的操作，最终会交给一个Render Thread执行。Render Thread又是通过GPU来执行这些渲染操作的。这时候App的UI线程不再是一个OpenGL线程，Render Thread才是。Android WebView的GPU命令就是由这个Render Thread执行的。当然，在Android 4.4时，Android WebView的GPU命令还是由App的UI线程执行的。这里我们只讨论Android 5.0的情况，具体可以参考Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章。

Chromium在android_webview模块中提供了一个DeferredGpuCommandService服务。当Android WebView的Render端需要通过GPU命令绘制网页UI时，它就会通过DeferredGpuCommandService服务提供的RequestProcessGL接口向App的Display List增加一个类型为DrawFunctorOp的操作。当Display List从UI线程同步给Render Thread的时候，它里面包含的DrawFunctorOp操作就会被执行。这时候Android WebView的Render端请求的GPU命令就会在App的Render Thread中得到执行了。

Android WebView的Browser端在合成网页UI时，是运行在App的Render Thread中的。这时候它仍然是通过DeferredGpuCommandService服务提供的RequestProcessGL接口请求执行GPU命令。不过，DeferredGpuCommandService会检测到它当前运行在App的Render Thread中，因此，就会直接执行它请求的GPU命令。

Chromium为Android WebView独特的GPU命令执行方式（既不是在单独的GPU进程中执行，也不是在单独的GPU线程中执行）提供了一个称为In-Process Command Buffer GL的接口。顾名思义，In-Process Command Buffer GL与Command Buffer GL接口一样，要执行的GPU命令都是先写入到一个Command Buffer中。然而，这个Command Buffer会提交给App的Render Thread进程执行，过程如图4所示：

图4 Android WebView通过In-Process Command Buffer GL接口执行GPU命令的过程

In-Process Command Buffer GL接口与前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文分析的Command Buffer GL接口一样，都是通过GLES2Implementation类描述的，区别在于前者通过一个InProcessCommandBuffer对象执行GPU命令，而后者通过一个CommandBufferProxyImpl对象执行GPU命令。更具体来说，就是CommandBufferProxyImpl对象会将要执行的GPU命令提交给Chromium的GPU进程/线程处理，而InProcessCommandBuffer对象会将要执行的GPU命令提交给App的Render Thread处理。

GLES2Implementation类是通过InProcessCommandBuffer类的成员函数Flush请求它处理已经写入在Command Buffer中的GPU命令的。InProcessCommandBuffer类的成员函数Flush又会请求前面提到的DeferredGpuCommandService服务调度一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread，意思就是说要在App的Render Thread线程中调用InProcessCommandBuffer类的成员函数FlushOnGpuThread。InProcessCommandBuffer类的成员函数FlushOnGpuThread在调用的过程中，就会执行已经写入在Command Buffer中的GPU命令。

DeferredGpuCommandService服务接收到调度Task的请求之后，会判断当前线程是否允许执行GL操作，实际上就是判断当前线程是否就是App的Render Thread。如果是的话，那么就会直接调用请求调度的Task绑定的InProcessCommandBuffer类的成员函数FlushOnGpuThread。这种情况发生在Browser端合成网页UI的过程中。Browser端合成网页UI的操作是由App的Render Thread主动发起的，因此这个合成操作就可以在当前线程中直接执行。

另一方面，DeferredGpuCommandService服务接收到调度Task的请求之后，如果发现当前不允许执行GL操作，那么它就会将该Task保存在内部一个Task队列中，并且通过调用Java层的DrawGLFunctor类的成员函数requestDrawGL请求App的UI线程调度执行一个GL操作。这种情况发生在两个场景中。

第一个场景发生在前面描述的Render端绘制网页UI的过程中。绘制网页UI相当于就是绘制Android WebView的UI。Android WebView属于App的UI里面一部分，因此它的绘制操作是由App的UI线程发起的。Android WebView在App的UI线程中接收到绘制的请求之后，它就会要求Render端的Compositor线程绘制网页的UI。这个Compositor线程不是一个OpenGL线程，它不能直接执行GL的操作，因此就要请求App的UI线程调度执行GL操作。

从前面Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章可以知道，App的UI线程主要是负责收集当前UI的渲染操作，并且通过一个DisplayListRenderer将这些渲染操作写入到一个Display List中去。这个Display List最终会同步到App的Render Thread中去。App的Render Thread获得了这个Display List之后，就会通过调用相应的OpenGL函数执行这些渲染操作，也就是通过GPU来执行这些渲染操作。这个过程称为Replay（重放） Display List。重放完成之后，就可以生成App的UI了。

DrawGLFunctor类的成员函数requestDrawGL请求App的UI线程调度执行的GL操作是一个特殊的渲染操作，它对应的是一个GL函数，而一般的渲染操作是指绘制一个Circle、Rect或者Bitmap等基本操作。GL函数在执行期间，可以执行任意的GPU命令。这个GL操作封装在一个DrawGLFunctor对象。App的UI线程又会进一步将这个rawGLFunctor对象封装成一个DrawFunctionOp操作。这个DrawFunctionOp操作会通过DisplayListRenderer类的成员函数callDrawGLFunction写入到App UI的Display List中。当这个Display List被App的Render Thread重放时，它里面包含的DrawFunctionOp操作就会被OpenGLRenderer类的成员函数callDrawGLFunction执行。

OpenGLRenderer类的成员函数callDrawGLFunction在执行DrawFunctionOp操作时，就会通知与它关联的DrawGLFunctor对象。这个DrawGLFunctor对象又会调用Chromium的android_webview模块提供的一个GL函数。这个GL函数又会找到一个HardwareRenderer对象。这个HardwareRenderer对象是Android WebView的Browser端用来合成网页的UI的。有了这个HardwareRenderer对象之后，上述GL函数就会调用它的成员函数DrawGL，以便请求前面提到的DeferredGpuCommandService服务执行保存在它内部的Task，这是通过调用它的成员函数PerformIdleTask实现的。

DeferredGpuCommandService类的成员函数PerformIdleTask会依次执行保存在内部Task队列的每一个Task。从前面的分析可以知道，这时候Task队列中存在一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。因此，这时候InProcessCommandBuffer类的成员函数FlushOnGpuThread就会在当前线程中被调用，也就是在App的Render Thread中被调用。

前面提到，InProcessCommandBuffer类的成员函数FlushOnGpuThread在调用的过程中，会执行之前通过In-Process Command Buffer GL接口写入在Command Buffer中的GPU命令。InProcessCommandBuffer类的成员函数FlushOnGpuThread又是通过内部的一个GpuScheduler对象和一个GLES2Decoder对象执行这些GPU命令的。其中，GpuScheduler对象负责将GPU命令调度在它们对应的OpenGL上下文中执行，而GLES2Decoder对象负责将GPU命令翻译成OpenGL函数执行。关于GpuScheduler类和GLES2Decoder类执行GPU命令的过程，可以参考前面前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

第二个场景发生Render端光栅化网页UI的过程中。从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章可以知道，Render端通过GPU光栅化网页UI的操作也是发生在Compositor线程中的。这时候它请求App的Render Thread执行GPU命令的大概流程相同，也是将要执行的GPU操作封装在一个DrawGLFunctor对象中。不过，这个DrawGLFunctor对象不会进一步被封装成DrawFunctionOp操作写入到App UI的Display List中，而是直接被App的UI线程放入到App的Render Thread中，App的Render Thread再通知它执行所请求的GPU操作。DrawGLFunctor对象获得执行GPU操作的通知后，后流的流程就与前面描述的第一个场景一致了。

通过以上描述的方式，Android WebView的Browser端和Render端就可以执行任意的GPU命令了。其中，Render端执行GPU命令是为了绘制网页UI，而Browser端执行GPU命令是为了将Render端渲染出来的网页UI合成在App的UI中，以便最后可以显示在屏幕中。这个过程就是Android WebView硬件加速渲染网页的过程，如图5所示：

图5 Android WebView硬件加速渲染网页过程

从前面Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章可以知道，App从接收到VSync信号开始渲染一帧UI。两个VSync信号时间间隔由屏幕刷新频率决定。一般的屏幕刷新频率是60fps，这意味着每一个VSync信号到来时，App有16ms的时间绘制自己的UI。

这16ms时间又划分为三个阶段。第一阶段用来构造App UI的Display List。这个构造工作由App的UI线程执行，表现为各个需要更新的View的成员函数onDraw会被调用。第二阶段App的UI线程会将前面构造的Display List同步给Render Thread。这个同步操作由App的Render Thread执行，同时App的UI线程会被阻塞，直到同步操作完成为止。第三阶段是绘制App UI的Display List。这个绘制操作由App的Render Thread执行。

由于Android WebView是嵌入在App的UI里面的，因此它每一帧的渲染也是按照上述三个阶段进行的。从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章可以知道，网页的UI最终是通过一个CC Layer Tree描述的，也就是Android WebView的Render端会创建一个CC Layer Tree来描述它正在加载的网页的UI。与此同时，Android WebView还会为Render端创建一个Synchronous Compositor，用来将网页的UI渲染在一个Synchronous Compositor Output Surface上。渲染得到的最终结果通过一个Compositor Frame描述。这意味网页的每一帧都是通过一个Compositor Frame描述的。

Android WebView的Browser端负责合成Render端渲染出来的UI。为了完成这个合成操作，它同样会创建一个CC Layer Tree。这个CC Layer Tree只有两个节点，一个是根节点，另外一个是根节点的子节点，称为Delegated Renderer Layer。这个Delegated Renderer Layer的内容来自于Render端的渲染结果，也就是一个Compositor Frame。与此同时，Android WebView会为Browser端创建一个Hardware Renderer，用来将它的CC Layer Tree渲染在一个Parent Output Surface上，实际上就是将网页的UI合成在App的窗口上。

在第一阶段，Android WebView的成员函数onDraw会在App的UI线程中被调用。在调用期间，它又会调用为Render端创建的Synchronous Compositor的成员函数DemandDrawHw，用来渲染Render端的CC Layer Tree。渲染完成后，为Render端创建的Synchronous Compositor Output Surface的成员函数SwapBuffers就会被调用，并且交给它一个Compositor Frame。这个Compositor Frame描述的就是网页当前的UI，它最终会被保存在一个SharedRendererState对象中。这个SharedRendererState对象是用来描述网页的状态的。

在第二阶段，保存在上述SharedRendererState对象中的Compositor Frame会被提取出来，并且同步给Browser端的CC Layer Tree，也就是设置为该CC Layer Tree的Delegated Renderer Layer的内容。

在第三阶段，Android WebView为Browser端创建的Hardware Renderer的成员函数DrawGL会在App的Render Thread中被调用，用来渲染Browser端的CC Layer Tree。渲染完成后，为Browser端创建的Parent Output Surface的成员函数SwapBuffers就会被调用，这时候它就会将得到的网页UI绘制在App的窗口上。

以上就是Android WebView以硬件加速方式将网页UI渲染在App窗口的过程。当然，Android WebView也可用软件方式将网页UI渲染在App窗口。不过，在这个系列的文章中，我们只要关注硬件加速渲染方式，因为这种渲染方式效率会更高，而且Android系统从4.0版本之后，默认已经是使用硬件加速方式渲染App的UI了。

接下来，我们就结合源码，按照以下四个情景，详细分析Android WebView硬件加速渲染网页UI的过程：

1. Android WebView加载Chromium动态库的过程；

2. Android WebView启动Chromium渲染引擎的过程；

3. Android WebView执行OpenGL命令的过程；

4. Android WebView硬件加速渲染网页UI的过程。

分析了这四个情景之后，我们就可以对Android WebView的实现有深刻的认识了。敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/11/21 0:59:03 原文链接

阅读：44189 评论：17 查看评论

↧

Android WebView加载Chromium动态库的过程分析

November 28, 2016, 1:00 am

≫ Next: Android WebView启动Chromium渲染引擎的过程分析

≪ Previous: Android WebView简要介绍和学习计划

Chromium动态库的体积比较大，有27M左右，其中程序段和数据段分别占据25.65M和1.35M。如果按照通常方式加载Chromium动态库，那么当有N个正在运行的App使用WebView时，系统需要为Chromium动态库分配的内存为(25.65 + N x 1.35)M。这是非常可观的。为此，Android使用了特殊的方式加载Chromium动态库。本文接下来就详细分析这种特殊的加载方式。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

为什么当有N个正在运行的App使用WebView时，系统需要为Chromium动态库分配的内存为(25.65 + N x 1.35)M呢？这是由于动态库的程序段是只读的，可以在多个进程之间进行共享，但是数据段一般是可读可写的，不能共享。在1.35M的数据段中，有1.28M在Chromium动态库加载完成后就是只读的。这1.28M数据包含有C++虚函数表，以及指针类型的常量等，它们在编译的时候会放在一个称为GNU_RELRO的Section中，如图1所示：

图1 App进程间不共享GNU_RELRO Section

如果我们将该GNU_RELRO Section看作是一般的数据段，那么系统就需要为每一个使用了WebView的App进程都分配一段1.28M大小的内存空间。前面说到，这1.28M数据在Chromium动态库加载完成后就是只读的，那么有没有办法让它像程序段一样，在多个App进程之间共享呢？

只要能满足一个条件，那么答案就是肯定的。这个条件就是所有的App进程都在相同的虚拟地址空间加载Chromium动态库。在这种情况下，就可以在系统启动的过程中，创建一个临时进程，并且在这个进程中加载Chromium动态库。假设Chromium动态库的加载地址为Base Address。加载完成后，将Chromium动态库的GNU_RELRO Section的内容Dump出来，并且写入到一个文件中去。

以后App进程加载Chromium动态库时，都将Chromium动态库加载地址Base Address上，并且使用内存映射的方式将前面Dump出来的GNU_RELRO文件代替Chromium动态库的GNU_RELRO Section。这样就可以实现在多个App进程之间共享Chromium动态库的GNU_RELRO Section了，如图2所示：

图2 App进程间共享GNU_RELRO Section

从前面Android应用程序进程启动过程的源代码分析一文可以知道，所有的App进程都是由Zygote进程fork出来的，因此，要让所有的App进程都在相同的虚拟地址空间加载Chromium动态库的最佳方法就是在Zygote进程的地址空间中预留一块地址。

还有两个问题需要解决。第一个问题是要将加载后的Chromium动态库的GNU_RELRO Section的内容Dump出来，并且写入到一个文件中去。第二个问题是要让所有的App进程将Chromium动态加载在指定位置，并且可以使用指定的文件来代替它的GNU_RELRO Section。这两个问题都可以通过Android在5.0版本提供的一个动态库加载函数android_dlopen_ext解决。

接下来，我们就结合源码，分析Zygote进程是如何为App进程预留地址加载Chromium动态库的，以及App进程如何使用新的动态库加载函数android_dlopen_ext加载Chromium动态库的。

从前面Android系统进程Zygote启动过程的源代码分析一文可以知道，Zygote进程在Java层的入口函数为ZygoteInit类的静态成员函数main，它的实现如下所示：

public class ZygoteInit {
    ......

    public static void main(String argv[]) {
        try {
            .......

            preload();
            .......

            if (startSystemServer) {
                startSystemServer(abiList, socketName);
            }

            ......
            runSelectLoop(abiList);

            ......
        } catch (MethodAndArgsCaller caller) {
            ......
        } catch (RuntimeException ex) {
            ......
        }
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/com/android/internal/os/ZygoteInit.java中。

ZygoteInit类的静态成员函数main在启动System进程以及使得Zygote进程进入运行状态之前，首先会调用另外一个静态成员函数preload预加载资源。这些预加载的资源以后就可以在App进程之间进行共享。

ZygoteInit类的静态成员函数preload在预加载资源的过程中，就会为Chromium动态库预保留加载地址，如下所示：

public class ZygoteInit {
    ......

    static void preload() {
        ......
        // Ask the WebViewFactory to do any initialization that must run in the zygote process,
        // for memory sharing purposes.
        WebViewFactory.prepareWebViewInZygote();
        ......
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/com/android/internal/os/ZygoteInit.java中。

ZygoteInit类的静态成员函数preload是通过调用WebViewFactory类的静态成员函数prepareWebViewInZygote为Chromium动态库预保留加载地址的，后者的实现如下所示：

public final class WebViewFactory {
    ......

    public static void prepareWebViewInZygote() {
        try {
            System.loadLibrary("webviewchromium_loader");
            long addressSpaceToReserve =
                    SystemProperties.getLong(CHROMIUM_WEBVIEW_VMSIZE_SIZE_PROPERTY,
                    CHROMIUM_WEBVIEW_DEFAULT_VMSIZE_BYTES);
            sAddressSpaceReserved = nativeReserveAddressSpace(addressSpaceToReserve);

            ......
        } catch (Throwable t) {
            ......
        }
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

WebViewFactory类的静态成员函数prepareWebViewInZygote首先会加载一个名称为“webviewchromium_loader”的动态库，接下来又会获得需要为Chromium动态库预留的地址空间大小addressSpaceToReserve。知道了要预留的地址空间的大小之后，WebViewFactory类的静态成员函数prepareWebViewInZygote就会调用另外一个静态成员函数nativeReserveAddressSpace为Chromium动态库预留地址空间。

WebViewFactory类的静态成员函数nativeReserveAddressSpace是一个JNI方法，它在C++层对应的函数为ReserveAddressSpace。这个函数实现在上述名称为“webviewchromium_loader”的动态库中，如下所示：

jboolean ReserveAddressSpace(JNIEnv*, jclass, jlong size) {
  return DoReserveAddressSpace(size);
}

这个函数定义在文件frameworks/webview/chromium/loader/loader.cpp中。

函数ReserveAddressSpace调用另外一个函数DoReserveAddressSpace预留大小为size的地址空间，如下所示：

void* gReservedAddress = NULL;
size_t gReservedSize = 0;

jboolean DoReserveAddressSpace(jlong size) {
  size_t vsize = static_cast<size_t>(size);

  void* addr = mmap(NULL, vsize, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  ......

  gReservedAddress = addr;
  gReservedSize = vsize;
  ......

  return JNI_TRUE;
}

这个函数定义在文件frameworks/webview/chromium/loader/loader.cpp中。

函数DoReserveAddressSpace是通过系统接口mmap预留指定大小的地址空间的。同时，预留出来的地址空间的起始地址和大小分别记录在全局变量gReservedAddress和gReservedSize中。以后Chromium动态库就可以加载在该地址空间中。

为Chromium动态库预留好加载地址之后，Android系统接下来要做的一件事情就是请求Zygote进程启动一个临时进程。这个临时进程将会在上述预留的地址空间中加载Chromium动态库。这个Chromium动态库在加载的过程中，它的GNU_RELRO Section会被重定位。重定位完成之后，就可以将它的内容Dump到一个文件中去。这个文件以后就会以内存映射的方式代替在App进程中加载的Chromium动态库的GNU_RELRO Section。

请求Zygote进程启动临时进程的操作是由System进程完成的。从前面Android系统进程Zygote启动过程的源代码分析一文可以知道，System进程是由Zygote进程启动的，它在Java层的入口函数为SystemServer的静态成员函数main，它的实现如下所示：

public final class SystemServer {
    ......

    public static void main(String[] args) {
        new SystemServer().run();
    }

    ......
}

这个函数定义在文件frameworks/base/services/java/com/android/server/SystemServer.java中。

SystemServer的静态成员函数main首先是创建一个SystemServer对象，然后调用这个SystemServer对象的成员函数run在System进程中启动各种系统服务，如下所示：

public final class SystemServer {
    ......

    private void run() {
        ......

        // Start services.
        try {
            startBootstrapServices();
            startCoreServices();
            startOtherServices();
        } catch (Throwable ex) {
            ......
        }

        ......

        // Loop forever.
        Looper.loop();
        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

    ......
}

这个函数定义在文件frameworks/base/services/java/com/android/server/SystemServer.java中。

SystemServer类的成员函数run首先会调用成员函数startBootstrapServices启动Bootstrap类型的系统服务。这些系统服务包括Activity Manager Service、Power Manager Service、Package Manager Service和Display Manager Service等。

SystemServer类的成员函数run接下来又会调用成员函数startCoreServices启动Core类型的系统服务。这些系统服务包括Lights Service、Battery Service和Usage Stats Service等。

SystemServer类的成员函数run再接下来还会调用成员函数startOtherServices启动其它的系统服务。这些其它的系统服务包括Account Manager Service、Network Management Service和Window Manager Service等。

SystemServer类的成员函数startOtherServices启动完成其它的系统服务之后，就会创建一个Runnable。这个Runnable会在Activity Manger Service启动完成后执行，如下所示：

public final class SystemServer {
    ......

    private void startOtherServices() {
        final Context context = mSystemContext;
        AccountManagerService accountManager = null;
        ContentService contentService = null;
        VibratorService vibrator = null;
        IAlarmManager alarm = null;
        MountService mountService = null;
        NetworkManagementService networkManagement = null;
        NetworkStatsService networkStats = null;
        NetworkPolicyManagerService networkPolicy = null;
        ConnectivityService connectivity = null;
        NetworkScoreService networkScore = null;
        NsdService serviceDiscovery= null;
        WindowManagerService wm = null;
        BluetoothManagerService bluetooth = null;
        UsbService usb = null;
        SerialService serial = null;
        NetworkTimeUpdateService networkTimeUpdater = null;
        CommonTimeManagementService commonTimeMgmtService = null;
        InputManagerService inputManager = null;
        TelephonyRegistry telephonyRegistry = null;
        ConsumerIrService consumerIr = null;
        AudioService audioService = null;
        MmsServiceBroker mmsService = null;
        ......

       mActivityManagerService.systemReady(new Runnable() {
            @Override
            public void run() {
                ......

                WebViewFactory.prepareWebViewInSystemServer();

                ......
            }
        });
    }

    ......
}

这个函数定义在文件frameworks/base/services/java/com/android/server/SystemServer.java中。

这个Runnable在执行的时候，会调用WebViewFactory类的静态成员函数prepareWebViewInSystemServer请求Zygote进程启动一个临时的进程，用来加载Chromium动态库，并且将完成重定位操作后的GNU_RELRO Section的内容Dump到一个文件中去。

WebViewFactory类的静态成员函数prepareWebViewInSystemServer的实现如下所示：

public final class WebViewFactory {
    ......

    public static void prepareWebViewInSystemServer() {
        String[] nativePaths = null;
        try {
            nativePaths = getWebViewNativeLibraryPaths();
        } catch (Throwable t) {
            // Log and discard errors at this stage as we must not crash the system server.
            Log.e(LOGTAG, "error preparing webview native library", t);
        }
        prepareWebViewInSystemServer(nativePaths);
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

WebViewFactory类的静态成员函数prepareWebViewInSystemServer首先调用另外一个静态成员函数getWebViewNativeLibraryPaths获得Chromium动态库的文件路径，如下所示：

public final class WebViewFactory {
    ......

    private static String[] getWebViewNativeLibraryPaths()
            throws PackageManager.NameNotFoundException {
        final String NATIVE_LIB_FILE_NAME = "libwebviewchromium.so";

        PackageManager pm = AppGlobals.getInitialApplication().getPackageManager();
        ApplicationInfo ai = pm.getApplicationInfo(getWebViewPackageName(), 0);

        String path32;
        String path64;
        boolean primaryArchIs64bit = VMRuntime.is64BitAbi(ai.primaryCpuAbi);
        if (!TextUtils.isEmpty(ai.secondaryCpuAbi)) {
            // Multi-arch case.
            if (primaryArchIs64bit) {
                // Primary arch: 64-bit, secondary: 32-bit.
                path64 = ai.nativeLibraryDir;
                path32 = ai.secondaryNativeLibraryDir;
            } else {
                // Primary arch: 32-bit, secondary: 64-bit.
                path64 = ai.secondaryNativeLibraryDir;
                path32 = ai.nativeLibraryDir;
            }
        } else if (primaryArchIs64bit) {
            // Single-arch 64-bit.
            path64 = ai.nativeLibraryDir;
            path32 = "";
        } else {
            // Single-arch 32-bit.
            path32 = ai.nativeLibraryDir;
            path64 = "";
        }
        if (!TextUtils.isEmpty(path32)) path32 += "/" + NATIVE_LIB_FILE_NAME;
        if (!TextUtils.isEmpty(path64)) path64 += "/" + NATIVE_LIB_FILE_NAME;
        return new String[] { path32, path64 };
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

Android系统将Chromium动态库打包在一个WebView Package中。这个WebView Package也是一个APK，它的Package Name可以通过调用WebViewFactory类的静态成员函数getWebViewPackageName获得，如下所示：

public final class WebViewFactory {
    ......

    public static String getWebViewPackageName() {
        return AppGlobals.getInitialApplication().getString(
                com.android.internal.R.string.config_webViewPackageName);
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

WebViewFactory类的静态成员函数getWebViewPackageName又是通过系统字符串资源com.android.internal.R.string.config_webViewPackageName获得WebView Package的Package Name。

系统字符串资源com.android.internal.R.string.config_webViewPackageName的定义如下所示：

<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
  ......

  <!-- Package name providing WebView implementation. -->
    <string name="config_webViewPackageName" translatable="false">com.android.webview</string>

  ......
</resources>

这个字符串资源定义在文件frameworks/base/core/res/res/values/config.xml中。

从这里就可以看到，WebView Package这个APK的Package Name定义为"com.android.webview"。通过查找源码，可以发现，这个APK实现在目录frameworks/webview/chromium中。

回到WebViewFactory类的静态成员函数getWebViewNativeLibraryPaths中，它知道了WebView Package这个APK的Package Name之后，就可以通过Package Manager Service获得它的安装信息。Package Manager Service负责安装系统上所有的APK，因此通过它可以获得任意一个APK的安装信息。关于Package Manager Service，可以参考Android应用程序安装过程源代码分析这篇文章。

获得了WebView Package这个APK的安装信息之后，就可以知道它用来保存动态库的目录。Chromium动态库就是保存在这个目录下的。因此，WebViewFactory类的静态成员函数getWebViewNativeLibraryPaths最终可以获得Chromium动态库的文件路径。注意，获得Chromium动态库的文件路径可能有两个。一个是32位版本的，另外一个是64位版本的。

为什么要将Chromium动态库打包在一个WebView Package中呢？而不是像其它的系统动态库一样，直接放在/system/lib目录下。原因为了方便以后升级WebView。例如，Chromium有了新的版本之后，就可以将它打包在一个更高版本的WebView Package中。当用户升级WebView Package的时候，就获得了基于新版本Chromium实现的WebView了。

这一步执行完成后，回到WebViewFactory类的静态成员函数prepareWebViewInSystemServer中，这时候它就获得了Chromium动态库的文件路径。接下来，它继续调用另外一个静态成员函数prepareWebViewInSystemServer请求Zygote进程启动一个临时的进程，用来加载Chromium动态库，以便将完成重定位操作后的GNU_RELRO Section的内容Dump到一个文件中去。

WebViewFactory类的静态成员函数prepareWebViewInSystemServer的实现如下所示：

public final class WebViewFactory {

    ......

    private static void prepareWebViewInSystemServer(String[] nativeLibraryPaths) {
        if (DEBUG) Log.v(LOGTAG, "creating relro files");

        // We must always trigger createRelRo regardless of the value of nativeLibraryPaths. Any
        // unexpected values will be handled there to ensure that we trigger notifying any process
        // waiting on relreo creation.
        if (Build.SUPPORTED_32_BIT_ABIS.length > 0) {
            if (DEBUG) Log.v(LOGTAG, "Create 32 bit relro");
            createRelroFile(false /* is64Bit */, nativeLibraryPaths);
        }

        if (Build.SUPPORTED_64_BIT_ABIS.length > 0) {
            if (DEBUG) Log.v(LOGTAG, "Create 64 bit relro");
            createRelroFile(true /* is64Bit */, nativeLibraryPaths);
        }
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

WebViewFactory类的静态成员函数prepareWebViewInSystemServer根据系统对32位和64位的支持情况，调用另外一个静态成员函数createRelroFile相应地创建32位和64位的Chromium GNU_RELRO Section文件。

WebViewFactory类的静态成员函数createRelroFile的实现如下所示：

public final class WebViewFactory {
    ......

    private static void createRelroFile(final boolean is64Bit, String[] nativeLibraryPaths) {
        ......

        try {
            ......

            int pid = LocalServices.getService(ActivityManagerInternal.class).startIsolatedProcess(
                    RelroFileCreator.class.getName(), nativeLibraryPaths, "WebViewLoader-" + abi, abi,
                    Process.SHARED_RELRO_UID, crashHandler);
            ......
        } catch (Throwable t) {
            ......
        }
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

WebViewFactory类的静态成员函数createRelroFile请求系统的Activity Manager Service启动一个Isolated Process。这个Isolated Process的启动过程与App进程是一样的，只不过它是一个被隔离的进程，没有自己的权限。

从前面Android应用程序进程启动过程的源代码分析一文可以知道，App进程最终是由Zygote进程fork出来的，并且它在Java层的入口函数为ActivityThread类的静态成员函数main。这个入口函数是可以指定的。WebViewFactory类的静态成员函数createRelroFile将请求启动的Isolated Process的入口函数指定为RelroFileCreator类的静态成员函数main。

这意味着，当上述Isolated Process启动起来之后，RelroFileCreator类的静态成员函数main就会被调用，如下所示：

public final class WebViewFactory {
    ......

    private static final String CHROMIUM_WEBVIEW_NATIVE_RELRO_32 =
            "/data/misc/shared_relro/libwebviewchromium32.relro";
    private static final String CHROMIUM_WEBVIEW_NATIVE_RELRO_64 =
            "/data/misc/shared_relro/libwebviewchromium64.relro";
    ......

    private static class RelroFileCreator {
        // Called in an unprivileged child process to create the relro file.
        public static void main(String[] args) {
            ......
            try{
                ......
                result = nativeCreateRelroFile(args[0] /* path32 */,
                                               args[1] /* path64 */,
                                               CHROMIUM_WEBVIEW_NATIVE_RELRO_32,
                                               CHROMIUM_WEBVIEW_NATIVE_RELRO_64);
                ......
            } finally {
                ......
            }
        }
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

前面获得的Chromium动态库文件路径会通过参数args传递进来。有了Chromium动态库文件路径之后，RelroFileCreator类的静态成员函数main就会调用另外一个静态成员函数nativeCreateRelroFile对它进行加载。加载完成后，RelroFileCreator类的静态成员函数nativeCreateRelroFile会将Chromium动态库已经完成重定位操作的Chromium GNU_RELRO Section写入到指定的文件中去。对于32位的Chromium动态库来说，它的GNU_RELRO Section会被写入到文件/data/misc/shared_relro/libwebviewchromium32.relro中，而对于64位的Chromium动态库来说，它的GNU_RELRO Section会被写入到文件/data/misc/shared_relro/libwebviewchromium64.relro中。

RelroFileCreator类的静态成员函数nativeCreateRelroFile是一个JNI方法，它由C++层的函数CreateRelroFile实现，如下所示：

jboolean CreateRelroFile(JNIEnv* env, jclass, jstring lib32, jstring lib64,
                         jstring relro32, jstring relro64) {
#ifdef __LP64__
  jstring lib = lib64;
  jstring relro = relro64;
  (void)lib32; (void)relro32;
#else
  jstring lib = lib32;
  jstring relro = relro32;
  (void)lib64; (void)relro64;
#endif
  jboolean ret = JNI_FALSE;
  const char* lib_utf8 = env->GetStringUTFChars(lib, NULL);
  if (lib_utf8 != NULL) {
    const char* relro_utf8 = env->GetStringUTFChars(relro, NULL);
    if (relro_utf8 != NULL) {
      ret = DoCreateRelroFile(lib_utf8, relro_utf8);
      env->ReleaseStringUTFChars(relro, relro_utf8);
    }
    env->ReleaseStringUTFChars(lib, lib_utf8);
  }
  return ret;
}

这个函数定义在文件frameworks/webview/chromium/loader/loader.cpp中。

函数CreateRelroFile判断自己是32位还是64位的实现，然后从参数lib32和lib64中选择对应的Chromium动态库进行加载。这个加载过程是通过调用另外一个函数DoCreateRelroFile实现的，如下所示：

void* gReservedAddress = NULL;
size_t gReservedSize = 0;

......

jboolean DoCreateRelroFile(const char* lib, const char* relro) {
  ......

  static const char tmpsuffix[] = ".XXXXXX";
  char relro_tmp[strlen(relro) + sizeof(tmpsuffix)];
  strlcpy(relro_tmp, relro, sizeof(relro_tmp));
  strlcat(relro_tmp, tmpsuffix, sizeof(relro_tmp));
  int tmp_fd = TEMP_FAILURE_RETRY(mkstemp(relro_tmp));
  ......

  android_dlextinfo extinfo;
  extinfo.flags = ANDROID_DLEXT_RESERVED_ADDRESS | ANDROID_DLEXT_WRITE_RELRO;
  extinfo.reserved_addr = gReservedAddress;
  extinfo.reserved_size = gReservedSize;
  extinfo.relro_fd = tmp_fd;
  void* handle = android_dlopen_ext(lib, RTLD_NOW, &extinfo);
  int close_result = close(tmp_fd);
  ......

  if (close_result != 0 ||
      chmod(relro_tmp, S_IRUSR | S_IRGRP | S_IROTH) != 0 ||
      rename(relro_tmp, relro) != 0) {
    ......
    return JNI_FALSE;
  }

  return JNI_TRUE;
}

这个函数定义在文件frameworks/webview/chromium/loader/loader.cpp中。

参数lib描述的是要加载的Chromium动态库的文件路径，另外一个参数relro描述的是要生成的Chromium GNU_RELRO Section文件路径。

我们假设要加载的Chromium动态库是32位的。函数DoCreateRelroFile的执行过程如下所示：

1. 创建一个临时的mium GNU_RELRO Section文件，文件路径为”/data/misc/shared_relro/libwebviewchromium32.relro.XXXXXX“，并且会找开这个临时文件，获得一个文件描述符tmp_fd。

2. 创建一个android_dlextinfo结构体。这个android_dlextinfo结构体会指定一个ANDROID_DLEXT_RESERVED_ADDRESS标志，以及一个Reserved地址gReservedAddress，表示要将Chromium动态库加载在全局变量gReservedAddress描述的地址中。从前面的分析可以知道，Zygote进程为Chromium动态库预留的地址空间的起始地址就保存在全局变量gReservedAddress中。由于当前进程是由Zygote进程fork出来的，因此它同样会获得Zygote进程预留的地址空间。

3. 前面创建的android_dlextinfo结构体，同时还会指定一个ANDROID_DLEXT_WRITE_RELRO标专，以及一个Relro文件描述符tmp_fd，表示在加载完成Chromium动态库后，将完成重定位操作后的GNU_RELRO Section写入到指定的文件中去，也就是写入到上述的临时文件/data/misc/shared_relro/libwebviewchromium32.relro.XXXXXX中去。

4. 调用Linker导出的函数android_dlopen_ext按照上述两点规则加载Chromium动态库。加载完成后，临时文件/data/misc/shared_relro/libwebviewchromium32.relro.XXXXXX将被重新命名为”/data/misc/shared_relro/libwebviewchromium32.relro“。

这样，我们得就到一个Chromium GNU_RELRO Section文件。这个Chromium GNU_RELRO Section文件在App进程加载Chromium动态库时就会使用到。接下来我们就继续分析App进程加载Chromium动态库的过程。

当App使用了WebView的时候，系统就为会其加载Chromium动态库。这个加载过程是从创建WebView对象的时候发起的。因此，接下来我们就从WebView类的构造函数开始分析App进程加载Chromium动态库的过程，如下所示：

public class WebView extends AbsoluteLayout
        implements ViewTreeObserver.OnGlobalFocusChangeListener,
        ViewGroup.OnHierarchyChangeListener, ViewDebug.HierarchyHandler {
    ......

    protected WebView(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes,
            Map<String, Object> javaScriptInterfaces, boolean privateBrowsing) {
        ......

        ensureProviderCreated();
        mProvider.init(javaScriptInterfaces, privateBrowsing);

        ......
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebView.java中。

WebView类的构造函数会调用另外一个成员函数ensureProviderCreated确保Chromium动态库已经加载。在Chromium动态库已经加载的情况下，WebView类的成员函数ensureProviderCreated还会创建一个WebView Provider，并且保存保存在成员变量mProvider中。这个WebView Provider才是真正用来实现WebView的功能的。

有了这个WebView Provider之后，WebView类的构造函数就会调用它的成员函数init启动网页渲染引擎。对于基于Chromium实现的WebView来说，它使用的WebView Provider是一个WebViewChromium对象。当这个WebViewChromium对象的成员函数init被调用的时候，它就会启动Chromium的网页渲染引擎。这个过程我们在接下来的一篇文章再详细分析。

接下来，我们继续分析WebView类的成员函数ensureProviderCreated的实现，如下所示：

public class WebView extends AbsoluteLayout
        implements ViewTreeObserver.OnGlobalFocusChangeListener,
        ViewGroup.OnHierarchyChangeListener, ViewDebug.HierarchyHandler {
    ......

    private void ensureProviderCreated() {
        checkThread();
        if (mProvider == null) {
            // As this can get called during the base class constructor chain, pass the minimum
            // number of dependencies here; the rest are deferred to init().
            mProvider = getFactory().createWebView(this, new PrivateAccess());
        }
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebView.java中。

WebView类的成员函数ensureProviderCreated首先调用成员函数checkThread确保它是在WebView的创建线程中调用的，接下来又会判断成员变量mProvider的值是否为null。如果为null，就表示它还没有当前创建的WebView创建过Provider。在这种情况下，它首先会调用成员函数getFactory获得一个WebView Factory。有了这个WebView Factory之后，就可以调用它的成员函数createWebView创建一个WebView Provider。

WebView类的成员函数getFactory的实现如下所示：

public class WebView extends AbsoluteLayout
        implements ViewTreeObserver.OnGlobalFocusChangeListener,
        ViewGroup.OnHierarchyChangeListener, ViewDebug.HierarchyHandler {
    ......

    private static synchronized WebViewFactoryProvider getFactory() {
        return WebViewFactory.getProvider();
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebView.java中。

WebView类的成员函数getFactory返回的WebView Factory是通过调用WebViewFactory类的静态成员函数getProvider获得的，如下所示：

public final class WebViewFactory {
    ......

    private static WebViewFactoryProvider sProviderInstance;
    ......

    static WebViewFactoryProvider getProvider() {
        synchronized (sProviderLock) {
            // For now the main purpose of this function (and the factory abstraction) is to keep
            // us honest and minimize usage of WebView internals when binding the proxy.
            if (sProviderInstance != null) return sProviderInstance;

            ......
            try {
                ......
                loadNativeLibrary();
                ......

                Class<WebViewFactoryProvider> providerClass;
                ......
                try {
                    providerClass = getFactoryClass();
                } catch (ClassNotFoundException e) {
                    ......
                } finally {
                    ......
                }

                ......
                try {
                    sProviderInstance = providerClass.newInstance();
                    ......
                    return sProviderInstance;
                } catch (Exception e) {
                    .......
                } finally {
                    ......
                }
            } finally {
                ......
            }
        }
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

WebViewFactory类的静态成员函数getProvider首先是判断静态成员变量sProviderInstance的值是否等于null。如果等于null，那么就说明当前的App进程还没有加载过Chromium动态库。在这种情况下，就需要加载Chromium动态库，并且创建一个WebView Factory，保存在静态成员变量sProviderInstance。接下来我们就先分析Chromium动态库的加载过程，然后再分析WebView Factory的创建过程。

加载Chromium动态库是通过调用WebViewFactory类的静态成员函数loadNativeLibrary实现的，如下所示：

public final class WebViewFactory {
    ......

    private static void loadNativeLibrary() {
        ......

        try {
            String[] args = getWebViewNativeLibraryPaths();
            boolean result = nativeLoadWithRelroFile(args[0] /* path32 */,
                                                     args[1] /* path64 */,
                                                     CHROMIUM_WEBVIEW_NATIVE_RELRO_32,
                                                     CHROMIUM_WEBVIEW_NATIVE_RELRO_64);
            ......
        } catch (PackageManager.NameNotFoundException e) {
            ......
        }
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

WebViewFactory类的静态成员函数loadNativeLibrary首先会调用我们前面分析过的成员函数getWebViewNativeLibraryPaths获得要加载的Chromium动态库的文件路径，然后再调用另外一个静态成员函数nativeLoadWithRelroFile对它进行加载。在加载的时候，会指定一个Chromium GNU_RELRO Section文件。这个Chromium GNU_RELRO Section文件就是前面通过启动一个临时进程生成的。

WebViewFactory类的静态成员函数nativeLoadWithRelroFile是一个JNI方法，它由C++层的函数LoadWithRelroFile实现，如下所示：

jboolean LoadWithRelroFile(JNIEnv* env, jclass, jstring lib32, jstring lib64,
                           jstring relro32, jstring relro64) {
#ifdef __LP64__
  jstring lib = lib64;
  jstring relro = relro64;
  (void)lib32; (void)relro32;
#else
  jstring lib = lib32;
  jstring relro = relro32;
  (void)lib64; (void)relro64;
#endif
  jboolean ret = JNI_FALSE;
  const char* lib_utf8 = env->GetStringUTFChars(lib, NULL);
  if (lib_utf8 != NULL) {
    const char* relro_utf8 = env->GetStringUTFChars(relro, NULL);
    if (relro_utf8 != NULL) {
      ret = DoLoadWithRelroFile(lib_utf8, relro_utf8);
      env->ReleaseStringUTFChars(relro, relro_utf8);
    }
    env->ReleaseStringUTFChars(lib, lib_utf8);
  }
  return ret;
}

这个函数定义在文件frameworks/webview/chromium/loader/loader.cpp中。

函数LoadWithRelroFile判断自己是32位还是64位的实现，然后从参数lib32和lib64中选择对应的Chromium动态库进行加载。这个加载过程是通过调用另外一个函数DoLoadWithRelroFile实现的，如下所示：

jboolean DoLoadWithRelroFile(const char* lib, const char* relro) {
  int relro_fd = TEMP_FAILURE_RETRY(open(relro, O_RDONLY));
  ......

  android_dlextinfo extinfo;
  extinfo.flags = ANDROID_DLEXT_RESERVED_ADDRESS | ANDROID_DLEXT_USE_RELRO;
  extinfo.reserved_addr = gReservedAddress;
  extinfo.reserved_size = gReservedSize;
  extinfo.relro_fd = relro_fd;
  void* handle = android_dlopen_ext(lib, RTLD_NOW, &extinfo);
  close(relro_fd);
  ......

  return JNI_TRUE;
}

这个函数定义在文件frameworks/webview/chromium/loader/loader.cpp中。

函数DoLoadWithRelroFile的实现与前面分析的函数DoCreateRelroFile类似，都是通过Linker导出的函数android_dlopen_ext在Zyogote进程保留的地址空间中加载Chromium动态库的。注意，App进程是Zygote进程fork出来的，因此它同样会获得Zygote进程预留的地址空间。

不过，函数DoLoadWithRelroFile会将告诉函数android_dlopen_ext在加载Chromium动态库的时候，将参数relro描述的Chromium GNU_RELRO Section文件内存映射到内存来，并且代替掉已经加载的Chromium动态库的GNU_RELRO Section。这是通过将指定一个ANDROID_DLEXT_USE_RELRO标志实现的。

之所以可以这样做，是因为参数relro描述的Chromium GNU_RELRO Section文件对应的Chromium动态库的加载地址与当前App进程加载的Chromium动态库的地址一致。只要两个相同的动态库在两个不同的进程中的加载地址一致，它们的链接和重定位信息就是完全一致的，因此就可以通过文件内存映射的方式进行共享。共享之后，就可以达到节省内存的目的了。

这一步执行完成之后，App进程就加载完成Chromium动态库了。回到前面分析的WebViewFactory类的静态成员函数getProvider，它接下来继续创建一个WebView Factory。这个WebView Factory以后就可以用来创建WebView Provider。

WebViewFactory类的静态成员函数getProvider首先要确定要创建的WebView Factory的类型。这个类型是通过调用另外一个静态成员函数getFactoryClass获得的，如下所示：

public final class WebViewFactory {

    private static final String CHROMIUM_WEBVIEW_FACTORY =
            "com.android.webview.chromium.WebViewChromiumFactoryProvider";

    ......

    private static Class<WebViewFactoryProvider> getFactoryClass() throws ClassNotFoundException {
        Application initialApplication = AppGlobals.getInitialApplication();
        try {
            // First fetch the package info so we can log the webview package version.
            String packageName = getWebViewPackageName();
            sPackageInfo = initialApplication.getPackageManager().getPackageInfo(packageName, 0);
            ......

            // Construct a package context to load the Java code into the current app.
            Context webViewContext = initialApplication.createPackageContext(packageName,
                    Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY);
            ......

            ClassLoader clazzLoader = webViewContext.getClassLoader();
            ......
            try {
                return (Class<WebViewFactoryProvider>) Class.forName(CHROMIUM_WEBVIEW_FACTORY, true,
                                                                     clazzLoader);
            } finally {
                ......
            }
        } catch (PackageManager.NameNotFoundException e) {
            ......
        }
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebViewFactory.java中。

从这里可以看到，WebViewFactory类的静态成员函数getFactoryClass返回的WebView Factory的类型为com.android.webview.chromium.WebViewChromiumFactoryProvider。这个com.android.webview.chromium.WebViewChromiumFactoryProvider类是由前面提到的WebView Package提供的。

这意味着WebViewFactory类的静态成员函数getProvider创建的WebView Factory是一个WebViewChromiumFactoryProvider对象。这个WebViewChromiumFactoryProvider的创建过程如下所示：

public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
    ......

    public WebViewChromiumFactoryProvider() {
        ......

        AwBrowserProcess.loadLibrary();

        .......
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromiumFactoryProvider.java中。

WebViewChromiumFactoryProvider类的构造函数会调用AwBrowserProcess类的静态成员函数loadLibrary对前面加载的Chromium动态库进行初始化，如下所示：

public abstract class AwBrowserProcess {
    ......

    public static void loadLibrary() {
        ......
        try {
            LibraryLoader.loadNow();
        } catch (ProcessInitException e) {
            throw new RuntimeException("Cannot load WebView", e);
        }
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwBrowserProcess.java中。

AwBrowserProcess类的静态成员函数loadLibrary又调用LibraryLoader类的静态成员函数loadNow对前面加载的Chromium动态库进行初始化，如下所示：

public class LibraryLoader {
    ......

    public static void loadNow() throws ProcessInitException {
        loadNow(null, false);
    }

    ......
}

这个函数定义在文件external/chromium_org/base/android/java/src/org/chromium/base/library_loader/LibraryLoader.java中。

LibraryLoader类的静态成员函数loadNow又调用另外一个重载版本的静态成员函数loadNow对前面加载的Chromium动态库进行初始化，如下所示：

public class LibraryLoader {
    ......

    public static void loadNow(Context context, boolean shouldDeleteOldWorkaroundLibraries)
            throws ProcessInitException {
        synchronized (sLock) {
            loadAlreadyLocked(context, shouldDeleteOldWorkaroundLibraries);
        }
    }

    ......
}

这个函数定义在文件external/chromium_org/base/android/java/src/org/chromium/base/library_loader/LibraryLoader.java中。

LibraryLoader类重载版本的静态成员函数loadNow又调用另外一个静态成员函数loadAlreadyLocked对前面加载的Chromium动态库进行初始化，如下所示：

public class LibraryLoader {
    ......

    // One-way switch becomes true when the libraries are loaded.
    private static boolean sLoaded = false;
    ......

    private static void loadAlreadyLocked(
            Context context, boolean shouldDeleteOldWorkaroundLibraries)
            throws ProcessInitException {
        try {
            if (!sLoaded) {
                ......

                boolean useChromiumLinker = Linker.isUsed();

                if (useChromiumLinker) Linker.prepareLibraryLoad();

                for (String library : NativeLibraries.LIBRARIES) {
                    Log.i(TAG, "Loading: " + library);
                    if (useChromiumLinker) {
                        Linker.loadLibrary(library);
                    } else {
                        try {
                            System.loadLibrary(library);
                        } catch (UnsatisfiedLinkError e) {
                            ......
                        }
                    }
                }
                if (useChromiumLinker) Linker.finishLibraryLoad();

                ......
                sLoaded = true;
            }
        } catch (UnsatisfiedLinkError e) {
            ......
        }
        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/base/android/java/src/org/chromium/base/library_loader/LibraryLoader.java中。

由于并不是所有的系统都支持在加载动态库时，以文件内存映射的方式代替它的GNU_RELRO Section，因此Chromium自己提供了一个Linker。通过这个Linker加载动态库时，能够以文件内存映射的方式代替要加载的动态库的GNU_RELRO Section，也就是实现前面提到的函数android_dlopen_ext的功能。

在Android 5.0中，由于系统已经提供了函数android_dlopen_ext，因此，Chromium就不会使用自己的Linker加载动态库，而是使用Android系统提供的Linker来加载动态库。通过调用System类的静态成员函数loadLibrary即可以使用系统提供的Linker来加载动态库。

LibraryLoader类的静态成员函数loadAlreadyLocked要加载的动态库由NativeLibraries类的静态成员变量LIBRARIES指定，如下所示：

public class NativeLibraries {
    ......

    static final String[] LIBRARIES = { "webviewchromium" };
    
    ......
}

这个静态成员变量定义在文件external/chromium_org/android_webview/java/generated_src/org/chromium/base/library_loader/NativeLibraries.java中。

从这里可以知道，LibraryLoader类的静态成员函数loadAlreadyLocked要加载的动态库就是Chromium动态库。这个Chromium动态库前面已经加载过了，因此这里通过调用System类的静态成员函数loadLibrary再加载时，仅仅是只会触发它导出的函数JNI_OnLoad被调用，而不会重新被加载。

Chromium动态库导出的JNI_OnLoad被调用的时候，Chromium动态库就会执行初始化工作，如下所示：

JNI_EXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved) {
  ......

  content::SetContentMainDelegate(new android_webview::AwMainDelegate());
  ......

  return JNI_VERSION_1_4;
}

这个函数定义在文件external/chromium_org/android_webview/lib/main/webview_entry_point.cc中。

其中的一个初始化操作是给Chromium的Content层设置一个类型为AwMainDelegate的Main Delegate。这个AwMainDelegate实现在Chromium的android_webview模块中。Android WebView是通过Chromium的android_webview模块加载和渲染网页的。Chromium加载和渲染网页的功能又是实现在Content层的，因此，Chromium的android_webview模块又要通过Content层实现加载和渲染网页功能。这样，Chromium的android_webview模块就可以设置一个Main Delegate给Content层，以便它们可以互相通信。

给Chromium的Content层设置一个Main Delegate是通过调用函数SetContentMainDelegate实现的，它的实现如下所示：

LazyInstance<scoped_ptr<ContentMainDelegate> > g_content_main_delegate =
    LAZY_INSTANCE_INITIALIZER;

......

void SetContentMainDelegate(ContentMainDelegate* delegate) {
  DCHECK(!g_content_main_delegate.Get().get());
  g_content_main_delegate.Get().reset(delegate);
}

这个函数定义在文件external/chromium_org/content/app/android/content_main.cc中。

从前面的分析可以知道，参数delegate指向的是一个AwMainDelegate对象，这个AwMainDelegate对象会被函数SetContentMainDelegate保存在全局变量g_content_main_delegate中。在接下来一篇文章中分析Chromium渲染引擎的启动过程时，我们就会看到这个AwMainDelegate对象的作用。

这一步执行完成后，Chromium动态库就在App进程中加载完毕，并且也已经完成了初始化工作。与此同时，系统也为App进程创建了一个类型为WebViewChromiumFactoryProvider的WebView Factory。回到前面分析的WebView类的成员函数ensureProviderCreated中，这时候就它会通过调用上述类型为WebViewChromiumFactoryProvider的WebView Factory的成员函数createWebView为当前创建的WebView创建一个WebView Provider，如下所示：

public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
    ......

    @Override
    public WebViewProvider createWebView(WebView webView, WebView.PrivateAccess privateAccess) {
        WebViewChromium wvc = new WebViewChromium(this, webView, privateAccess);

        ......

        return wvc;
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromiumFactoryProvider.java中。

WebViewChromiumFactoryProvider类的成员函数createWebView创建的是一个类型为WebViewChromium的WebView Provider。这个WebView Provider将会返回给WebView类的成员函数ensureProviderCreated。WebView类的成员函数ensureProviderCreated再将该WebView Provider保存在成员变量mProvider中。

这样，正在创建的WebView就获得了一个类型为WebViewChromium的WebView Provider。以后通过这个WebView Provider，就可以通过Chromium来加载和渲染网页了。

至此，我们也分析完成了Android WebView加载Chromium动态库的过程。在接下来的一篇文章中，我们继续分析Android WebView启动Chromium渲染引擎的过程。Chromium渲染引擎启动起来之后，Android WebView就可以通过它来加载和渲染网页了。敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/11/28 1:00:19 原文链接

阅读：40456 评论：4 查看评论

↧

Android WebView启动Chromium渲染引擎的过程分析

December 5, 2016, 1:02 am

≫ Next: Android WebView执行GPU命令的过程分析

≪ Previous: Android WebView加载Chromium动态库的过程分析

Android WebView加载了Chromium动态库之后，就可以启动Chromium渲染引擎了。Chromium渲染引擎由Browser、Render和GPU三端组成。其中，Browser端负责将网页UI合成在屏幕上，Render端负责加载网页的URL和渲染网页的UI，GPU端负责执行Browser端和Render端请求的GPU命令。本文接下来详细分析Chromium渲染引擎三端的启动过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

Android WebView使用了单进程架构的Chromium来加载和渲染网页，因此它的Browser端、Render端和GPU端都不是以进程的形式存在的，而是以线程的形式存在。其中，Browser端实现在App的UI线程中，Render端实现在一个独立的线程中，而GPU端实现在App的Render Thread中。注意，这是针对Android 5.0及以上版本的。Android在4.4版本引入基于Chromium实现的WebView，那时候GPU端与Browser一样，都是实现在App的UI线程中。接下来我们只讨论Android WebView在Android 5.0及以上版本的实现。

Android WebView启动Chromium渲染引擎三端的过程如图1所示：

图1 Android WebView启动Chromium渲染引擎的过程

从前面Android WebView加载Chromium动态库的过程分析一文可以知道，当我们在App的UI中嵌入一个WebView时，WebView会在内部创建一个类型为WebViewChromium的Provider。Android WebView就是通过这个Provider来启动和使用Chromium渲染引擎的。

Chromium里面有一个android_webview模块。这个模块提供了两个类AwBrowserProcess和AwContents，分别用来封装Chromium的Content层提供的两个接口类BrowserStartupController和ContentViewCore，它们分别用来启动Chromium的Browser端和Render端。

Android WebView启动Chromium的Browser端，实际上就是在App的UI线程创建一个Browser Main Loop。Chromium以后需要请求Browser端执行某一个操作时，就可以向这个Browser Main Loop发送一个Task。这个Task最终会在App进程的UI线程中调度执行。

Android WebView启动Chromium的Render端，实际上就是在当前的App进程中创建一个线程。以后网页就由这个线程负责加载和渲染。这个线程称为In-Process Renderer Thread。

由于Chromium的GPU端实现在App的Render Thread中，这个Render Thread是由App负责启动的，因此Chromium无需启动它。不过，Chromium里的android_webview模块会启动一个DeferredGpuCommandService服务。当Chromium的Browser端和Render端需要执行GPU操作时，就会向DeferredGpuCommandService服务发出请求。这时候DeferredGpuCommandService服务又会通过App的UI线程将请求的GPU操作提交给App的Render Thread执行。这一点可以参考前面Android WebView简要介绍和学习计划一文的描述。我们在接下来的一篇文章也会对Chromium的Browser端和Render端执行GPU操作的过程进行详细的分析。

接下来我们就结合源码，分析Android WebView启动Chromium的Browser端和Render端的过程。对于GPU端，我们仅仅分析与它相关的DeferredGpuCommandService服务的启动过程。在接下来一篇文章分析Android WebView执行GPU命令的过程时，我们再对GPU端进行更详细的分析。

我们首先分析Android WebView启动Chromium的Browser端的过程。前面提到，WebView会在内部创建一个类型为WebViewChromium的Provider。有了这个Provider之后，WebView就可以调用它的成员函数init启动Chromium的Browser端，如下所示：

class WebViewChromium implements WebViewProvider,
          WebViewProvider.ScrollDelegate, WebViewProvider.ViewDelegate {
    ......

    public void init(final Map<String, Object> javaScriptInterfaces,
            final boolean privateBrowsing) {
        ......

        // We will defer real initialization until we know which thread to do it on, unless:
        // - we are on the main thread already (common case),
        // - the app is targeting >= JB MR2, in which case checkThread enforces that all usage
        //   comes from a single thread. (Note in JB MR2 this exception was in WebView.java).
        if (mAppTargetSdkVersion >= Build.VERSION_CODES.JELLY_BEAN_MR2) {
            mFactory.startYourEngines(false);
            checkThread();
        } else if (!mFactory.hasStarted()) {
            if (Looper.myLooper() == Looper.getMainLooper()) {
                mFactory.startYourEngines(true);
            }
        }

        ......

        mRunQueue.addTask(new Runnable() {
                @Override
                public void run() {
                    initForReal();
                    ......
                }
        });
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromium.java中。

WebViewChromium类的成员变量mFactory指向的是一个WebViewChromiumFactoryProvider对象。WebViewChromium类的成员函数init通过调用这个WebViewChromiumFactoryProvider对象的成员函数startYourEngines启动Chromium渲染引擎的Browser端。

在Android 4.3之前，WebView只能在App的UI线程中创建。相应地，WebView也只能在App的UI线程中启动Chromium渲染引擎的Browser端。这时候WebViewChromium类的成员函数init会传递一个参数true给WebViewChromiumFactoryProvider类的成员函数startYourEngines，表示如果当前线程如果不是UI线程，那么就需要向UI线程发出一个通知，让UI线程执行启动Chromium渲染引擎的Browser端的操作。

在Android 4.3及以后，WebView也允许在App的非UI线程中创建。这时候WebView允行在App的非UI线程中启动Chromium渲染引擎的Browser端。因此，WebViewChromium类的成员函数init就会传递一个参数false给WebViewChromiumFactoryProvider类的成员函数startYourEngines。

一般情况下，WebView都是在App的UI线程中创建的。为了简单起见，我们只考虑这种情况。WebViewChromium类的成员函数init调用WebViewChromiumFactoryProvider类的成员函数startYourEngines启动了Chromium渲染引擎的Browser端之后，接下来还会向App的UI线程的消息队列发送一个Runnable。当该Runnable被执行的时候，它就会调用WebViewChromium类的成员函数initForReal创建图1所示的AwContents对象。有了这个AwContents对象之后，后面就可以通过它来加载指定的URL了。

接下来，我们首先分析WebViewChromiumFactoryProvider类的成员函数startYourEngines启动Chromium渲染引擎的Browser端的过程，然后再分析WebViewChromium类的成员函数initForReal为WebView创建AwContents对象的过程。

WebViewChromiumFactoryProvider类的成员函数startYourEngines的实现如下所示：

public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
    ......

    void startYourEngines(boolean onMainThread) {
        synchronized (mLock) {
            ensureChromiumStartedLocked(onMainThread);

        }
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromiumFactoryProvider.java中。

WebViewChromiumFactoryProvider类的成员函数startYourEngines调用另外一个成员函数ensureChromiumStartedLocked检查Chromium渲染引擎的Browser端是否已经启动。如果还没有启动，那么就会进行启动，如下所示：

public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
    ......

    private void ensureChromiumStartedLocked(boolean onMainThread) {
        ......

        if (mStarted) {  // Early-out for the common case.
            return;
        }

        Looper looper = !onMainThread ? Looper.myLooper() : Looper.getMainLooper();
        ......
        ThreadUtils.setUiThread(looper);

        if (ThreadUtils.runningOnUiThread()) {
            startChromiumLocked();
            return;
        }

        // We must post to the UI thread to cover the case that the user has invoked Chromium
        // startup by using the (thread-safe) CookieManager rather than creating a WebView.
        ThreadUtils.postOnUiThread(new Runnable() {
            @Override
            public void run() {
                synchronized (mLock) {
                    startChromiumLocked();
                }
            }
        });
        while (!mStarted) {
            try {
                // Important: wait() releases |mLock| the UI thread can take it :-)
                mLock.wait();
            } catch (InterruptedException e) {
                // Keep trying... eventually the UI thread will process the task we sent it.
            }
        }
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromiumFactoryProvider.java中。

如果Chromium渲染引擎的Browser端已经启动，那么WebViewChromiumFactoryProvider类的成员变量mStarted的值就会等于true。在这种情况下，WebViewChromiumFactoryProvider类的成员函数ensureChromiumStartedLocked什么也不用做就可以返回。

另一方面，如果Chromium渲染引擎的Browser端还没有启动，那么WebViewChromiumFactoryProvider类的成员函数ensureChromiumStartedLocked首先会根据参数onMainThread确定Chromium渲染引擎的Browser端要在哪个线程中运行。

当参数onMainThread的值等于true的时候，就表示Chromium渲染引擎的Browser端要在App的UI线程中运行。这时候如果当前线程不是App的UI线程，那么WebViewChromiumFactoryProvider类的成员函数ensureChromiumStartedLocked就会向App的UI线程的消息队列发送一个Runnable。当该Runnable被执行的时候，才会启动Chromium渲染引擎的Browser端。在这种情况下，当前线程也会等待App的UI线程启动完成Chromium渲染引擎的Browser端。

当参数onMainThread的值等于true的时候，如果当前线程刚好也是App的UI线程，那么WebViewChromiumFactoryProvider类的成员函数ensureChromiumStartedLocked就可以马上启动Chromium渲染引擎的Browser端。

当参数onMainThread的值等于false的时候，不管当前线程是否App的UI线程，都表示Chromium渲染引擎的Browser端要在它里面运行。因此，这时候WebViewChromiumFactoryProvider类的成员函数ensureChromiumStartedLocked都会马上启动Chromium渲染引擎的Browser端。

无论是上述的哪一种情况，用来运行Chromium渲染引擎的Browser端的线程都会通过调用ThreadUtils类的静态成员函数setUiThread记录起来。以后WebView都需要在该线程中访问Chromium渲染引擎。

WebViewChromiumFactoryProvider类的成员函数ensureChromiumStartedLocked是通过调用另外一个成员函数startChromiumLocked启动Chromium渲染引擎的Browser端的，如下所示：

public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
    ......

    private void startChromiumLocked() {
        ......

        AwBrowserProcess.start(ActivityThread.currentApplication());

        ......
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromiumFactoryProvider.java中。

WebViewChromiumFactoryProvider类的成员函数startChromiumLocked通过调用AwBrowserProcess类的静态成员函数start启动Chromium渲染引擎的Browser端的，如下所示：

public abstract class AwBrowserProcess {
    ......

    public static void start(final Context context) {
        // We must post to the UI thread to cover the case that the user
        // has invoked Chromium startup by using the (thread-safe)
        // CookieManager rather than creating a WebView.
        ThreadUtils.runOnUiThreadBlocking(new Runnable() {
            @Override
            public void run() {
                try {
                    BrowserStartupController.get(context).startBrowserProcessesSync(
                                BrowserStartupController.MAX_RENDERERS_SINGLE_PROCESS);
                    ......
                } catch (ProcessInitException e) {
                    ......
                }
            }
        });
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwBrowserProcess.java中。

前面提到，用来运行Chromium渲染引擎的Browser端的线程会通过ThreadUtils类的静态成员函数setUiThread记录起来。AwBrowserProcess类的静态成员函数start为了确保Chromium渲染引擎的Browser端在该线程中启动，会通过调用ThreadUtils类的静态成员函数runOnUiThreadBlocking检查当前线程是否就是该线程。如果是的话，那么就会直接启动。否则的话，会向该线程的消息队列发送一个Runnable。当该Runnable被执行的时候，再启动Chromium渲染引擎的Browser端。

AwBrowserProcess类的静态成员函数start是通过调用当前App进程中的一个BrowserStartupController单例对象的成员函数startBrowserProcessesSync来启动Chromium渲染引擎的Browser端的。这个BrowserStartupController单例对象可以通过调用BrowserStartupController类的静态成员函数get获得。

AwBrowserProcess类的静态成员函数start在启动Chromium渲染引擎的Browser端的时候，会指定一个BrowserStartupController.MAX_RENDERERS_SINGLE_PROCESS参数。这个参数的值等于0，表示要启动一个单进程架构的Chromium渲染引擎。

接下来，我们就继续分析Chromium渲染引擎的Browser端的启动过程，也就是BrowserStartupController类的成员函数startBrowserProcessesSync的实现，如下所示：

public class BrowserStartupController {
    ......

    public void startBrowserProcessesSync(int maxRenderers) throws ProcessInitException {
        // If already started skip to checking the result
        if (!mStartupDone) {
            if (!mHasStartedInitializingBrowserProcess) {
                prepareToStartBrowserProcess(maxRenderers);
            }

            ......
            if (contentStart() > 0) {
                // Failed. The callbacks may not have run, so run them.
                enqueueCallbackExecution(STARTUP_FAILURE, NOT_ALREADY_STARTED);
            }
        }

        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/content/public/android/java/src/org/chromium/content/browser/BrowserStartupController.java中。

当BrowserStartupController类的成员变量mStartupDone的值等于true的时候，就表示Chromium渲染引擎的Browser端已经启动了。这时候BrowserStartupController类的成员函数startBrowserProcessesSync就什么也不做就直接返回。

另一方面，如果Chromium渲染引擎的Browser端还没有启动。这时候BrowserStartupController类的成员函数startBrowserProcessesSync就会调用另外一个成员函数contentStart进行启动。

在启动Chromium渲染引擎的Browser端之前，BrowserStartupController类的成员函数startBrowserProcessesSync也会检查成员变量mHasStartedInitializingBrowserProcess的值。当这个值等于false的时候，就会先调用成员函数prepareToStartBrowserProcess设置Chromium渲染引擎的启动参数。其中，最重要的就是将Chromium渲染引擎设置为单进程架构。

接下来，我们先分析将Chromium渲染引擎设置为单进程架构的过程，也就是BrowserStartupController类的成员函数prepareToStartBrowserProcess的实现，然后再分析启动Chromium渲染引擎的Browser端的过程，也就是BrowserStartupController类的成员函数contentStart的实现。

BrowserStartupController类的成员函数prepareToStartBrowserProcess的实现如下所示：

public class BrowserStartupController {
    ......

    void prepareToStartBrowserProcess(int maxRendererProcesses) throws ProcessInitException {
        ......

        nativeSetCommandLineFlags(maxRendererProcesses,
                nativeIsPluginEnabled() ? getPlugins() : null);
        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/content/public/android/java/src/org/chromium/content/browser/BrowserStartupController.java中。

BrowserStartupController类的成员函数prepareToStartBrowserProcess调用另外一个成员函数nativeSetCommandLineFlags将Chromium渲染引擎设置为单进程架构。

BrowserStartupController类的成员函数nativeSetCommandLineFlags是一个JNI方法，它由C++层的函数Java_com_android_org_chromium_content_browser_BrowserStartupController_nativeSetCommandLineFlags实现，如下所示：

__attribute__((visibility("default")))
void
    Java_com_android_org_chromium_content_browser_BrowserStartupController_nativeSetCommandLineFlags(JNIEnv*
    env, jclass jcaller,
    jint maxRenderProcesses,
    jstring pluginDescriptor) {
  return SetCommandLineFlags(env, jcaller, maxRenderProcesses,
      pluginDescriptor);
}

这个函数定义在文件out/target/product/generic/obj/GYP/shared_intermediates/content/jni/BrowserStartupController_jni.h中。

函数Java_com_android_org_chromium_content_browser_BrowserStartupController_nativeSetCommandLineFlags调用另外一个函数SetCommandLineFlags将Chromium渲染引擎设置为单进程架构，如下所示：

static void SetCommandLineFlags(JNIEnv* env,
                                jclass clazz,
                                jint max_render_process_count,
                                jstring plugin_descriptor) {
  std::string plugin_str =
      (plugin_descriptor == NULL
           ? std::string()
           : base::android::ConvertJavaStringToUTF8(env, plugin_descriptor));
  SetContentCommandLineFlags(max_render_process_count, plugin_str);
}

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

函数SetCommandLineFlags又会调用另外一个函数SetContentCommandLineFlags将Chromium渲染引擎设置为单进程架构，如下所示：

void SetContentCommandLineFlags(int max_render_process_count,
                                const std::string& plugin_descriptor) {
  ......

  CommandLine* parsed_command_line = CommandLine::ForCurrentProcess();
  
  int command_line_renderer_limit = -1;
  if (parsed_command_line->HasSwitch(switches::kRendererProcessLimit)) {
    std::string limit = parsed_command_line->GetSwitchValueASCII(
        switches::kRendererProcessLimit);
    int value;
    if (base::StringToInt(limit, &value)) {
      command_line_renderer_limit = value;
      if (value <= 0)
        max_render_process_count = 0;
    }
  }

  if (command_line_renderer_limit > 0) {
    int limit = std::min(command_line_renderer_limit,
                         static_cast<int>(kMaxRendererProcessCount));
    RenderProcessHost::SetMaxRendererProcessCount(limit);
  } else if (max_render_process_count <= 0) {
    // Need to ensure the command line flag is consistent as a lot of chrome
    // internal code checks this directly, but it wouldn't normally get set when
    // we are implementing an embedded WebView.
    parsed_command_line->AppendSwitch(switches::kSingleProcess);
  } else {
    int default_maximum = RenderProcessHost::GetMaxRendererProcessCount();
    DCHECK(default_maximum <= static_cast<int>(kMaxRendererProcessCount));
    if (max_render_process_count < default_maximum)
      RenderProcessHost::SetMaxRendererProcessCount(max_render_process_count);
  }

  ......
}

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

函数SetContentCommandLineFlags首先检查Android WebView是否设置了switches::kRendererProcessLimit命令行参数。如果设置了，那么这个参数的值就会被解析出来，保存在本地变量command_line_renderer_limit中，用来限定Chromium渲染引擎最多可创建的Render进程的个数的。

Chromium渲染引擎最多可创建的Render进程的个数还受到参数max_render_process_count的限制：

1. 当本地变量command_line_renderer_limit的值大于0的时候，那么取max_render_process_count和command_line_renderer_limit之间的较小者作为最多可创建的Render进程的个数。

2. 当本地变量command_line_renderer_limit的值小于等于0，并且参数max_render_process_count的值也小于等于0的时候，那么Chromium渲染引擎不允许创建Render进程，也就是它使用的是单进程架构。

3. 当本地变量command_line_renderer_limit的值小于等于0，并且参数max_render_process_count的值大于0的时候，会调用RenderProcessHost类的静态成员函数GetMaxRendererProcessCount根据设备内存的大小计算出可以创建的Render进程的最大数default_maximum。如果参数max_render_process_count的值小于这个最大值，那么就将它设置为可以创建的Render进程的个数。

在我们这个情景中，Android WebView没有设置switches::kRendererProcessLimit命令行参数，并且参数max_render_process_count的值等于0，因此函数SetContentCommandLineFlags会将Chromium渲染引擎设置为单进程架构。这是通过在Android WebView的命令行参数中设置一个switches::kSingleProcess选项实现的。

这一步执行完成后，回到前面分析的BrowserStartupController类的成员函数startBrowserProcessesSync中，接下来它会调用另外一个成员函数contentStart启动Chromium渲染引擎的Browser端，如下所示：

public class BrowserStartupController {
    ......

    int contentStart() {
        return ContentMain.start();
    }

    ......
}

这个函数定义在文件external/chromium_org/content/public/android/java/src/org/chromium/content/browser/BrowserStartupController.java中。

BrowserStartupController类的成员函数contentStart调用ContentMain类的静态成员函数Start启动Chromium渲染引擎的Browser端，如下所示：

public class ContentMain {
    ......

    public static int start() {
        return nativeStart();
    }

    ......
}

这个函数定义在文件external/chromium_org/content/public/android/java/src/org/chromium/content/app/ContentMain.java中。

ContentMain类的静态成员函数Start调用另外一个静态成员函数nativeStart启动Chromium渲染引擎的Browser端。

ContentMain类的静态成员函数nativeStart是一个JNI方法，它由C++层的函数Java_com_android_org_chromium_content_app_ContentMain_nativeStart实现，如下所示：

__attribute__((visibility("default")))
jint Java_com_android_org_chromium_content_app_ContentMain_nativeStart(JNIEnv*
    env, jclass jcaller) {
  return Start(env, jcaller);
}

这个函数定义在文件out/target/product/generic/obj/GYP/shared_intermediates/content/jni/ContentMain_jni.h中。

函数Java_com_android_org_chromium_content_app_ContentMain_nativeStart调用另外一个函数Start启动Chromium渲染引擎的Browser端，如下所示：

LazyInstance<scoped_ptr<ContentMainRunner> > g_content_runner =
    LAZY_INSTANCE_INITIALIZER;

LazyInstance<scoped_ptr<ContentMainDelegate> > g_content_main_delegate =
    LAZY_INSTANCE_INITIALIZER;

......

static jint Start(JNIEnv* env, jclass clazz) {
  ......

  if (!g_content_runner.Get().get()) {
    ContentMainParams params(g_content_main_delegate.Get().get());
    g_content_runner.Get().reset(ContentMainRunner::Create());
    g_content_runner.Get()->Initialize(params);
  }
  return g_content_runner.Get()->Run();
}

这个函数定义在文件external/chromium_org/content/app/android/content_main.cc中。

函数Start判断全局变量g_content_runner是否已经指向了一个ContentMainRunner对象。如果还没有指向，那么就说明Chromium渲染引擎的Browser端还没有启动。在这种情况下，函数Start就会调用ContentMainRunner类的静态成员函数Create创建一个ContentMainRunner对象，并且保存在全局变量g_content_runner中。

ContentMainRunner类的静态成员函数Create的实现如下所示：

ContentMainRunner* ContentMainRunner::Create() {
  return new ContentMainRunnerImpl();
}

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

从这里可以看到，ContentMainRunner类的静态成员函数Create实际创建的是一个ContentMainRunnerImpl对象。这个ContentMainRunnerImpl返回给函数Start之后，它的成员函数Initialize就会被调用，用来对它进行初始化。

从前面Android WebView加载Chromium动态库的过程分析一文可以知道，全局变量g_content_main_delegate指向的是一个AwMainDelegate对象。这个AwMainDelegate对象将会封装在一个ContentMainParams对象中，并且传递给前面创建的ContentMainRunnerImpl对象的成员函数Initialize，以便后者用来执行初始化工作。

ContentMainRunnerImpl类的成员函数Initialize的实现如下所示：

class ContentMainRunnerImpl : public ContentMainRunner {
 public:
  ......

  virtual int Initialize(const ContentMainParams& params) OVERRIDE {
    ......

    delegate_ = params.delegate;
    ......

    int exit_code;
    if (delegate_ && delegate_->BasicStartupComplete(&exit_code))
      return exit_code;
    ......
    
    const CommandLine& command_line = *CommandLine::ForCurrentProcess();
    std::string process_type =
        command_line.GetSwitchValueASCII(switches::kProcessType);

    ......

    ContentClientInitializer::Set(process_type, delegate_);

    ......
}

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

参数params描述的ContentMainParams对象的成员变量delegate指向的是就是前面描述的全局变量g_content_main_delegate指向的AwMainDelegate对象。ContentMainRunnerImpl类的成员函数Initialize会将这个AwMainDelegate对象保存在成员变量delegate_中，并且会调用这个AwMainDelegate对象的成员函数BasicStartupComplete执行一些基本的初始化工作，如下所示：

bool AwMainDelegate::BasicStartupComplete(int* exit_code) {
  content::SetContentClient(&content_client_);
  ......
}

这个函数定义在文件external/chromium_org/android_webview/lib/main/aw_main_delegate.cc中。

AwMainDelegate类的成员变量content_client_描述的是一个AwContentClient对象。这个AwContentClient对象将会设置给Chromium的Content层。这个通过调用函数SetContentClient实现的，如下所示：

static ContentClient* g_client;

......

void SetContentClient(ContentClient* client) {
  g_client = client;
  ......
}

ContentClient* GetContentClient() {
  return g_client;
}

这个函数定义在文件external/chromium_org/content/public/common/content_client.cc中。

函数SetContentClient将参数client指向的一个AwContentClient对象保存在全局变量g_client中。这个AwContentClient对象以后可以通过调用函数GetContentClient获得。

这一步执行完成后，回到前面分析的ContentMainRunnerImpl类的成员函数Initialize的中，它接下来检查Android WebView是否设置了switches::kProcessType命令行参数。如果设置了，那么该参数值process_type描述的就是当前启动的进程的类型（Browser端、Render端或者GPU端）。如果没有设置，那么参数值process_type就会等于一个空字符串，表示当前要启动的是一个Browser端。

在我们这个情景中，Android WebView没有设置switches::kProcessType，因此得到的参数值process_type就等于一个空字符串。这个空字符串，连同ContentMainRunnerImpl类的成员变量delegate_指向的AwMainDelegate对象，会进一步传递给ContentClientInitializer类的静态成员函数Set执行初始化操作，如下所示：

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();
      ......
    }

    ......
  }
 
  ......
};

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

ContentClientInitializer类的静态成员函数Set首先是调用前面提到的函数GetContentClient获得一个AwContentClient对象，接下来判断参数process_type的值是否等于一个空字符串。如果等于的话，那么就会调用参数delegate指向的一个AwMainDelegate对象的成员函数CreateContentBrowserClient创建一个ContentBrowserClient对象，并且保存在前面获得的AwContentClient对象的成员变量browser_中。

从前面的分析可以知道，参数process_type的值等于一个空字符串，因此接下来ContentClientInitializer类的静态成员函数Set就会调用参数delegate指向的AwMainDelegate对象的成员函数CreateContentBrowserClient创建一个ContentBrowserClient对象，如下所示：

content::ContentBrowserClient*
    AwMainDelegate::CreateContentBrowserClient() {
  content_browser_client_.reset(new AwContentBrowserClient(this));
  return content_browser_client_.get();
}

这个函数定义在文件external/chromium_org/android_webview/lib/main/aw_main_delegate.cc中。

AwMainDelegate类的成员函数CreateContentBrowserClient实际创建的是一个AwContentBrowserClient对象。这个AwContentBrowserClient对象是从ContentBrowserClient类继承下来的。

这意味着前面设置到Conent层的一个AwContentClient对象的成员变量browser_指向的是一个AwContentBrowserClient对象。这个AwContentBrowserClient对象在接下来启动Chromium渲染引擎的Browser端过程中会使用到。

这一步执行完成后，回到前面分析的函数Start中。这时候它就创建了一个ContentMainRunner对象，并且对这个ContentMainRunner对象进行初始化。接下来，函数Start继续调用这个ContentMainRunner对象的成员函数Run，以便启动Chromium渲染引擎的Browser端，如下所示：

class ContentMainRunnerImpl : public ContentMainRunner {
 public:
  ......

  virtual int Run() OVERRIDE {
    ......
    const CommandLine& command_line = *CommandLine::ForCurrentProcess();
    std::string process_type =
          command_line.GetSwitchValueASCII(switches::kProcessType);

    MainFunctionParams main_params(command_line);
    ......

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

  ......
};

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

ContentMainRunner类的成员函数Run首先获得Android WebView设置的命令行参数switches::kProcessType的值。前面提到，Android WebView没有设置命令行参数switches::kProcessType，因此这里获得的值为一个空字符串，也就是本地变量process_type的值等于一个空字符串。

接下来，ContentMainRunner类的成员函数Run还会将Android WebView设置的命令行参数封装在一个MainFunctionParams对象中。这个MainFunctionParams对象，连同前面设置的本地变量process_type，以及ContentMainRunner类的成员变量delegate_指向的一个AwMainDelegate对象，会传递给另外一个函数RunNamedProcessTypeMain。这个函数将会负责启动Chromium渲染引擎的Browser端，如下所示：

   const MainFunctionParams& main_function_params,
    ContentMainDelegate* delegate) {
  static const MainFunction kMainFunctions[] = {
#if !defined(CHROME_MULTIPLE_DLL_CHILD)
    { "",                            BrowserMain },
#endif
    ......
    { switches::kRendererProcess,    RendererMain },
    { switches::kGpuProcess,         GpuMain }, 
    ......
  };

  RegisterMainThreadFactories();

  for (size_t i = 0; i < arraysize(kMainFunctions); ++i) {
    if (process_type == kMainFunctions[i].name) {
      if (delegate) {
        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;
      }
      return kMainFunctions[i].function(main_function_params);
    }
  }

  ......
}

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

函数RunNamedProcessTypeMain定义了一个MainFunction数组。这个MainFunction数组用来指定不同类型的进程的入口函数。其中，Browser进程、Render进程和GPU进程对应的入口函数分别为BrowserMain、RendererMain和GpuMain。当然，只有在参数delegate的值等于NULL的情况下，这个MainFunction数组才会生效。否则的话，所有进程的入口函数都为该参数指向的ContentMainDelegate对象的成员函数RunProcess。对于非Browser进程，如果参数delegate指向的ContentMainDelegate对象的成员函数RunProcess的返回值小于0，那么上述MainFunction数组也会同样生效。

从前面的调用过程可以知道，参数process_type的值是一个空字符串，表示函数RunNamedProcessTypeMain需要启动的是一个Chromium渲染引擎的Browser进程（端）。这时候由于另外一个参数delegate指向了一个AwMainDelegate对象，因此，函数RunNamedProcessTypeMain将调用这个AwMainDelegate对象的成员函数RunProcess启动Chromium渲染引擎的Browser端。

函数RunNamedProcessTypeMain在调用参数delegate指向的AwMainDelegate对象的成员函数RunProcess启动Chromium渲染引擎的Browser端之前，还会调用函数RegisterMainThreadFactories注册一些线程创建工厂函数，如下所示：

static void RegisterMainThreadFactories() {
#if !defined(CHROME_MULTIPLE_DLL_BROWSER)
  ......
  RenderProcessHostImpl::RegisterRendererMainThreadFactory(
      CreateInProcessRendererThread);
  ......
#else
  ......
#endif
}

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

其中的一个线程创建工厂函数是Render线程创建工厂函数，它被指定为函数CreateInProcessRendererThread，并且会通过调用RenderProcessHostImpl类的静态成员函数RegisterRendererMainThreadFactory记录起来，如下所示：

RendererMainThreadFactoryFunction g_renderer_main_thread_factory = NULL;

......

void RenderProcessHostImpl::RegisterRendererMainThreadFactory(
    RendererMainThreadFactoryFunction create) {
  g_renderer_main_thread_factory = create;
}

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

参数create描述的函数CreateInProcessRendererThread将会保存在全局变量g_renderer_main_thread_factory中。以后Chromium渲染引擎的Browser端将会通过这个函数创建In-Process Renderer Thread，以便用来加载和渲染指定的URL。

这一步执行完成后，回到前面分析的函数RunNamedProcessTypeMain，接下来它就会调用参数delegate指向的AwMainDelegate对象的成员函数RunProcess启动Chromium渲染引擎的Browser端，如下所示：

int AwMainDelegate::RunProcess(
    const std::string& process_type,
    const content::MainFunctionParams& main_function_params) {
  if (process_type.empty()) {
    ......

    browser_runner_.reset(content::BrowserMainRunner::Create());
    int exit_code = browser_runner_->Initialize(main_function_params);
    ......

    return 0;
  }

  return -1;
}

这个函数定义在文件external/chromium_org/android_webview/lib/main/aw_main_delegate.cc中。

从前面的调用过程可以知道，参数process_type的值等于一个空字符串。在这种情况下，AwMainDelegate类的成员函数RunProcess会调用BrowserMainRunner类的静态成员函数Create创建一个BrowserMainRunner对象，并且会保存在成员变量browser_runner_中，如下所示：

BrowserMainRunner* BrowserMainRunner::Create() {
  return new BrowserMainRunnerImpl();
}

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

从这里可以看到，BrowserMainRunner类的静态成员函数Create创建的实际上是一个BrowserMainRunnerImpl对象。这意味着AwMainDelegate类的成员变量browser_runner_指向的是一个BrowserMainRunnerImpl对象。这个BrowserMainRunnerImpl对象的成员函数Initialize接下来会被调用。在调用的过程中，就会将Chromium渲染引擎的Browser端启动起来，如下所示：

class BrowserMainRunnerImpl : public BrowserMainRunner {
 public:
  ......

  virtual int Initialize(const MainFunctionParams& parameters) OVERRIDE {
    ......

    if (!initialization_started_) {
      initialization_started_ = true;
      ......

      main_loop_.reset(new BrowserMainLoop(parameters));

      main_loop_->Init();

      main_loop_->EarlyInitialization();

      ......

      main_loop_->MainMessageLoopStart();

      ......
    }

    main_loop_->CreateStartupTasks();
    int result_code = main_loop_->GetResultCode();
    if (result_code > 0)
      return result_code;

    // Return -1 to indicate no early termination.
    return -1;
  }

  ......
}

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

BrowserMainRunnerImpl类的成员函数Initialize首先检查成员变量initialization_started_的值是否等于true。如果等于true，那么就说明Chromium渲染引擎的Browser端已经启动过。在这种情况下，BrowserMainRunnerImpl类的成员函数Initialize只会创建一些Startup Task。

如果Chromium渲染引擎的Browser端还没有启动过，那么BrowserMainRunnerImpl类的成员函数Initialize首先就会创建一个BrowserMainLoop对象，并且保存在成员变量main_loop_中。接下来，BrowserMainRunnerImpl类的成员函数Initialize会调用上述BrowserMainLoop对象的成员函数Init和EarlyInitialization对其进行初始化。初始化完成后，它的成员函数MainMessageLoopStart又会被调用。调用完成后，Chromium渲染引擎的Browser端就启动完成了。启动完成后，上述BrowserMainLoop对象的成员函数CreateStartupTasks也会被调用，用来创建一些Startup Task。

接下来，我们就分别分析BrowserMainLoop类的成员函数Init、EarlyInitialization、MainMessageLoopStart和CreateStartupTasks的实现，以便了解Chromium渲染引擎的Browser端的启动过程。

BrowserMainLoop类的成员函数Init用来创建一个BrowserMainParts对象，它的实现如下所示：

void BrowserMainLoop::Init() {
  ......
  parts_.reset(
      GetContentClient()->browser()->CreateBrowserMainParts(parameters_));
}

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

BrowserMainLoop类的成员函数Init首先调用前面提到的函数GetContentClient获得一个AwContentClient对象，接下来又会调用这个AwContentClient对象的成员函数browser获得它的成员变量browser_指向的一个AwContentBrowserClient对象。获得了这个AwContentBrowserClient对象之后，就可以调用它的成员函数CreateBrowserMainParts创建一个BrowserMainParts对象，并且保存在BrowserMainLoop类的成员变量parts_中，如下所示：

content::BrowserMainParts* AwContentBrowserClient::CreateBrowserMainParts(
    const content::MainFunctionParams& parameters) {
  return new AwBrowserMainParts(browser_context_.get());
}

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

从这里可以看出，AwContentBrowserClient类的成员函数CreateBrowserMainParts创建的实际上是一个AwBrowserMainParts对象。这个AwBrowserMainParts对象接下来会用来创建一个Native层的UI Message Loop。这个UI Message Loop接下来又会用来创建一个Browser Thread，用来表示Chromium渲染引擎的Browser端。

这一步执行完成后，回到前面分析的BrowserMainRunnerImpl类的成员函数Initialize中，接下来BrowserMainLoop类的成员函数EarlyInitialization会被调用，用来创建一个Native层的UI Message Loop，如下所示：

void BrowserMainLoop::EarlyInitialization() {
  ......

  if (parts_)
    parts_->PreEarlyInitialization();
  
  ......
}

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

从前面的分析可以知道，BrowserMainLoop类的成员变量parts_指向的是一个AwBrowserMainParts对象。BrowserMainLoop类的成员函数EarlyInitialization会调用这个AwBrowserMainParts对象的成员函数PreEarlyInitialization创建一个UI Message Loop，如下所示：

void AwBrowserMainParts::PreEarlyInitialization() {
  ......
  main_message_loop_.reset(new base::MessageLoopForUI);
  base::MessageLoopForUI::current()->Start();
}

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

AwBrowserMainParts类的成员函数PreEarlyInitialization创建了一个MessageLoopForUI对象。这个MessageLoopForUI对象描述的就是一个Native层的UI Message Loop。从前面Chromium多线程模型设计和实现分析一文可以知道，Native层的UI Message Loop并没有自己的线程，而是寄生在App的UI线程中运行（当前线程就是App的UI线程）。App的UI线程在Java层也有一个Message Loop，并且是由这个Java层的Message Loop驱动运行的。

当我们往Native层的UI Message Loop发送一个消息的时候，Native层的UI Message Loop会向App的UI线程在Java层的Message Loop发送一个消息。当该消息被Java层的Message Loop调度执行的时候，之前发送在Native层的UI Message Loop中的消息就会得到执行。Chromium渲染引擎的Browser端，就是以这种方式运行在App的UI线程中的。

AwBrowserMainParts类的成员函数PreEarlyInitialization在当前线程中创建了一个MessageLoopForUI对象之后，以后在当前线程中调用MessageLoopForUI类的静态成员函数current时，就会获得该MessageLoopForUI对象。有了这个MessageLoopForUI对象之后，AwBrowserMainParts类的成员函数PreEarlyInitialization就会调用它的成员函数Start，用来启动它描述的Native UI Message Loop。

这一步执行完成后，回到前面分析的BrowserMainRunnerImpl类的成员函数Initialize中，接下来BrowserMainLoop类的成员函数MainMessageLoopStart会被调用，用来创建一个Browser Thread，如下所示：

void BrowserMainLoop::MainMessageLoopStart() {
  ......

  InitializeMainThread();

  .....
}

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

BrowserMainLoop类的成员函数MainMessageLoopStart调用另外一个成员函数InitializeMainThread创建一个Browser Thread，如下所示：

void BrowserMainLoop::InitializeMainThread() {
  ......
  main_thread_.reset(
      new BrowserThreadImpl(BrowserThread::UI, base::MessageLoop::current()));
}

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

BrowserMainLoop类的成员函数InitializeMainThread使用前面创建的Native UI Message Loop创建了一个Browser Thread。这个Browser Thread描述的就是Chromium渲染引擎的Browser端。由于这个Browser Thread是使用前面创建的Native UI Message Loop创建的，因此，它实际上描述的是App的UI线程。以后Chromium请求这个Browser Thread执行操作时，这个操作就会在App的UI线程中执行。

这一步执行完成之后，Chromium渲染引擎的Browser端就启动完成了。再回到前面分析的BrowserMainRunnerImpl类的成员函数Initialize中，接下来BrowserMainLoop类的成员函数CreateStartupTasks会被调用，用来在Chromium渲染引擎的Browser端执行一些Startup Task，如下所示：

void BrowserMainLoop::CreateStartupTasks() {
  ......

  if (!startup_task_runner_.get()) {
    ......

    StartupTask pre_create_threads =
        base::Bind(&BrowserMainLoop::PreCreateThreads, base::Unretained(this));
    startup_task_runner_->AddTask(pre_create_threads);

    ......
  }

  ......
}

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

其中的一个Startup Task，是在Chromium渲染引擎的Browser端创建其它线程（IO线程、数据库线程、文件线程等）之前执行的，对应的函数为BrowserMainLoop类的成员函数PreCreateThreads。

BrowserMainLoop类的成员函数PreCreateThread会检查Android WebView的命令行参数是否设置了一个switches::kSingleProcess选项。如果设置了，那么就会将Chromium渲染引擎设置为单进程架构，如下所示：

int BrowserMainLoop::PreCreateThreads() {
  ......

#if !defined(OS_IOS) && (!defined(GOOGLE_CHROME_BUILD) || defined(OS_ANDROID))
  // Single-process is an unsupported and not fully tested mode, so
  // don't enable it for official Chrome builds (except on Android).
  if (parsed_command_line_.HasSwitch(switches::kSingleProcess))
    RenderProcessHost::SetRunRendererInProcess(true);
#endif
  return result_code_;
}

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

从前面的分析可以知道，函数SetContentCommandLineFlags会给Android WebView的命令行参数设置一个switches::kSingleProcess选项。在这种情况下，BrowserMainLoop类的成员函数PreCreateThread会调用RenderProcessHost类的静态成员函数SetRunRendererInProcess将Chromium渲染引擎设置为单进程架构，如下所示：

bool g_run_renderer_in_process_ = false;

......

void RenderProcessHost::SetRunRendererInProcess(bool value) {
  g_run_renderer_in_process_ = value;

  ......
}

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

从前面的调用过程可以知道，参数value的值等于true。这时候RenderProcessHost类的静态成员函数SetRunRendererInProcess就会将全局变量g_run_renderer_in_process_的值设置为true，表示Chromium渲染引擎使用单进程加载，也就是在需要创建Render进程来加载和渲染网页时，通过一个In-Process Renderer Thread模拟。

这一步执行完成后，Chromium渲染引擎的Browser端就启动完毕。回到前面分析的WebViewChromium类的成员函数init中，接下来它会继续调用另外一个成员函数initForReal为WebView创建一个AwContents对象。这个AwContents对象以后可以用来加载指定的URL。

接下来，我们就继续分析WebViewChromium类的成员函数initForReal创建AwContents对象的过程，如下所示：

class WebViewChromium implements WebViewProvider,
          WebViewProvider.ScrollDelegate, WebViewProvider.ViewDelegate {
    ......

    private void initForReal() {
        ......
        mAwContents = new AwContents(mFactory.getBrowserContext(), mWebView, ctx,
                new InternalAccessAdapter(), new WebViewNativeGLDelegate(),
                mContentsClientAdapter, mWebSettings.getAwSettings());

        ......
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromium.java中。

WebViewChromium类的成员函数initForReal主要是创建了一个AwContents对象，并且保存在成员变量mAwContents中。这个AwContents对象的创建过程，也就是AwContents类的构造函数的实现，如下所示：

public class AwContents {
    ......

    public AwContents(AwBrowserContext browserContext, ViewGroup containerView, Context context,
            InternalAccessDelegate internalAccessAdapter, NativeGLDelegate nativeGLDelegate,
            AwContentsClient contentsClient, AwSettings awSettings) {
        this(browserContext, containerView, context, internalAccessAdapter, nativeGLDelegate,
                contentsClient, awSettings, new DependencyFactory());
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwContents.java中。

AwContents类的构造函数调用另外一个重载版本的构造函数创建一个AwContents对象，如下所示：

public class AwContents {
    ......

    public AwContents(AwBrowserContext browserContext, ViewGroup containerView, Context context,
            InternalAccessDelegate internalAccessAdapter, NativeGLDelegate nativeGLDelegate,
            AwContentsClient contentsClient, AwSettings settings,
            DependencyFactory dependencyFactory) {
        ......
        mNativeGLDelegate = nativeGLDelegate;
        ......

        setNewAwContents(nativeInit(mBrowserContext));

        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwContents.java中。

参数nativeGLDelegate指向的是一个WebViewNativeGLDelegate对象。这个WebViewNativeGLDelegate对象会被保存在AwContents类的成员变量mNativeGLDelegate中。

AwContents类的构造函数会调用另外一个成员函数nativeInit在Native层创建一个WebContents对象。WebContents类是Chromium的Content层向外提供的一个类，通过它可以描述一个网页。

在Native层创建了一个WebContents对象之后，AwContents类的构造函数会将该WebContents对象传递给另外一个成员函数setNewAwContents，用来在Native层创建一个ContentViewCore对象。ContentViewCore类同样是Chromium的Content层向外提供的一个类，通过它可以加载一个指定的URL，也就是通过可以启动Chromium渲染引擎的Render端。

接下来，我们就继续分析AwContents成员函数nativeInit和setNewAwContents的实现，以便了解Android WebView在Native层ContentViewCore对象的过程，为接下来分析Chromium渲染引擎的Render端的启动过程做准备。

AwContents成员函数nativeInit是一个JNI方法，它由C++层的函数Java_com_android_org_chromium_android_1webview_AwContents_nativeInit实现，如下所示：

__attribute__((visibility("default")))
jlong
    Java_com_android_org_chromium_android_1webview_AwContents_nativeInit(JNIEnv*
    env, jclass jcaller,
    jobject browserContext) {
  return Init(env, jcaller, browserContext);
}

这个函数定义在文件out/target/product/generic/obj/GYP/shared_intermediates/android_webview/jni/AwContents_jni.h中。

函数Java_com_android_org_chromium_android_1webview_AwContents_nativeInit调用另外一个函数Init创建一个WebContents对象，并且使用这个WebContents对象创建一个Native层的AwContents对象，如下所示：

static jlong Init(JNIEnv* env, jclass, jobject browser_context) {
  ......
  scoped_ptr<WebContents> web_contents(content::WebContents::Create(
      content::WebContents::CreateParams(AwBrowserContext::GetDefault())));
  ......
  return reinterpret_cast<intptr_t>(new AwContents(web_contents.Pass()));
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

函数Init是通过调用WebContents类的静态成员函数Create创建一个WebContents对象的。WebContents类的静态成员函数Create的实现，可以参考前面Chromium网页Frame Tree创建过程分析一文。

创建了一个WebContents对象之后，函数Init就使用它来创建一个Native层的AwContents对象，如下所示：

AwContents::AwContents(scoped_ptr<WebContents> web_contents)
    : web_contents_(web_contents.Pass()),
      shared_renderer_state_(
          BrowserThread::GetMessageLoopProxyForThread(BrowserThread::UI),
          this),
      browser_view_renderer_(
          this,
          &shared_renderer_state_,
          web_contents_.get(),
          BrowserThread::GetMessageLoopProxyForThread(BrowserThread::UI)),
      ...... {
  ......
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

AwContents类的构造函数首先将参数web_contents指向的WebContents对象保存在成员变量web_contents_中，接下来又会分别构造一个SharedRendererState对象和一个BrowserViewRenderer对象，并且保存在成员变量shared_renderer_state_和browser_view_renderer_中。

通过AwContents类的成员变量shared_renderer_state_描述的SharedRendererState对象，Chromium渲染引擎的Browser端和Render端可以请求App的Render Thread执行GPU命令。同时，这个SharedRendererState对象也会用来保存Chromium渲染引擎的Render端渲染的每一帧数据。这些帧数据将会交给Chromium渲染引擎的Browser端合成显示在屏幕上。

通过AwContents类的成员变量browser_view_renderer_描述的BrowserViewRenderer对象，则可以为Chromium渲染引擎的Render端创建一个Synchronous Compositor。这个Synchronous Compositor可以用来将网页的CC Layer Tree渲染在一个Synchronous Compositor Output Surface上。

接下来我们就继续分析上述SharedRendererState对象和BrowserViewRenderer对象的构造过程。

SharedRendererState对象的构造过程，也就是SharedRendererState类的构造函数的实现，如下所示：

SharedRendererState::SharedRendererState(
    scoped_refptr<base::MessageLoopProxy> ui_loop,
    BrowserViewRendererClient* client)
    : ui_loop_(ui_loop),
      client_on_ui_(client),
      ...... {
  ......
}

这个函数定义在文件external/chromium_org/android_webview$ vi browser/shared_renderer_state.cc中。

参数ui_loop描述的是一个Native UI Message Loop。这个Native UI Message Loop是通过前面调用BrowserThread类的静态成员函数GetMessageLoopProxyForThread获得的。这个Native UI Message Loop会保存在SharedRendererState类的成员变量ui_loop_。以后通过这个成员变量，就可以向App的Render Thread请求执行GPU操作了。

另外一个参数client指向的就是前面创建的AwContents对象。这个AwContents对象会保存在SharedRendererState类的成员变量client_on_ui_中。

BrowserViewRenderer对象的构造过程，也就是BrowserViewRenderer类的构造函数的实现，如下所示：

BrowserViewRenderer::BrowserViewRenderer(
    BrowserViewRendererClient* client,
    SharedRendererState* shared_renderer_state,
    content::WebContents* web_contents,
    const scoped_refptr<base::SingleThreadTaskRunner>& ui_task_runner)
    : client_(client),
      ...... {
  ......
  content::SynchronousCompositor::SetClientForWebContents(web_contents_, this);
  ......
}

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

从前面的调用过程可以知道，参数client指向的是前面创建的AwContents对象。这个AwContents对象会保存在BrowserViewRenderer类的成员变量client_中。

BrowserViewRenderer类的构造函数接下来会调用SynchronousCompositor类的静态成员函数SetClientForWebContents创建一个Synchronous Compositor，如下所示：

void SynchronousCompositor::SetClientForWebContents(
    WebContents* contents,
    SynchronousCompositorClient* client) {
  ......
  if (client) {
    ......
    SynchronousCompositorImpl::CreateForWebContents(contents);
  }
  if (SynchronousCompositorImpl* instance =
      SynchronousCompositorImpl::FromWebContents(contents)) {
    instance->SetClient(client);
  }
}

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

从前面的调用过程可以知道，参数client的值不等于NULL，它指向的是一个BrowserViewRenderer对象。在这种情况下，SynchronousCompositor类的静态成员函数SetClientForWebContents会调用SynchronousCompositorImpl类的静态成员函数CreateForWebContents为前面创建的WebContents对象创建一个Synchronous Compositor。

SynchronousCompositorImpl类的静态成员函数CreateForWebContents是从父类WebContentsUserData<SynchronousCompositorImpl>继承下来的，它的实现如下所示：

template <typename T>
class WebContentsUserData : public base::SupportsUserData::Data {
 public:
  // Creates an object of type T, and attaches it to the specified WebContents.
  // If an instance is already attached, does nothing.
  static void CreateForWebContents(WebContents* contents) {
    ......
    if (!FromWebContents(contents))
      contents->SetUserData(UserDataKey(), new T(contents));
  }

  ......
};

这个函数定义在文件external/chromium_org/content/public/browser/web_contents_user_data.h中。

WebContentsUserData<SynchronousCompositorImpl>类的静态成员函数CreateForWebContents首先调用另外一个FromWebContents检查之前是否已经为参数contents描述的WebContents对象创建过一个SynchronousCompositorImpl对象。如果没有创建过，那么就会创建一个，并且保存在该WebContents对象的内部，这是通过调用它的成员函数SetUserData实现的。这里创建出来的SynchronousCompositorImpl对象描述的就是一个ynchronous Compositor。

这一步执行完成后，回到前面分析的SynchronousCompositor类的静态成员函数SetClientForWebContents中，接下来它又会通过SynchronousCompositorImpl类的静态成员函数FromWebContents获得前面创建的SynchronousCompositorImpl对象，并且调用它的成员函数SetClient，用来将参数client指向的BrowserViewRenderer对象保存在内部，如下所示：

void SynchronousCompositorImpl::SetClient(
    SynchronousCompositorClient* compositor_client) {
  DCHECK(CalledOnValidThread());
  compositor_client_ = compositor_client;
}

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

SynchronousCompositorImpl类的成员函数SetClient将参数compositor_client指向的BrowserViewRenderer对象保存在成员变量compositor_client_中。

这一步执行完成后，回到前面分析的Java层的AwContents类的构造函数中，这时候就在Native层创建一个WebContents对象、一个AwContents对象、一个SharedRendererState对象、一个BrowserViewRenderer对象，以及一个SynchronousCompositorImpl对象。这些对象后面在启动Chromium渲染引擎的Render端，以及Chromium渲染引擎的Render端渲染网页UI时，都会使用到。

Java层的AwContents类的构造函数接下来会调用另外一个成员函数setNewAwContents在Native层创建一个ContentViewCore对象，如下所示：

public class AwContents {
    ......

    private void setNewAwContents(long newAwContentsPtr) {
        ......

        mNativeAwContents = newAwContentsPtr;
        ......

        long nativeWebContents = nativeGetWebContents(mNativeAwContents);
        mContentViewCore = createAndInitializeContentViewCore(
                mContainerView, mContext, mInternalAccessAdapter, nativeWebContents,
                new AwGestureStateListener(), mContentViewClient, mZoomControls);
        .......
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwContents.java中。

从前面的调用过程可以知道，参数newAwContentsPtr描述的是前面在Native层创建的AwContents对象。这个AwContents对象将会保存在AwContents类的成员变量mNativeAwContents中。

AwContents类的成员函数setNewAwContents接下来又会调用另外一个成员函数nativeGetWebContents获得用来创建上述Native层AwContents对象所使用的一个WebContents对象。有了这个WebContents对象之后，就使用它来在Native层创建一个ContentViewCore对象。这是通过调用AwContents类的成员函数createAndInitializeContentViewCore实现的，如下所示：

public class AwContents {
    ......

    private static ContentViewCore createAndInitializeContentViewCore(ViewGroup containerView,
            Context context, InternalAccessDelegate internalDispatcher, long nativeWebContents,
            GestureStateListener gestureStateListener,
            ContentViewClient contentViewClient,
            ContentViewCore.ZoomControlsDelegate zoomControlsDelegate) {
        ContentViewCore contentViewCore = new ContentViewCore(context);
        contentViewCore.initialize(containerView, internalDispatcher, nativeWebContents,
                context instanceof Activity ?
                        new ActivityWindowAndroid((Activity) context) :
                        new WindowAndroid(context.getApplicationContext()));
        ......
        return contentViewCore;
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwContents.java中。

AwContents类的成员函数createAndInitializeContentViewCore首先会创建一个Java层的ContentViewCore对象，然后再调用这个Java层的ContentViewCore对象的成员函数initialize对它进行初始化。在初始化的过程中，就会在Native层创建一个对应的ContentViewCore对象，如下所示：

public class ContentViewCore
        implements NavigationClient, AccessibilityStateChangeListener, ScreenOrientationObserver {
    ......

    public void initialize(ViewGroup containerView, InternalAccessDelegate internalDispatcher,
            long nativeWebContents, WindowAndroid windowAndroid) {
        ......

        mNativeContentViewCore = nativeInit(
                nativeWebContents, viewAndroidNativePointer, windowNativePointer,
                mRetainedJavaScriptObjects);
      
        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java中。

ContentViewCore类的成员函数initialize会调用另外一个成员函数nativeInit在Native层创建一个ContentViewCore对象，并且保存在成员变量mNativeContentViewCore中。在创建这个Native层的ContentViewCore对象的时候，需要使用到参数nativeWebContents描述的一个Native层的WebContents对象。

ContentViewCore类的成员函数nativeInit是一个JNI方法，它由C++层的函数Java_com_android_org_chromium_content_browser_ContentViewCore_nativeInit实现，如下所示：

__attribute__((visibility("default")))
jlong
    Java_com_android_org_chromium_content_browser_ContentViewCore_nativeInit(JNIEnv*
    env, jobject jcaller,
    jlong webContentsPtr,
    jlong viewAndroidPtr,
    jlong windowAndroidPtr,
    jobject retainedObjectSet) {
  return Init(env, jcaller, webContentsPtr, viewAndroidPtr, windowAndroidPtr,
      retainedObjectSet);
}

这个函数定义在文件out/target/product/generic/obj/GYP/shared_intermediates/content/jni/ContentViewCore_jni.h中。

函数Java_com_android_org_chromium_content_browser_ContentViewCore_nativeInit调用另外一个函数Init在Native层创建一个ContentViewCore对象，如下所示：

jlong Init(JNIEnv* env,
           jobject obj,
           jlong native_web_contents,
           jlong view_android,
           jlong window_android,
           jobject retained_objects_set) {
  ContentViewCoreImpl* view = new ContentViewCoreImpl(
      env, obj,
      reinterpret_cast<WebContents*>(native_web_contents),
      reinterpret_cast<ui::ViewAndroid*>(view_android),
      reinterpret_cast<ui::WindowAndroid*>(window_android),
      retained_objects_set);
  return reinterpret_cast<intptr_t>(view);
}

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

从这里可以看到，函数Init会使用参数native_web_contents描述的一个WebContents对象以及其它参数在Native层创建一个ContentViewCoreImpl对象。 ContentViewCoreImpl类是从ContentViewCore继承下来的。

ContentViewCoreImpl对象的创建过程，也就是ContentViewCoreImpl类的构造函数的实现，如下所示：

ContentViewCoreImpl::ContentViewCoreImpl(
    JNIEnv* env,
    jobject obj,
    WebContents* web_contents,
    ui::ViewAndroid* view_android,
    ui::WindowAndroid* window_android,
    jobject java_bridge_retained_object_set)
    : ......,
      web_contents_(static_cast<WebContentsImpl*>(web_contents)),
      ...... {
  ......
}

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

ContentViewCoreImpl类的构造函数会将参数web_contents指向的一个WebContents对象保存在成员变量web_contents_中。以后通过ContentViewCoreImpl类的成员函数LoadUrl加载指定的URL时，就需要使用到这个WebContents对象。

在Java层创建了一个AwContents对象和在Native层创建了一个WebContents对象和一个ContentViewCore对象之后，接下来我们就可以在Android WebView中加载指定的URL了。Android WebView又会请求Chromium渲染引擎启动一个Render端，并且在这个Render端中加载指定的URL。接下来，我们就从Android WebView中加载URL开始，分析Chromium渲染引擎启动Render端的过程。

Android WebView提供了一个成员函数loadUrl，用来加载指定的URL，如下所示：

public class WebView extends AbsoluteLayout
        implements ViewTreeObserver.OnGlobalFocusChangeListener,
        ViewGroup.OnHierarchyChangeListener, ViewDebug.HierarchyHandler {
    ......

    public void loadUrl(String url) {
        checkThread();
        if (DebugFlags.TRACE_API) Log.d(LOGTAG, "loadUrl=" + url);
        mProvider.loadUrl(url);
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebView.java中。

WebView类的成员函数loadUrl首先调用成员函数checkThread检查当前线程是否是创建WebView的线程。如果不是，那么就会抛出一个异常出来。

从前面Android WebView加载Chromium动态库的过程分析一文可以知道，WebView类的成员变量mProvider指向的是一个WebViewChromium对象。如果通过前面检查，那么接下来这个WebViewChromium对象的成员函数loadUrl会被调用，用来加载参数url指定的URL，如下所示：

class WebViewChromium implements WebViewProvider,
          WebViewProvider.ScrollDelegate, WebViewProvider.ViewDelegate {
    ......

    @Override
    public void loadUrl(String url) {
        // Early out to match old WebView implementation
        if (url == null) {
            return;
        }
        loadUrl(url, null);
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromium.java中。

WebViewChromium类的成员函数loadUrl调用另外一个重载版本的成员函数loadUrl加载参数url指定的URL，如下所示：

class WebViewChromium implements WebViewProvider,
          WebViewProvider.ScrollDelegate, WebViewProvider.ViewDelegate {
    ......

    @Override
    public void loadUrl(final String url, Map<String, String> additionalHttpHeaders) {
        ......

        LoadUrlParams params = new LoadUrlParams(url);
        if (additionalHttpHeaders != null) params.setExtraHeaders(additionalHttpHeaders);
        loadUrlOnUiThread(params);
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromium.java中。

WebViewChromium类重载版本的成员函数loadUrl将参数url和additinalHttpHeaders封装一个LoadUrlParams对象中，然后再传这个LoadUrlParams对象传递给另外一个成员函数loadUrlonUiThread，如下所示：

class WebViewChromium implements WebViewProvider,
          WebViewProvider.ScrollDelegate, WebViewProvider.ViewDelegate {
    ......

    private void loadUrlOnUiThread(final LoadUrlParams loadUrlParams) {
        ......
        if (checkNeedsPost()) {
            // Disallowed in WebView API for apps targetting a new SDK
            assert mAppTargetSdkVersion < Build.VERSION_CODES.JELLY_BEAN_MR2;
            mRunQueue.addTask(new Runnable() {
                @Override
                public void run() {
                    mAwContents.loadUrl(loadUrlParams);
                }
            });
            return;
        }
        mAwContents.loadUrl(loadUrlParams);
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromium.java中。

WebViewChromium类的成员函数LoadUrlParams会调用成员函数checkNeedsPost检查当前线程是否就是WebView的创建线程。如果不是，并且当前的Android版本小于4.3，那么就会向WebView的创建线程的消息队列发送一个Runnable。当该Runnable被执行的时候，才会调用WebViewChromium类的成员变量mAwContents指向的一个AwContents对象的成员函数loadUrl加载参数loadUrlParam描述的URL。

注意，如果当前线程不是WebView的创建线程，并且当前的Android版本大于等于4.3，那么WebViewChromium类的成员函数LoadUrlParams是不允许调用的。在我们这个情景中，前面已经保证了当前线程就是WebView的创建线程。在这种情况下，WebViewChromium类的成员函数LoadUrlParams就会直接调用成员变量mAwContents指向的一个AwContents对象的成员函数loadUrl加载参数loadUrlParam描述的URL，如下所示：

public class AwContents {
    ......

    public void loadUrl(LoadUrlParams params) {
        ......

        mContentViewCore.loadUrl(params);

        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwContents.java中。

从前面的分析可以知道，AwContents类的成员变量mContentViewCore指向的是一个ContentViewCore对象。AwContents类的成员函数loadUrl调用这个ContentViewCore对象的成员函数loadUrl加载参数params描述的URL。

ContentViewCore类的成员函数loadUrl加载指定URL的过程可以参考前面Chromium网页Frame Tree创建过程分析一文。在加载的过程中，会创建一个RenderViewHostImpl对象。从前面Chromium的Render进程启动过程分析一文又可以知道，在创建这个RenderViewHostImpl对象的过程中，又会创建一个RenderProcessHostImpl对象描述一个Render端。接下来这个RenderProcessHostImpl对象的成员函数Init又会被调用。在调用的过程中，它就会判断是要创建一个Render进程还是一个Render线程描述一个Render端，如下所示：

bool RenderProcessHostImpl::Init() {    
  ......  
  
  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);  
    ......  
  } else {  
    ......  
  
    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调用另外一个成员函数run_renderer_in_process判断要创建一个Render进程还是一个Render线程描述一个Render端。

RenderProcessHostImpl类的成员函数run_renderer_in_process是从父类RenderProcessHost继承下来的，它的实现如下所示：

bool g_run_renderer_in_process_ = false;

......

bool RenderProcessHost::run_renderer_in_process() {
  return g_run_renderer_in_process_;
}

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

RenderProcessHostImpl类的成员函数run_renderer_in_process返回的是全局变量g_run_renderer_in_process_的值。从前面的分析可以知道，这个全局变量g_run_renderer_in_process_已经被Android WebView设置为true。因此，RenderProcessHostImpl类的成员函数Init会创建一个Render线程来描述一个Render端。

这个Render线程是通过调用另外一个全局变量g_renderer_main_thread_factory描述的一个线程创建工厂函数创建的。从前面的分析可以知道，这个全局变量g_renderer_main_thread_factory描述的线程创建工厂函数为CreateInProcessRendererThread，它的实现如下所示：

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

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

从这里可以看到，函数为CreateInProcessRendererThread创建的是一个InProcessRendererThread对象。这个InProcessRendererThread对象描述的是一个类型为In-Process的Render线程。这个Render线程在RenderProcessHostImpl类的成员函数Init中将会被启动起来。这时候Android WebView就将Chromium渲染引擎的Render端启动起来了。

最后，我们分析Chromium渲染引擎的GPU端。由于Android WebView要求Chromium渲染引擎使用App的Render Thread来执行GPU命令，因此Chromium渲染引擎的GPU端是通过App的Render Thread描述的，它的启动过程可以参考前面Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章。

为了让Chromium渲染引擎可以使用App的Render Thread执行GPU命令，Chromium的android_webview模块会创建一个DeferredGpuCommandService服务。这个DeferredGpuCommandService服务将会负责请求App的Render Thread执行Chromium渲染引擎的Render端和Browser端发出来的GPU命令。接下来我们就分析这个DeferredGpuCommandService服务的创建过程。

DeferredGpuCommandService服务是在Android WebView的成员函数onDraw被App的UI线程调用时创建的，因此接下来我们就从Android WebView的成员函数onDraw开始分析DeferredGpuCommandService服务的创建过程，如下所示：

public class WebView extends AbsoluteLayout
        implements ViewTreeObserver.OnGlobalFocusChangeListener,
        ViewGroup.OnHierarchyChangeListener, ViewDebug.HierarchyHandler {
    ......

    @Override
    protected void onDraw(Canvas canvas) {
        mProvider.getViewDelegate().onDraw(canvas);
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/webkit/WebView.java中。

前面提到，WebView类的成员变量mProvider指向的是一个WebViewChromium对象。WebView的成员函数onDraw调用这个WebViewChromium对象的成员函数getViewDelegate获得一个View Delegate，如下所示：

class WebViewChromium implements WebViewProvider,
          WebViewProvider.ScrollDelegate, WebViewProvider.ViewDelegate {
    ......

    @Override
    // This needs to be kept thread safe!
    public WebViewProvider.ViewDelegate getViewDelegate() {
        return this;
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromium.java中。

从这里可以看到，WebViewChromium类的成员函数getViewDelegate返回的View Delegate就是当前正在处理的WebViewChromium对象。这个WebViewChromium对象返回给WebView类的成员函数onDraw之后，它的成员函数onDraw就会被调用，如下所示：

class WebViewChromium implements WebViewProvider,
          WebViewProvider.ScrollDelegate, WebViewProvider.ViewDelegate {
    ......

    @Override
    public void onDraw(final Canvas canvas) {
        ......
        if (checkNeedsPost()) {
            runVoidTaskOnUiThreadBlocking(new Runnable() {
                @Override
                public void run() {
                    onDraw(canvas);
                }
            });
            return;
        }
        mAwContents.onDraw(canvas);
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromium.java中。

WebViewChromium类的成员函数onDraw首先会调用成员函数checkNeedsPost检查当前线程是否就是WebView的创建线程。如果不是，那么就会向WebView的创建线程的消息队列发送一个Runnable。当该Runnable被执行的时候，才会重新进入WebViewChromium类的成员函数onDraw中，并且调用它的成员变量mAwContents指向的一个AwContents对象的成员函数onDraw，用来绘制网页的UI。

如果当前线程就是WebView的创建线程，那么WebViewChromium类的成员函数onDraw就会直接调用成员变量mAwContents指向的一个AwContents对象的成员函数onDraw绘制网页的UI。

AwContents类的成员函数onDraw的实现如下所示：

public class AwContents {
    ......

    public void onDraw(Canvas canvas) {
        mAwViewMethods.onDraw(canvas);
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwContents.java中。

AwContents类的成员变量mAwViewMethods指向的是一个AwViewMethodsImpl对象。AwContents类的成员函数onDraw调用这个AwViewMethodsImpl对象的成员函数onDraw绘制网页的UI，如下所示：

public class AwContents {
    ......

    private long mNativeAwContents;
    ......
 
    private class AwViewMethodsImpl implements AwViewMethods {
        ......

        @Override
        public void onDraw(Canvas canvas) {
            ......

            if (!nativeOnDraw(mNativeAwContents, canvas, canvas.isHardwareAccelerated(),
                    mContainerView.getScrollX(), mContainerView.getScrollY(),
                    globalVisibleRect.left, globalVisibleRect.top,
                    globalVisibleRect.right, globalVisibleRect.bottom)) {
                ......
            }

            ......
        }

        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwContents.java中。

AwViewMethodsImpl类的成员函数onDraw会调用外部类AwContents的成员函数nativeOnDraw绘制网页的UI，并且会将外部类的成员变量mNativeAwContents描述的一个Native层的AwContents对象传递给它。

AwContents类的成员函数nativeOnDraw是一个JNI方法，它由C++层的函数Java_com_android_org_chromium_android_1webview_AwContents_nativeOnDraw实现，如下所示：

__attribute__((visibility("default")))
jboolean
    Java_com_android_org_chromium_android_1webview_AwContents_nativeOnDraw(JNIEnv*
    env,
    jobject jcaller,
    jlong nativeAwContents,
    jobject canvas,
    jboolean isHardwareAccelerated,
    jint scrollX,
    jint scrollY,
    jint visibleLeft,
    jint visibleTop,
    jint visibleRight,
    jint visibleBottom) {
  AwContents* native = reinterpret_cast<AwContents*>(nativeAwContents);
  CHECK_NATIVE_PTR(env, jcaller, native, "OnDraw", false);
  return native->OnDraw(env, jcaller, canvas, isHardwareAccelerated, scrollX,
      scrollY, visibleLeft, visibleTop, visibleRight, visibleBottom);
}

这个函数定义在文件out/target/product/generic/obj/GYP/shared_intermediates/android_webview/jni/AwContents_jni.h中。

函数Java_com_android_org_chromium_android_1webview_AwContents_nativeOnDraw调用参数nativeAwContents描述的一个Native层AwContents对象的成员函数OnDraw绘制网页的UI，如下所示：

bool AwContents::OnDraw(JNIEnv* env,
                        jobject obj,
                        jobject canvas,
                        jboolean is_hardware_accelerated,
                        jint scroll_x,
                        jint scroll_y,
                        jint visible_left,
                        jint visible_top,
                        jint visible_right,
                        jint visible_bottom) {
  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
  if (is_hardware_accelerated)
    InitializeHardwareDrawIfNeeded();
  return browser_view_renderer_.OnDraw(
      canvas,
      is_hardware_accelerated,
      gfx::Vector2d(scroll_x, scroll_y),
      gfx::Rect(visible_left,
                visible_top,
                visible_right - visible_left,
                visible_bottom - visible_top));
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

参数is_hardware_accelerated表示App的UI是否采用硬件加速方式绘制。如果是的话，那么Chromium也会使用硬件加速方式绘制网页的UI。在这种情况下，AwContents类的成员函数OnDraw首先会调用另外一个成员函数InitializeHardwareDrawIfNeeded检查是否需要为Chromium初始化一个硬件加速渲染环境。这个硬件加速渲染环境初始化完成后，AwContents类的成员函数OnDraw才会调用成员变量browser_view_renderer_描述的一个BrowserViewRenderer对象的成员函数OnDraw绘制网页的UI。

AwContents类的成员函数InitializeHardwareDrawIfNeeded在为Chromium初始化硬件加速渲染环境的过程中，就会创建一个DeferredGpuCommandService服务，如下所示：

void AwContents::InitializeHardwareDrawIfNeeded() {
  GLViewRendererManager* manager = GLViewRendererManager::GetInstance();

  base::AutoLock lock(render_thread_lock_);
  if (renderer_manager_key_ == manager->NullKey()) {
    renderer_manager_key_ = manager->PushBack(&shared_renderer_state_);
    DeferredGpuCommandService::SetInstance();
  }
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

在Chromium渲染引擎中，存在一个GLViewRendererManager单例对象。这个GLViewRendererManager单例对象可以通过调用GLViewRendererManager类的静态成员函数GetInstance获得，它用来记录当前有哪些WebView是采用硬件加速方式绘制的。

AwContents类的成员函数InitializeHardwareDrawIfNeeded会检查成员变量renderer_manager_key_的值是否等于一个Null Key。如果等于的话，那么就说明当前正在绘制的WebView还没有初始化过硬件加速渲染环境。这时候AwContents类的成员函数InitializeHardwareDrawIfNeeded就会将成员变量shared_renderer_state_描述的一个SharedRendererState对象添加到上述GLViewRendererManager单例对象中。添加之后，会获得一个Key。这个Key就保存在AwContents类的成员变量renderer_manager_key_。同时，DeferredGpuCommandService类的静态成员函数SetInstance会被调用，用来创建一个DeferredGpuCommandService服务。这时候就表示当前正在绘制的WebView的硬件加速渲染环境初始化好了。

接下来我们继续分析DeferredGpuCommandService类的静态成员函数SetInstance会创建ferredGpuCommandService服务的过程，如下所示：

base::LazyInstance<scoped_refptr<DeferredGpuCommandService> >
    g_service = LAZY_INSTANCE_INITIALIZER;

......

void DeferredGpuCommandService::SetInstance() {
  if (!g_service.Get()) {
    g_service.Get() = new DeferredGpuCommandService;
    content::SynchronousCompositor::SetGpuService(g_service.Get());
  }
}

......

DeferredGpuCommandService* DeferredGpuCommandService::GetInstance() {
  DCHECK(g_service.Get().get());
  return g_service.Get().get();
}

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

DeferredGpuCommandService类的静态成员函数SetInstance检查全局变量g_service是否已经指向了一个DeferredGpuCommandService对象。如果还没有指向，那么就会创建一个DeferredGpuCommandService对象让它指向。创建出来的DeferredGpuCommandService对象描述的就是一个DeferredGpuCommandService服务。这个DeferredGpuCommandService服务可以通过调用DeferredGpuCommandService类的静态成员函数GetInstance获得。

DeferredGpuCommandService类的静态成员函数SetInstance创建出来的DeferredGpuCommandService服务会被设置为Android WebView绘制网页所使用的Synchronous Compositor的GPU服务，这是通过调用SynchronousCompositor类的静态成员函数SetGpuService实现的，如下所示：

base::LazyInstance<synchronouscompositorfactoryimpl>::Leaky g_factory =
    LAZY_INSTANCE_INITIALIZER;

......

void SynchronousCompositor::SetGpuService(
    scoped_refptr<gpu::InProcessCommandBuffer::Service> service) {
  g_factory.Get().SetDeferredGpuService(service);
}

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

全局变量g_factory描述的是一个SynchronousCompositorFactoryImpl对象，SynchronousCompositor类的静态成员函数SetGpuService会将参数service描述的一个DeferredGpuCommandService服务保存在它内部。这个通过调用它的成员函数SetDeferredGpuService实现的，如下所示

void SynchronousCompositorFactoryImpl::SetDeferredGpuService(
    scoped_refptr<gpu::InProcessCommandBuffer::Service> service) {
  DCHECK(!service_);
  service_ = service;
}

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

SynchronousCompositorFactoryImpl类的成员函数SetDeferredGpuService将参数service描述的一个DeferredGpuCommandService服务保存在成员变量service_。

这一步执行完成后，Chromium渲染引擎的Render端以后就会通过保存在SynchronousCompositorFactoryImpl类的成员变量service_中的DeferredGpuCommandService服务来执行GPU命令。这一点我们在接下来一篇文章中再详细分析。

至此，我们就分析完成了Android WebView启动Chromium渲染引擎的过程，主要就是启动的Chromium渲染引擎的Browser端和Render端。其中，Browser端对应的就是App的UI线程，而Render端对应的是一个类型为In-Process的Render线程。

由于Android WebView要求Chromium渲染引擎使用App的Render Thread执行GPU命令，因此Chromium渲染引擎就不会创建自己的GPU端。不过，它会创建一个DeferredGpuCommandService服务，用来将Chromium渲染引擎发出的GPU命令交给App的Render Thread执行。在接下来一篇文章中，我们就详细分析Chromium渲染引擎执行GPU命令的过程。敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/12/5 1:02:47 原文链接

阅读：40532 评论：6 查看评论

↧

Android WebView执行GPU命令的过程分析

December 12, 2016, 1:05 am

≫ Next: Android WebView硬件加速渲染网页UI的过程分析

≪ Previous: Android WebView启动Chromium渲染引擎的过程分析

Android WebView使用的Chromium引擎，虽然没有自己的GPU进程或者线程，但是却可以执行GPU命令。原来，Android WebView会给它提供一个In-Process Command Buffer GL接口。通过这个接口，Chromium引擎就可以将GPU命令提交给App的Render Thread执行。本文接下来就详细分析Android WebView执行GPU命令的过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

从前面Chromium硬件加速渲染的OpenGL命令执行过程分析这篇文章可以知道，Chromium渲染引擎在有自己的GPU进程或者线程的情况下，是通过一个Command Buffer GL接口执行GPU命令的。这个Command Buffer GL接口通过一个GLES2Implementation类描述。Android WebView给Chromium引擎提供的In-Process Command Buffer GL接口，同样是通过GLES2Implementation类描述的。这样，Chromium渲染引擎就不用关心它发出的GPU命令是如何执行的。

在Chromium渲染引擎中，需要执行GPU命令的是Render端和Browser端。Render端执行GPU命令是为渲染网页的UI，而Browser端执行GPU命令是为了将Render端渲染的网页UI合成显示在屏幕上。对Android WebView来说，它的Render端会将网页抽象成一个CC Layer Tree，然后使用一个Synchronous Compositor将它渲染在一个Synchronous Compositor Output Surface上，如图1所示：

图1 Android WebView的Render端渲染网页UI的示意图

Android WebView的Browser端同样会将自己要合成的UI抽象为一个CC Layer Tree，然后使用一个Hardware Renderer将它渲染在一个Parent Output Surface上，如图2所示：

图2 Android WebView的Browser端合成网页UI的示意图

Browser端的CC Layer Tree比较特别，它只有两个节点。一个是根节点，另一个是根节点的子节点，称为Delegated Render Layer，它要渲染的内容来自于Render端的渲染输出。从前面Chromium硬件加速渲染的UI合成过程分析一文可以知道，Render端的渲染输出是一系列的Render Pass。每一个Render Pass都包含了若干个纹理。这些纹理是在Render端光栅化网页时产生的。Browser端的Hardware Renderer所要做的事情就是将这些纹理渲染在屏幕上。这个过程也就是Browser端合成网页UI的过程。

不管是Render端，还是Browser端，当它们执行GPU命令的时候，都是通过GLES2Implementation类描述的一个In-Process Command Buffer GL接口写入到一个Command Buffer中去的。只不过在Android WebView的情况下，这些GPU命令会被一个DeferredGpuCommandService服务提交给App的Render Thread执行，如图3所示：

图3 Android WebView执行GPU命令的过程

Render端和Browser端将要执行的GPU命令写入到Command Buffer之后，就会请求DeferredGpuCommandService服务在App的Render Thread中调度执行一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。InProcessCommandBuffer类的成员函数FlushOnGpuThread又是通过一个Gpu Scheduler按照上下文来执行请求的GPU命令，并且这些GPU命令在执行之前，先要经过一个GLES2 Decoder进行解码。这个过程可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

对于Browser端来说，它本来就是在App的Render Thread中请求执行GPU命令的。这时候DeferredGpuCommandService服务会直接在当前线程中调用InProcessCommandBuffer类的成员函数FlushOnGpuThread，以便执行请求的GPU命令。

对于Render端来说，它在两种情景下需要请求执行GPU命令。第一种情景是光栅化网页的UI，第二种情景是绘制网页的UI。这两种情景都是发生在Render端的Compositor线程中。关于Render端的Compositor线程，以及网页UI的光栅化和绘制操作，可以参考前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章。

上述两种情景都会将要执行的GPU操作抽象为一个DrawGLFunctor对象。对于第一个情景，DrawGLFunctor对象会通过App的UI线程直接提交给App的Render Thread。App的Render Thread再通知该DrawGLFunctor对象执行GPU操作。

对于第二个情景，DrawGLFunctor对象会被App的UI线程封装为一个DrawFunctorOp操作，并且写入到App UI的Display List中。接下来App的UI线程会将Display List同步给App的Render Thread。随后这个Display List就会被App的Render Thread通过一个OpenGL Renderer进行Replay，这时候Display List中包含的DrawFunctorOp操作就会被执行。在执行的过程中，与它关联的DrawGLFunctor对象获得通知。DrawGLFunctor对象获得通知以后就会执行之前Render端请求的GPU操作了。

DrawGLFunctor对象在执行GPU操作的时候，会调用到一个DrawGL函数。这个DrawGL函数是Android WebView在启动Chromium渲染引擎时注册的。它在执行的过程中，就会通过Browser端的Hardware Renderer通知DeferredGpuCommandService服务执行此前请求调度的Task。这时候InProcessCommandBuffer类的成员函数FlushOnGpuThread就会被调用，这时候Render端之前请求的GPU命令就会被执行。

接下来，我们就结合源码，分析Chromium渲染引擎的Render端和Browser端创建In-Process Command Buffer GL接口的过程，以及以Render端使用GPU光栅化网页的过程为例，分析Chromium渲染引擎通过In-Process Command Buffer GL接口执行GPU命令的过程。不过，在分析这些过程之前，我们首先分析Android WebView向Chromium渲染引擎注册DrawGL函数的过程。这个过程发生在Android WebView启动Chromium渲染引擎的Browser端的过程中。

从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，Android WebView在启动Chromium渲染引擎的Browser端的过程中，会调用到WebViewChromiumFactoryProvider类的成员函数startChromiumLocked，如下所示：

public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
    ......

    private void startChromiumLocked() {
        ......

        initPlatSupportLibrary();
        AwBrowserProcess.start(ActivityThread.currentApplication());
    
        ......
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromiumFactoryProvider.java中。

在调用AwBrowserProcess类的静态成员函数start动Chromium渲染引擎的Browser端之前，WebViewChromiumFactoryProvider类的成员函数startChromiumLocked先会调用成员函数initPlatSupportLibrary向Chromium渲染引擎注册一个DrawGL函数，如下所示：

public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
    ......

    private void initPlatSupportLibrary() {
        DrawGLFunctor.setChromiumAwDrawGLFunction(AwContents.getAwDrawGLFunction());
        ......
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromiumFactoryProvider.java中。

WebViewChromiumFactoryProvider类的成员函数startChromiumLocked首先会调用AwContents类的静态成员函数getAwDrawGLFunction获得要注册的DrawGL函数，然后再调用DrawGLFunctor类的静态成员函数setChromiumAwDrawGLFunction将它注册到Chromium渲染引擎中。

接下来，我们首先分析AwContents类的静态成员函数getAwDrawGLFunction获取要注册的DrawGL函数的过程，然后再分析DrawGLFunctor类的静态成员函数setChromiumAwDrawGLFunction注册DrawGL函数到Chromium渲染引擎的过程。

AwContents类的静态成员函数getAwDrawGLFunction的实现如下所示：

public class AwContents {
    ......

    public static long getAwDrawGLFunction() {
        return nativeGetAwDrawGLFunction();
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwContents.java中。

AwContents类的静态成员函数getAwDrawGLFunction调用另外一个静态成员函数AwContents类的静态成员函数获取要注册的的DrawGL函数的过程。

AwContents类的静态成员函数AwContents类的静态成员函数是一个JNI方法，它由C++层的函数Java_com_android_org_chromium_android_1webview_AwContents_nativeGetAwDrawGLFunction实现，如下所示：

__attribute__((visibility("default")))
jlong
    Java_com_android_org_chromium_android_1webview_AwContents_nativeGetAwDrawGLFunction(JNIEnv*
    env, jclass jcaller) {
  return GetAwDrawGLFunction(env, jcaller);
}

这个函数定义在文件out/target/product/generic/obj/GYP/shared_intermediates/android_webview/jni/AwContents_jni.h中。

函数Java_com_android_org_chromium_android_1webview_AwContents_nativeGetAwDrawGLFunction又通过调用另外一个函数GetAwDrawGLFunction获取要注册的DrawGL函数，如下所示：

static jlong GetAwDrawGLFunction(JNIEnv* env, jclass) {
  return reinterpret_cast<intptr_t>(&DrawGLFunction);
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

函数GetAwDrawGLFunction返回的是定义在同文件中的函数DrawGLFunction。这个函数的地址将会返回到前面分析的WebViewChromiumFactoryProvider类的成员函数initPlatSupportLibrary向Chromium，后者再调用DrawGLFunctor类的静态成员函数setChromiumAwDrawGLFunction将它注册到Chromium渲染引擎中，如下所示：

class DrawGLFunctor {
    ......

    public static void setChromiumAwDrawGLFunction(long functionPointer) {
        nativeSetChromiumAwDrawGLFunction(functionPointer);
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/DrawGLFunctor.java中。

DrawGLFunctor类的静态成员函数setChromiumAwDrawGLFunction调用另外一个静态成员函数nativeSetChromiumAwDrawGLFunction将前面获得的函数DrawGLFunction注册在Chromium渲染引擎中。

DrawGLFunctor类的静态成员函数nativeSetChromiumAwDrawGLFunction是一个JNI方法，它由C++层的函数SetChromiumAwDrawGLFunction实现，如下所示：

AwDrawGLFunction* g_aw_drawgl_function = NULL;

......

void SetChromiumAwDrawGLFunction(JNIEnv*, jclass, jlong draw_function) {
  g_aw_drawgl_function = reinterpret_cast<AwDrawGLFunction*>(draw_function);
}

这个函数定义在文件frameworks/webview/chromium/plat_support/draw_gl_functor.cpp中。

函数SetChromiumAwDrawGLFunction将参数draw_function描述的函数DrawGLFunction的地址保存在全局变量g_aw_drawgl_function中。这样，Android WebView就在启动Chromium渲染引擎的Browser端的过程中，向Chromium渲染引擎注册了一个DrawGL函数。

接下来，我们分析Chromium渲染引擎为Render端创建In-Process Command Buffer GL接口的过程。Chromium渲染引擎为Render端创建的In-Process Command Buffer GL接口是封装在绘图表面（Output Surface）里面的。在Chromium中，每一个网页都关联一个Output Surface。在分析Render端的In-Process Command Buffer GL接口的创建之前，我们首先分析网页的Output Surface的创建过程。

从前面Chromium网页绘图表面（Output Surface）创建过程分析和Chromium的GPU进程启动过程分析这两篇文章可以知道，Render端在加载了网页之后，会为网页创建一个绘图表面，即一个Output Surface，最终是通过调用RenderWidget类的成员函数CreateOutputSurface进行创建的，如下所示：

scoped_ptr<cc::OutputSurface> RenderWidget::CreateOutputSurface(bool fallback) {
  ......

#if defined(OS_ANDROID)
  if (SynchronousCompositorFactory* factory =
      SynchronousCompositorFactory::GetInstance()) {
    return factory->CreateOutputSurface(routing_id());
  }
#endif

  ......
}

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

在Android平台上，RenderWidget类的成员函数CreateOutputSurface首先会调用SynchronousCompositorFactory类的静态成员函数GetInstance检查当前进程是否存在一个用来创建Output Surface的工厂对象。如果存在，那么就会调用它的成员函数CreateOutputSurface为当前加载的网页创建一个Output Surface。

SynchronousCompositorFactory类的静态成员函数GetInstance的实现如下所示：

SynchronousCompositorFactory* g_instance = NULL;

......

void SynchronousCompositorFactory::SetInstance(
    SynchronousCompositorFactory* instance) {
  ......

  g_instance = instance;
}

SynchronousCompositorFactory* SynchronousCompositorFactory::GetInstance() {
  return g_instance;
}

这两个函数定义在文件external/chromium_org/content/renderer/android/synchronous_compositor_factory.cc。

SynchronousCompositorFactory类的静态成员函数GetInstance返回的是全局变量g_instance指向的一个SynchronousCompositorFactoryImpl对象。这个SynchronousCompositorFactoryImpl对象是通过SynchronousCompositorFactory类的静态成员数SetInstance设置给全局变量g_instance的。

这个SynchronousCompositorFactoryImpl对象是什么时候设置给全局变量g_instance的呢？回忆前面Android WebView启动Chromium渲染引擎的过程分析一文，Android WebView在启动Chromium渲染引擎的过程，会创建一个DeferredGpuCommandService服务，并且将这个DeferredGpuCommandService服务保存在一个SynchronousCompositorFactoryImpl对象的成员变量service_中。这个SynchronousCompositorFactoryImpl对象在创建的过程中，就会通过调用SynchronousCompositorFactory类的静态成员数SetInstance将自己保存在上述全局变量g_instance中，如下所示：

SynchronousCompositorFactoryImpl::SynchronousCompositorFactoryImpl()
    : record_full_layer_(true),
      num_hardware_compositors_(0) {
  SynchronousCompositorFactory::SetInstance(this);
}

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

回到前面分析的RenderWidget类的成员函数CreateOutputSurface中，这时候它调用SynchronousCompositorFactory类的静态成员函数GetInstance就会获得一个SynchronousCompositorFactoryImpl对象。有了这个SynchronousCompositorFactoryImpl对象之后，RenderWidget类的成员函数CreateOutputSurface就会调用它的成员函数CreateOutputSurface为当前正在加载的网页创建一个Output Surface，如下所示：

scoped_ptr<cc::OutputSurface>
SynchronousCompositorFactoryImpl::CreateOutputSurface(int routing_id) {
  scoped_ptr<SynchronousCompositorOutputSurface> output_surface(
      new SynchronousCompositorOutputSurface(routing_id));
  return output_surface.PassAs<cc::OutputSurface>();
}

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

SynchronousCompositorFactoryImpl类的成员函数CreateOutputSurface创建一个类型为Synchronous Compositor的Output Surface返回给调用者。从前面Chromium网页绘图表面（Output Surface）创建过程分析一文可以知道，这个Synchronous Compositor Output Surface将会返回给ThreadProxy类的成员函数CreateAndInitializeOutputSurface，如下所示：

void ThreadProxy::CreateAndInitializeOutputSurface() {  
  ......    
  
  scoped_ptr<OutputSurface> output_surface =  
      layer_tree_host()->CreateOutputSurface();  
  
  if (output_surface) {  
    Proxy::ImplThreadTaskRunner()->PostTask(  
        FROM_HERE,  
        base::Bind(&ThreadProxy::InitializeOutputSurfaceOnImplThread,  
                   impl_thread_weak_ptr_,  
                   base::Passed(&output_surface)));  
    return;  
  }  
  
  ......  
}

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

ThreadProxy类的成员函数CreateAndInitializeOutputSurface又会将这个Synchronous Compositor Output Surface传递给Render端的Compositor线程，让后者对它进行初始化。这个初始化操作是通过在Render端的Compositor线程中调用ThreadProxy类的成员函数InitializeOutputSurfaceOnImplThread实现的。

从前面Chromium网页绘图表面（Output Surface）创建过程分析一文可以知道，ThreadProxy类的成员函数InitializeOutputSurfaceOnImplThread在初始化Synchronous Compositor Output Surface的过程中，会调用它的成员函数BindToClient，表示它已经被设置给一个网页使用。

SynchronousCompositorOutputSurface类的成员函数BindToClient的实现如下所示：

bool SynchronousCompositorOutputSurface::BindToClient(
    cc::OutputSurfaceClient* surface_client) {
  ......

  SynchronousCompositorOutputSurfaceDelegate* delegate = GetDelegate();
  if (delegate)
    delegate->DidBindOutputSurface(this);

  return true;
}

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

SynchronousCompositorOutputSurface类的成员函数BindToClient会调用另外一个成员函数GetDelegate获得一个Delegate对象，如下所示：

SynchronousCompositorOutputSurfaceDelegate*
SynchronousCompositorOutputSurface::GetDelegate() {
  return SynchronousCompositorImpl::FromRoutingID(routing_id_);
}

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

SynchronousCompositorOutputSurface类的成员函数GetDelegate通过调用SynchronousCompositorImpl类的静态成员函数FromRoutingID获得一个Delegate对象，如下所示：

SynchronousCompositorImpl* SynchronousCompositorImpl::FromRoutingID(
    int routing_id) {
  return FromID(GetInProcessRendererId(), routing_id);
}

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

SynchronousCompositorImpl类的静态成员函数FromRoutingID首先会调用静态成员函数GetInProcessRendererId获得当前正在处理的Render端的ID。有了这个ID之后，连同参数routing_id描述的网页ID，传递给SynchronousCompositorImpl类的另外一个静态成员函数FromID，如下所示：

SynchronousCompositorImpl* SynchronousCompositorImpl::FromID(int process_id,
                                                             int routing_id) {
  ......
  RenderViewHost* rvh = RenderViewHost::FromID(process_id, routing_id);
  ......
  WebContents* contents = WebContents::FromRenderViewHost(rvh);
  ......
  return FromWebContents(contents);
}

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

SynchronousCompositorImpl类的静态成员函数FromID首先通过调用RenderViewHost类的静态成员函数FromID获得与参数process_id和routing_id对应的一个RenderViewHost对象。这个RenderViewHost对象用来在Browser端描述的一个网页。这个网页就是当前正在Android WebView中加载的网页。

获得了与当前正在加载的网页对应的RenderViewHost对象之后，就可以调用WebContents类的静态成员函数FromRenderViewHost获得一个WebContents对象。在Chromium中，每一个网页在Content层又都是通过一个WebContents对象描述的。这个WebContents对象的创建过程可以参考前面Android WebView启动Chromium渲染引擎的过程分析一文。

获得了用来描述当前正在加载的网页的WebContents对象之后，SynchronousCompositorImpl类的静态成员函数FromID就可以调用另外一个静态成员函数FromWebContents获得一个SynchronousCompositorImpl对象。这个SynchronousCompositorImpl对象的创建过程可以参考前面Android WebView启动Chromium渲染引擎的过程分析一文，它是负责用来渲染在Android WebView中加载的网页的UI的。

SynchronousCompositorImpl类的静态成员函数FromID最后会将获得的SynchronousCompositorImpl对象返回给调用者，也就是前面分析的SynchronousCompositorOutputSurface类的成员函数BindToClient。SynchronousCompositorOutputSurface类的成员函数BindToClient接下来会调用这个SynchronousCompositorImpl对象的成员函数DidBindOutputSurface，表示它现在已经与一个Synchronous Compositor Output Surface建立了绑定关系，这样以后它就可以将网页的UI渲染在这个Synchronous Compositor Output Surface之上。

SynchronousCompositorImpl类的成员函数DidBindOutputSurface的实现如下所示：

void SynchronousCompositorImpl::DidBindOutputSurface(
      SynchronousCompositorOutputSurface* output_surface) {
  ......
  output_surface_ = output_surface;
  if (compositor_client_)
    compositor_client_->DidInitializeCompositor(this);
}

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

SynchronousCompositorImpl类的成员函数DidBindOutputSurface首先将参数output_surface描述的Synchronous Compositor Output Surface保存在成员变量output_surface_中。

从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，SynchronousCompositorImpl类的成员变量compositor_client_指向的是一个BrowserViewRenderer对象。SynchronousCompositorImpl类的成员函数DidBindOutputSurface最后会调用这个BrowserViewRenderer对象的成员函数DidInitializeCompositor，表示Chromium渲染引擎已经为它创建了一个用来渲染网页UI的Synchronous Compositor，如下所示：

void BrowserViewRenderer::DidInitializeCompositor(
    content::SynchronousCompositor* compositor) {
  ......

  compositor_ = compositor;
}

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

BrowserViewRenderer类的成员函数DidInitializeCompositor会将参数compositor指向的一个SynchronousCompositorImpl对象保存在成员变量compositor_中。

这一步执行完成之后，Chromium渲染引擎就为在Render端加载的网页创建了一个Synchronous Compositor Output Surface，并且会将这个Synchronous Compositor Output Surface设置给一个Synchronous Compositor。这个Synchronous Compositor又会设置给一个BrowserViewRenderer对象。这个BrowserViewRenderer对象负责绘制Android WebView的UI。

接下来我们就开始分析Chromium渲染引擎为Render端创建In-Process Command Buffer GL接口的过程。这个In-Process Command Buffer GL接口是在Android WebView第一次执行硬件加速渲染之前创建的。从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，Android WebView每次被绘制时，它在Chromium的android_webview模块中对应的AwContents对象的成员函数OnDraw都会被调用，如下所示：

bool AwContents::OnDraw(JNIEnv* env,
                        jobject obj,
                        jobject canvas,
                        jboolean is_hardware_accelerated,
                        jint scroll_x,
                        jint scroll_y,
                        jint visible_left,
                        jint visible_top,
                        jint visible_right,
                        jint visible_bottom) {
  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
  if (is_hardware_accelerated)
    InitializeHardwareDrawIfNeeded();
  return browser_view_renderer_.OnDraw(
      canvas,
      is_hardware_accelerated,
      gfx::Vector2d(scroll_x, scroll_y),
      gfx::Rect(visible_left,
                visible_top,
                visible_right - visible_left,
                visible_bottom - visible_top));
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc。

如果执行的是硬件加速渲染，那么AwContents类的成员函数OnDraw首先会调用另外一个成员函数InitializeHardwareDrawIfNeeded检查当前是否已经创建了一个DeferredGpuCommandService服务。如果还没有创建，那么就会进行创建。这个DeferredGpuCommandService服务的创建过程可以参考前面Android WebView启动Chromium渲染引擎的过程分析一文。

AwContents类的成员函数OnDraw接下来会调用成员变量browser_view_renderer_描述的一个BrowserViewRenderer对象的成员函数OnDraw执行硬件加速渲染，如下所示：

bool BrowserViewRenderer::OnDraw(jobject java_canvas,
                                 bool is_hardware_canvas,
                                 const gfx::Vector2d& scroll,
                                 const gfx::Rect& global_visible_rect) {
  ......

  if (is_hardware_canvas && attached_to_window_)
    return OnDrawHardware(java_canvas);
  // Perform a software draw
  return OnDrawSoftware(java_canvas);
}

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

在执行硬件加速渲染的情况下，BrowserViewRenderer对象的成员函数OnDraw会调用成员函数OnDrawHardware对Android WebView进行绘制，如下所示：

bool BrowserViewRenderer::OnDrawHardware(jobject java_canvas) {
  ......

  if (!hardware_enabled_) {
    hardware_enabled_ = compositor_->InitializeHwDraw();
    ......
  }

  ......

  scoped_ptr<DrawGLInput> draw_gl_input(new DrawGLInput);
  ......

  scoped_ptr<cc::CompositorFrame> frame =
      compositor_->DemandDrawHw(surface_size,
                                gfx::Transform(),
                                viewport,
                                clip,
                                viewport_rect_for_tile_priority,
                                transform_for_tile_priority);
  ......

  shared_renderer_state_->SetDrawGLInput(draw_gl_input.Pass());
  ......
  return client_->RequestDrawGL(java_canvas, false);
}

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

当BrowserViewRenderer类的成员变量hardware_enabled_的值等于false时，表示Android WebView是第一次启用硬件加速渲染。在这种情况下，BrowserViewRenderer类的函数OnDraw首先会初始化一个硬件加速渲染环境，然后再对Android WebView进行绘制。

从前面的分析可以知道，BrowserViewRenderer类的成员变量compositor_指向的是一个SynchronousCompositorImpl对象。BrowserViewRenderer类的函数OnDraw就是通过调用这个SynchronousCompositorImpl对象的成员函数InitializeHwDraw初始化一个硬件加速渲染环境的。在初始化这个硬件加速渲染环境的过程中，就会创建一个In-Process Command Buffer GL接口。

接下来，我们就继续分析SynchronousCompositorImpl类的成员函数InitializeHwDraw初始化创建In-Process Command Buffer GL接口的过程。在接下来一篇文章中，我们再分析BrowserViewRenderer类的函数OnDraw绘制Android WebView的过程。

SynchronousCompositorImpl类的成员函数InitializeHwDraw的实现如下所示：

base::LazyInstance<SynchronousCompositorFactoryImpl>::Leaky g_factory =
    LAZY_INSTANCE_INITIALIZER;

......

bool SynchronousCompositorImpl::InitializeHwDraw() {
  ......

  scoped_refptr<cc::ContextProvider> onscreen_context =
      g_factory.Get().CreateOnscreenContextProviderForCompositorThread();

  bool success = output_surface_->InitializeHwDraw(onscreen_context);

  ......
  return success;
}

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

全局变量指向的就是前面提到的用来为网页创建Output Surface的SynchronousCompositorFactoryImpl对象。SynchronousCompositorImpl类的成员函数InitializeHwDraw调用这个SynchronousCompositorFactoryImpl对象的成员函数CreateOnscreenContextProviderForCompositorThread创建一个硬件加速渲染环境。

创建出来的硬件加速渲染环境是通过一个ContextProviderInProcess对象描述的。这个ContextProviderInProcess对象又会设置给SynchronousCompositorImpl类的成员变量output_surface_描述的一个Synchronous Compositor Output Surface。Synchronous Compositor Output Surface有了硬件加速渲染环境之后，就可以执行GPU命令了。

接下来，我们首先分析SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread创建硬件加速渲染环境的过程，如下所示：

scoped_refptr<cc::ContextProvider> SynchronousCompositorFactoryImpl::
    CreateOnscreenContextProviderForCompositorThread() {
  ......
  return webkit::gpu::ContextProviderInProcess::Create(
      WrapContext(CreateContext(service_, share_context_.get())),
      "Child-Compositor");
}

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

SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread首先调有函数CreateContext创建一个In-Process Command Buffer GL接口，然后再调用另外一个函数WrapContext将这个In-Process Command Buffer GL接口封装在一个WebGraphicsContext3DInProcessCommandBufferImpl对象，最后调用ContextProviderInProcess类的静态成员函数Create将该WebGraphicsContext3DInProcessCommandBufferImpl对象封装在一个ContextProviderInProcess对象中。

从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，SynchronousCompositorFactoryImpl类的成员变量service_指向的就是一个DeferredGpuCommandService服务。函数CreateContext在创建In-Process Command Buffer GL接口的时候，会使用到这个DeferredGpuCommandService服务，如下所示：

scoped_ptr<gpu::GLInProcessContext> CreateContext(
    scoped_refptr<gpu::InProcessCommandBuffer::Service> service,
    gpu::GLInProcessContext* share_context) {
  ......

  scoped_ptr<gpu::GLInProcessContext> context(
      gpu::GLInProcessContext::Create(service,
                                      NULL /* surface */,
                                      false /* is_offscreen */,
                                      gfx::kNullAcceleratedWidget,
                                      gfx::Size(1, 1),
                                      share_context,
                                      false /* share_resources */,
                                      in_process_attribs,
                                      gpu_preference));
  return context.Pass();
}

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

函数调用GLInProcessContext类的静态成员函数Create创建了一个In-Process Command Buffer GL接口，如下所示：

GLInProcessContext* GLInProcessContext::Create(
    scoped_refptr<gpu::InProcessCommandBuffer::Service> service,
    scoped_refptr<gfx::GLSurface> surface,
    bool is_offscreen,
    gfx::AcceleratedWidget window,
    const gfx::Size& size,
    GLInProcessContext* share_context,
    bool use_global_share_group,
    const GLInProcessContextAttribs& attribs,
    gfx::GpuPreference gpu_preference) {
  ......

  scoped_ptr<GLInProcessContextImpl> context(new GLInProcessContextImpl());
  if (!context->Initialize(surface,
                           is_offscreen,
                           use_global_share_group,
                           share_context,
                           window,
                           size,
                           attribs,
                           gpu_preference,
                           service))
    return NULL;

  return context.release();
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/client/gl_in_process_context.cc中。

GLInProcessContext类的静态成员函数Create首先创建了一个GLInProcessContextImpl对象，然后调用这个GLInProcessContextImpl对象的成员函数Initialize对其进行初始化。在初始化的过程中，就会创建一个In-Process Command Buffer GL接口，如下所示：

bool GLInProcessContextImpl::Initialize(
    scoped_refptr<gfx::GLSurface> surface,
    bool is_offscreen,
    bool use_global_share_group,
    GLInProcessContext* share_context,
    gfx::AcceleratedWidget window,
    const gfx::Size& size,
    const GLInProcessContextAttribs& attribs,
    gfx::GpuPreference gpu_preference,
    const scoped_refptr<InProcessCommandBuffer::Service>& service) {
  ......

  command_buffer_.reset(new InProcessCommandBuffer(service));
  ......

  if (!command_buffer_->Initialize(surface,
                                   is_offscreen,
                                   window,
                                   size,
                                   attrib_vector,
                                   gpu_preference,
                                   wrapped_callback,
                                   share_command_buffer)) {
    ......
    return false;
  }

  // Create the GLES2 helper, which writes the command buffer protocol.
  gles2_helper_.reset(new gles2::GLES2CmdHelper(command_buffer_.get()));
  ......

  // Create the object exposing the OpenGL API.
  gles2_implementation_.reset(new gles2::GLES2Implementation(
      gles2_helper_.get(),
      share_group,
      transfer_buffer_.get(),
      bind_generates_resources,
      attribs.lose_context_when_out_of_memory > 0,
      command_buffer_.get()));
  ......

  return true;
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/client/gl_in_process_context.cc中。

GLInProcessContextImpl类的成员函数Initialize创建In-Process Command Buffer GL接口的过程与前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文提到的Command Buffer GL接口的创建过程是类似的。首先是创建一个Command Buffer，然后再将该Command Buffer封装在一个GLES2CmdHelper对象中。以后通过个GLES2CmdHelper对象就可以将要执行的GPU命令写入到它封装的Command Buffer中去。最后又会使用前面封装得到的GLES2CmdHelper对象创建一个GLES2Implementation对象。这个GLES2Implementation对象就用来描述的一个In-Process Command Buffer GL或者Command Buffer GL接口。

In-Process Command Buffer GL接口与Command Buffer GL接口的最大区别就在于它们使用了不同的Command Buffer。In-Process Command Buffer GL使用的Command Buffer是一个In-Process Command Buffer，而Command Buffer GL接口使用的Command Buffer是一个Command Buffer Proxy。In-Process Command Buffer会将要执行的GPU命令发送给App的Render Thread处理，而Command Buffer Proxy会将要执行的GPU命令发送给Chromium的GPU进程/线程处理。

接下来，我们就重点分析In-Process Command Buffer的创建过程，以便后面可以更好地理解它是怎么将要执行的GPU命令发送给App的Render Thread处理的。

从前面的调用过程可以知道，参数service描述的是一个DeferredGpuCommandService服务。这个DeferredGpuCommandService服务将会用来创建In-Process Command Buffer，如下所示：

InProcessCommandBuffer::InProcessCommandBuffer(
    const scoped_refptr<Service>& service)
    : ......,
      service_(service.get() ? service : GetDefaultService()),
      ...... {
  ......
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/service/in_process_command_buffer.cc中。

在创建In-Process Command Buffer的过程中，如果指定了一个Service，那么以后就会通过这个Service执行GPU命令。在我们这个情景中，指定的Service即为一个DeferredGpuCommandService服务。因此，这时候InProcessCommandBuffer类的成员变量service_指向的是一个DeferredGpuCommandService服务。

如果在创建In-Process Command Buffer的过程中，没有指定一个Service，那么InProcessCommandBuffer的构造函数就会通过调用另外一个成员函数GetDefaultService获得一个默认的Service，用来执行GPU命令。这个默认的Service实际上就是一个自行创建的GPU线程。

回到GLInProcessContextImpl类的成员函数Initialize中，它创建了一个In-Process Command Buffer之后，接下来还会调用这个InProcessCommandBuffer类的成员函数Initialize对它进行初始化，如下所示：

bool InProcessCommandBuffer::Initialize(
    scoped_refptr<gfx::GLSurface> surface,
    bool is_offscreen,
    gfx::AcceleratedWidget window,
    const gfx::Size& size,
    const std::vector<int32>& attribs,
    gfx::GpuPreference gpu_preference,
    const base::Closure& context_lost_callback,
    InProcessCommandBuffer* share_group) {
  ......

  gpu::Capabilities capabilities;
  InitializeOnGpuThreadParams params(is_offscreen,
                                     window,
                                     size,
                                     attribs,
                                     gpu_preference,
                                     &capabilities,
                                     share_group);

  base::Callback<bool(void)> init_task =
      base::Bind(&InProcessCommandBuffer::InitializeOnGpuThread,
                 base::Unretained(this),
                 params);

  base::WaitableEvent completion(true, false);
  bool result = false;
  QueueTask(
      base::Bind(&RunTaskWithResult<bool>, init_task, &result, &completion));
  completion.Wait();

  ......
  return result;
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/service/in_process_command_buffer.cc中。

InProcessCommandBuffer类的成员函数Initialize所做的事情就是通过成员变量service_指向的DeferredGpuCommandService服务请求在App的Render Thread中调用InProcessCommandBuffer类的成员函数InitializeOnGpuThread，以便对当前正在创建的In-Process Command Buffer进行初始化。

后面分析Render端执行的GPU命令的过程时，我们就会清楚地看到DeferredGpuCommandService服务是如何请求在App的Render Thread执行一个操作的。现在我们主要关注In-Process Command Buffer的初始化过程，也就是InProcessCommandBuffer类的成员函数InitializeOnGpuThread的实现，如下所示：

bool InProcessCommandBuffer::InitializeOnGpuThread(
    const InitializeOnGpuThreadParams& params) {
  ......

  scoped_ptr<CommandBufferService> command_buffer(
      new CommandBufferService(transfer_buffer_manager_.get()));
  command_buffer->SetPutOffsetChangeCallback(base::Bind(
      &InProcessCommandBuffer::PumpCommands, gpu_thread_weak_ptr_));
  ......

  decoder_.reset(gles2::GLES2Decoder::Create(
      params.context_group
          ? params.context_group->decoder_->GetContextGroup()
          : new gles2::ContextGroup(NULL,
                                    NULL,
                                    NULL,
                                    service_->shader_translator_cache(),
                                    NULL,
                                    bind_generates_resource)));

  gpu_scheduler_.reset(
      new GpuScheduler(command_buffer.get(), decoder_.get(), decoder_.get()));
  ......
  command_buffer_ = command_buffer.Pass();

  decoder_->set_engine(gpu_scheduler_.get());

  ......
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/service/in_process_command_buffer.cc中。

InProcessCommandBuffer类的成员函数InitializeOnGpuThread首先是创建了一个Command Buffer Service，并且保存在成员变量command_buffer_中。这个Command Buffer Service负责管理Command Buffer的状态，例如第一个等待执行的GPU命令的位置，以及最新写入的GPU命令的位置，等等。

InProcessCommandBuffer类的成员函数InitializeOnGpuThread创建了一个Command Buffer Service，会调用它的成员函数SetPutOffsetChangeCallback，用来设置一个Put Offset Change Callback，如下所示：

void CommandBufferService::SetPutOffsetChangeCallback(
    const base::Closure& callback) {
  put_offset_change_callback_ = callback;
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/service/command_buffer_service.cc中。

这个Callback指定为当前正在创建的In-Process Command Buffer的成员函数PumpCommands。当我们往Command Buffer写入了新的GPU命令时，这个Callback就会被执行，也就是InProcessCommandBuffer类的成员函数PumpCommands会被调用。

InProcessCommandBuffer类的成员函数PumpCommands在调用的过程中，就会通过一个Gpu Scheduler和一个GLES2 Decoder执行新写入到Command Buffer中的GPU命令。Gpu Scheduler在执行一个GPU命令之前，会将当前的OpenGL上下文切换至该GPU命令所属的OpenGL上下文，这样它就可以同时支持多个OpenGL上下文。GLES2 Decoder负责从Command Buffer中解析出每一个待执行的GPU命令及其携带的参数，这样就可以通过调用对应的OpenGL函数执行它们。关于Gpu Scheduler和一个GLES2 Decoder执行GPU命令的过程，可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

回到前面分析的InProcessCommandBuffer类的成员函数InitializeOnGpuThread中，上述Gpu Scheduler和GLES2 Decoder也是在InProcessCommandBuffer类的成员函数InitializeOnGpuThread中创建的。创建出来之后，就分别保存在InProcessCommandBuffer类的成员变量gpu_scheduler_和decoder_中。

这一步执行完成后，回到前面分析的SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread中，这时候它就获得了一个In-Process Command Buffer GL接口。这个In-Process Command Buffer GL接口是封装在一个GLInProcessContextImpl对象中的。这个GLInProcessContextImpl对象接下来又会通过函数WrapContext封装在一个WebGraphicsContext3DInProcessCommandBufferImpl对象中，如下所示：

scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl> WrapContext(
    scoped_ptr<gpu::GLInProcessContext> context) {
  ......

  return scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl>(
      WebGraphicsContext3DInProcessCommandBufferImpl::WrapContext(
          context.Pass(), GetDefaultAttribs()));
}

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

函数WrapContext通过调用WebGraphicsContext3DInProcessCommandBufferImpl类的静态成员函数WrapContext将一个GLInProcessContextImpl对象封装在一个WebGraphicsContext3DInProcessCommandBufferImpl对象中，如下所示：

scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl>
WebGraphicsContext3DInProcessCommandBufferImpl::WrapContext(
    scoped_ptr< ::gpu::GLInProcessContext> context,
    const blink::WebGraphicsContext3D::Attributes& attributes) {
  bool lose_context_when_out_of_memory = false;  // Not used.
  bool is_offscreen = true;                      // Not used.
  return make_scoped_ptr(new WebGraphicsContext3DInProcessCommandBufferImpl(
      context.Pass(),
      attributes,
      lose_context_when_out_of_memory,
      is_offscreen,
      gfx::kNullAcceleratedWidget /* window. Not used. */));
}

这个函数定义在文件external/chromium_org/webkit/common/gpu/webgraphicscontext3d_in_process_command_buffer_impl.cc中。

WebGraphicsContext3DInProcessCommandBufferImpl类的构造函数会将要封装的GLInProcessContextImpl对象保存在成员变量context_中，如下所示：

WebGraphicsContext3DInProcessCommandBufferImpl::
    WebGraphicsContext3DInProcessCommandBufferImpl(
        scoped_ptr< ::gpu::GLInProcessContext> context,
        const blink::WebGraphicsContext3D::Attributes& attributes,
        bool lose_context_when_out_of_memory,
        bool is_offscreen,
        gfx::AcceleratedWidget window)
    : ......,
      context_(context.Pass()) {
  ......
}

这个函数定义在文件external/chromium_org/webkit/common/gpu/webgraphicscontext3d_in_process_command_buffer_impl.cc中。

这一步执行完成后，继续回到前面分析的SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread中，这时候它就获得了一个WebGraphicsContext3DInProcessCommandBufferImpl对象。这个WebGraphicsContext3DInProcessCommandBufferImpl对象通过一个GLInProcessContextImpl对象间接地保存了前面创建的In-Process Command Buffer GL接口

SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread最后又会调用ContextProviderInProcess类的静态成员函数Create将上述WebGraphicsContext3DInProcessCommandBufferImpl对象封装在一个ContextProviderInProcess对象中，如下所示：

scoped_refptr<ContextProviderInProcess> ContextProviderInProcess::Create(
    scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl> context3d,
    const std::string& debug_name) {
  ......
  return new ContextProviderInProcess(context3d.Pass(), debug_name);
}

这个函数定义在文件external/chromium_org/webkit/common/gpu/context_provider_in_process.cc中。

ContextProviderInProcess对象会将要封装的WebGraphicsContext3DInProcessCommandBufferImpl对象保存在成员变量context_中，如下所示：

ContextProviderInProcess::ContextProviderInProcess(
    scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl> context3d,
    const std::string& debug_name)
    : context3d_(context3d.Pass()),
      ...... {
  ......
}

这个函数定义在文件external/chromium_org/webkit/common/gpu/context_provider_in_process.cc中。

这一步执行完成后，SynchronousCompositorImpl类的成员函数InitializeHwDraw，这时候它就是初始化了一个硬件加速渲染环境。这个硬件加速渲染环境就是通过前面创建的ContextProviderInProcess对象描述。这个ContextProviderInProcess对象接来会设置给SynchronousCompositorImpl类的成员变量output_surface_描述的一个Synchronous Compositor Output Surface。这是通过调用SynchronousCompositorOutputSurface类的成员函数InitializeHwDraw实现的，如下所示：

bool SynchronousCompositorOutputSurface::InitializeHwDraw(
    scoped_refptr<cc::ContextProvider> onscreen_context_provider) {
  ......

  return InitializeAndSetContext3d(onscreen_context_provider);
}

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

SynchronousCompositorOutputSurface类的成员函数InitializeHwDraw会调用另外一个成员函数InitializeAndSetContext3d将参数onscreen_context_provider指向的ContextProviderInProcess对象保存在内部。以后通过这个ContextProviderInProcess对象，就可以获得前面创建的In-Process Command Buffer GL接口了。

SynchronousCompositorOutputSurface类的成员函数InitializeAndSetContext3d是从父类OutputSurface继承下来的，它的实现如下所示：

bool OutputSurface::InitializeAndSetContext3d(
    scoped_refptr<ContextProvider> context_provider) {
  ......

  bool success = false;
  if (context_provider->BindToCurrentThread()) {
    context_provider_ = context_provider;
    ......
    success = true;
  }

  ......

  return success;
}

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

OutputSurface类的成员函数InitializeAndSetContext3d首先会调用参数context_provider指向的ContextProviderInProcess对象的成员函数BindToCurrentThread将其引用的In-Process Command Buffer GL接口设置为当前线程所使用的GL接口。当前线程即为Render端的Compositor线程。有了这个GL接口之后，Render端的Compositor线程就可以执行GPU操作了。

成功将参数context_provider指向的ContextProviderInProcess对象引用的In-Process Command Buffer GL接口设置为当前线程所使用的GL接口之后，该ContextProviderInProcess对象就会保存在OutputSurface类的成员变量context_provider_中。

接下来我们继续分析ContextProviderInProcess类的成员函数BindToCurrentThread为当前线程设置Process Command Buffer GL接口的过程，如下所示：

bool ContextProviderInProcess::BindToCurrentThread() {
  ......

  if (!context3d_->makeContextCurrent())
    return false;

  ......
  return true;
}

这个函数定义在文件external/chromium_org/webkit/common/gpu/context_provider_in_process.cc中。

从前面的分析可以知道，ContextProviderInProcess类的成员变量context3d_指向的是一个WebGraphicsContext3DInProcessCommandBufferImpl对象。ContextProviderInProcess类的成员函数BindToCurrentThread会调用这个WebGraphicsContext3DInProcessCommandBufferImpl对象的成员函数makeContextCurrent将前面创建的In-Process Command Buffer GL接口设置为当前线程所使用的GL接口，如下所示：

bool WebGraphicsContext3DInProcessCommandBufferImpl::makeContextCurrent() {
  if (!MaybeInitializeGL())
    return false;
  ::gles2::SetGLContext(GetGLInterface());
  return context_ && !isContextLost();
}

这个函数定义在文件external/chromium_org/webkit/common/gpu/webgraphicscontext3d_in_process_command_buffer_impl.cc中。

WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数makeContextCurrent首先调用成员函数MaybeInitializeGL检查是否已经为当前线程初始化过GL接口了。如果还没有初始化，那么就会进行初始化，如下所示：

bool WebGraphicsContext3DInProcessCommandBufferImpl::MaybeInitializeGL() {
  if (initialized_)
    return true;
  ......

  real_gl_ = context_->GetImplementation();
  setGLInterface(real_gl_);

  ......

  initialized_ = true;
  return true;
}

这个函数定义在文件external/chromium_org/webkit/common/gpu/webgraphicscontext3d_in_process_command_buffer_impl.cc中。

当WebGraphicsContext3DInProcessCommandBufferImpl类的成员变量initialized_的值等于true的时候，就表示当前线程初始化过GL接口了。另一方面，如果当前线程还没有初始化过GL接口，那么WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数MaybeInitializeGL就会进行初始化。

从前面的分析可以知道，WebGraphicsContext3DInProcessCommandBufferImpl类的成员变量context_指向的是一个GLInProcessContextImpl对象。调用这个GLInProcessContextImpl对象的成员函数可以获得它内部封装一个GLES2Implementation对象。这个GLES2Implementation对象描述的就是一个In-Process Command Buffer GL接口。

WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数MaybeInitializeGL获得了上述In-Process Command Buffer GL接口之后，会调用另外一个成员函数setGLInterface将其保存起来。

WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数setGLInterface是从父类WebGraphicsContext3DImpl继承下来的，它的实现如下所示：

class WEBKIT_GPU_EXPORT WebGraphicsContext3DImpl  
    : public NON_EXPORTED_BASE(blink::WebGraphicsContext3D) {  
 public:  
  ......  
  
  ::gpu::gles2::GLES2Interface* GetGLInterface() {  
    return gl_;  
  }  
  
 protected:  
  ......  
  
  void setGLInterface(::gpu::gles2::GLES2Interface* gl) {  
    gl_ = gl;  
  }  
  
  ......  
  
  ::gpu::gles2::GLES2Interface* gl_;  
  ......  
};

这个函数定义在文件external/chromium_org/webkit/common/gpu/webgraphicscontext3d_impl.h中。

WebGraphicsContext3DImpl类的成员函数setGLInterface将参数描述的In-Process Command Buffer GL接口保存在成员变量gl_中。这个In-Process Command Buffer GL接口可以通过调用WebGraphicsContext3DImpl类的另外一个成员函数GetGLInterface获得。

这一步执行完成后，回到前面分析的WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数makeContextCurrent，它接下来又会调用从父类WebGraphicsContext3DImpl继承下来的成员函数GetGLInterface获得前面所保存的In-Process Command Buffer GL接口，并且将该In-Process Command Buffer GL接口设置为当前线程的GL接口，也就是OpenGL调用接口。这是通过调用函数gles2::SetGLContext实现的，如下所示：

static gpu::ThreadLocalKey g_gl_context_key;   

......
 
gpu::gles2::GLES2Interface* GetGLContext() {  
  return static_cast<gpu::gles2::GLES2Interface*>(  
    gpu::ThreadLocalGetValue(g_gl_context_key));  
}
 
void SetGLContext(gpu::gles2::GLES2Interface* context) {  
  gpu::ThreadLocalSetValue(g_gl_context_key, context);  
}

这两个函数定义在文件external/chromium_org/gpu/command_buffer/client/gles2_lib.cc中。

参数context描述的In-Process Command Buffer GL接口将被保存在全局变量g_gl_context_key所描述的一个线程局部储存中，作为当前线程所使用的OpenGL接口。以后通过调用另外一个函数gles2::GetGLContext就可以获得保存在这个线程局部储存中的In-Process Command Buffer GL接口。

这一步执行完成后，以后Render端的Compositor线程直接调用OpenGL函数glXXX时，就会通过In-Process Command Buffer GL接口执行指定的GPU的操作。从OpenGL函数glXXX调用到In-Process Command Buffer GL接口的原理可以参考前面Chromium网页GPU光栅化原理分析一文。

Render端的Compositor线程除了可以通过OpenGL函数glXXX使用In-Process Command Buffer GL接口，还可以通过它为网页创建的Synchronous Compositor Output Surface使用In-Process Command Buffer GL接口。接下来，我们就以Render端的Compositor线程执行GPU光栅化操作为例，说明它执行GPU命令的过程。

从前面Chromium网页GPU光栅化原理分析一文可以知道，当Render端的Compositor线程是通过一个Skia Canvas对网页UI进行GPU光栅化操作的。这个Skia Canvas又是通过一个类型为SkSurface_Gpu的Skia Surface获得的。这个类型为SkSurface_Gpu的Skia Surface是通过调用DirectRasterBuffer类的成员函数CreateSurface创建的，如下所示：

skia::RefPtr<SkSurface> ResourceProvider::DirectRasterBuffer::CreateSurface() {  
  skia::RefPtr<SkSurface> surface;  
  switch (resource()->type) {  
    case GLTexture: {  
      ......  
      class GrContext* gr_context = resource_provider()->GrContext();  
      if (gr_context) {  
        GrBackendTextureDesc desc;  
        ......
 
        skia::RefPtr<GrTexture> gr_texture =  
            skia::AdoptRef(gr_context->wrapBackendTexture(desc));  
        ......
  
        surface = skia::AdoptRef(SkSurface::NewRenderTargetDirect(  
            gr_texture->asRenderTarget(), text_render_mode));  
      }  
      break;  
    }  
    ......
  }  
  return surface;  
}

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

DirectRasterBuffer类的成员函数CreateSurface的详细实现可以参考前面Chromium网页GPU光栅化原理分析一文。这里我们所关注的重点是它通过调用ResourceProvider类的成员函数GrContext获得一个In-Process Command Buffer GL接口的过程。这个In-Process Command Buffer GL接口会传递给这里所创建的类型为SkSurface_Gpu的Skia Surface。有了In-Process Command Buffer GL接口之后，类型为SkSurface_Gpu的Skia Surface就可以通过GPU对网页的UI进行光栅化了。

DirectRasterBuffer类的成员函数CreateSurface首先是调用成员函数resource_provider获得一个ResourceProvider对象。这个ResourceProvider对象负责管理网页在渲染过程中所要使用到的资源。有这个ResourceProvider对象之后，就可以调用它的成员函数GrContext获得一个In-Process Command Buffer GL接口，如下所示：

class GrContext* ResourceProvider::GrContext() const {
  ContextProvider* context_provider = output_surface_->context_provider();
  return context_provider ? context_provider->GrContext() : NULL;
}

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

ResourceProvider类的成员变量output_surface_指向的就是一个SynchronousCompositorOutputSurface对象。ResourceProvider类的成员函数GrContext会调用这个SynchronousCompositorOutputSurface对象的成员函数context_provider获得一个Context Provider。

SynchronousCompositorOutputSurface对象的成员函数context_provider是从父类OutputSurface继承下来的，它的实现如下所示：

class CC_EXPORT OutputSurface {
  ......

  scoped_refptr<ContextProvider> context_provider() const {
    return context_provider_.get();
  }

  ......
};

这个函数定义在文件external/chromium_org/cc/output/output_surface.h中。

从前面的分析可以知道，此时OutputSurface类的成员变量context_provider_指向的是一个ContextProviderInProcess对象。OutputSurface类的成员函数context_provider将这个ContextProviderInProcess对象返回给调用者。

回到前面分析的ResourceProvider类的成员函数GrContext中，这时候它就获得了一个ContextProviderInProcess对象。接下来它继续调用这个ContextProviderInProcess对象的成员函数GrContext获得一个GrContextForWebGraphicsContext3D对象，如下所示：

class GrContext* ContextProviderInProcess::GrContext() {
  ......

  if (gr_context_)
    return gr_context_->get();

  gr_context_.reset(
      new webkit::gpu::GrContextForWebGraphicsContext3D(context3d_.get()));
  return gr_context_->get();
}

这个函数定义在文件external/chromium_org/webkit/common/gpu/context_provider_in_process.cc中。

ContextProviderInProcess类的成员函数GrContext首先判断成员变量gr_context_是否指向了一个GrContextForWebGraphicsContext3D对象。如果已经指向，那么就会将该GrContextForWebGraphicsContext3D对象返回给调用者。

另一方面，如果ContextProviderInProcesGrContextForWebGraphicsContext3Ds类的成员变量gr_context_还没有指向一个GrContextForWebGraphicsContext3D对象，那么ContextProviderInProcess类的成员函数GrContext就会先创建该GrContextForWebGraphicsContext3D对象，然后再将它返回给调用者。

在创建GrContextForWebGraphicsContext3D对象的时候，会使用到ContextProviderInProcess类的成员变量context3d_。从前面的分析可以知道，ContextProviderInProcess类的成员变量context3d_指向的是一个WebGraphicsContext3DInProcessCommandBufferImpl对象。这个WebGraphicsContext3DInProcessCommandBufferImpl对象内部封装了一个In-Process Command Buffer GL接口。

因此，ContextProviderInProcess类的成员函数GrContext创建出来的GrContextForWebGraphicsContext3D对象也会间接地引用了一个In-Process Command Buffer GL接口。前面创建的类型为SkSurface_Gpu的Skia Surface在光栅化网页UI的时候，就会使用到这个In-Process Command Buffer GL接口，也就是会将要执行的GPU命令写入到一个In-Process Command Buffer中去。

写入到In-Process Command Buffer中的命令会被周期性地提交给DeferredGpuCommandService服务处理。这是通过调用InProcessCommandBuffer类的成员函数Flush实现的。或者我们也可以主动地调用In-Process Command Buffer GL接口提供的成员函数Flush将写入在In-Process Command Buffer中的命令会被周期性地提交给DeferredGpuCommandService服务。这个主动提交的操作最终也是通过调用InProcessCommandBuffer类的成员函数Flush实现的。这一点可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

接下来，我们就从InProcessCommandBuffer类的成员函数Flush开始，分析Render端在使用GPU光栅化网页UI的过程中，是如何执行GPU命令的，如下所示：

void InProcessCommandBuffer::Flush(int32 put_offset) {
  ......

  last_put_offset_ = put_offset;
  base::Closure task = base::Bind(&InProcessCommandBuffer::FlushOnGpuThread,
                                  gpu_thread_weak_ptr_,
                                  put_offset);
  QueueTask(task);
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/service/in_process_command_buffer.cc中。

参数put_offset表示最新写入的GPU命令在In-Process Command Buffer中的位置。InProcessCommandBuffer类的成员函数Flush首先将这个位置记录在成员变量last_put_offset_中。

InProcessCommandBuffer类的成员函数Flush接下来创建了一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。接下来这个Task会被提交给DeferredGpuCommandService服务处理。这是通过调用InProcessCommandBuffer类的成员函数QueueTask实现的，如下所示：

class GPU_EXPORT InProcessCommandBuffer : public CommandBuffer,
                                          public GpuControl {
 ......

 private:
  ......

  void QueueTask(const base::Closure& task) { service_->ScheduleTask(task); }

  ......
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/service/in_process_command_buffer.h中。

从前面的分析可以知道，InProcessCommandBuffer类的成员变量service_描述的就是一个DeferredGpuCommandService服务。InProcessCommandBuffer类的成员函数QueueTask通过调用这个DeferredGpuCommandService服务的成员函数ScheduleTask调度执行参数task描述的Task。

DeferredGpuCommandService类的成员函数ScheduleTask的实现如下所示：

void DeferredGpuCommandService::ScheduleTask(const base::Closure& task) {
  {
    base::AutoLock lock(tasks_lock_);
    tasks_.push(task);
  }
  if (ScopedAllowGL::IsAllowed()) {
    RunTasks();
  } else {
    RequestProcessGL();
  }
}

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

DeferredGpuCommandService类的成员函数ScheduleTask首先将参数task描述的Task保存在成员变量tasks_描述的一个std::queue中。

DeferredGpuCommandService类的成员函数ScheduleTask接下来通过调用ScopedAllowGL类的静态成员函数IsAllowed判断当前线程是否允许直接执行GPU命令，也就是当前线程是否是一个GPU线程。如果是的话，那么就会调用成员函数RunTasks执行参数task描述的Task，如下所示：

void DeferredGpuCommandService::RunTasks() {
  bool has_more_tasks;
  {
    base::AutoLock lock(tasks_lock_);
    has_more_tasks = tasks_.size() > 0;
  }

  while (has_more_tasks) {
    base::Closure task;
    {
      base::AutoLock lock(tasks_lock_);
      task = tasks_.front();
      tasks_.pop();
    }
    task.Run();
    {
      base::AutoLock lock(tasks_lock_);
      has_more_tasks = tasks_.size() > 0;
    }
  }
}

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

DeferredGpuCommandService类的成员函数RunTasks会依次执行保存在成员变量tasks_描述的std::queue中的每一个Task。从前面的分析可以知道，这个std::queue保存了一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。因此，当该Task被执行的时候，InProcessCommandBuffer类的成员函数FlushOnGpuThread就会被调用。在调用的过程中，就会执行那些新写入到In-Process Command Buffer的GPU命令。

DeferredGpuCommandService类的成员函数ScheduleTask可以直接调用成员函数RunTasks执行GPU命令的情况发生在Browser端合成网页UI的过程中。这时候Browser端运行在App的Render Thread中，并且它会通过ScopedAllowGL类标记App的Render Thread可以执行GPU命令。这样DeferredGpuCommandService类的成员函数ScheduleTask就可以知道它可以直接执行GPU命令了。

在我们这个情景中，正在执行的是网页UI的光栅化操作。这个操作是发生在Render端的Compositor线程中的。Render端的Compositor线程不是一个GPU线程，因此这时候DeferredGpuCommandService类的成员函数ScheduleTask就不能直接调用成员函数RunTasks执行GPU命令，而是要通过调用另外一个成员函数RequestProcessGL请求App的Render Thread执行。

另外一个情景，也就是Render端绘制网页UI的情景，也是发生在Render端的Compositor线程。这时候DeferredGpuCommandService类的成员函数ScheduleTask也需要调用成员函数RequestProcessGL请求App的Render Thread执行绘制网页UI所需要执行的GPU命令。

接下来，我们就继续分析DeferredGpuCommandService类的成员函数RequestProcessGL，以便了解它请求App的Render Thread执行GPU命令的过程，如下所示：

void DeferredGpuCommandService::RequestProcessGL() {
  SharedRendererState* renderer_state =
      GLViewRendererManager::GetInstance()->GetMostRecentlyDrawn();
  ......
  renderer_state->ClientRequestDrawGL();
}

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

我们在前面Android WebView启动Chromium渲染引擎的过程分析一文中提到，在Chromium渲染引擎中，存在一个GLViewRendererManager单例对象。这个GLViewRendererManager单例对象记录了当前有哪些WebView是采用硬件加速方式绘制的。通过调用这个GLViewRendererManager对象的成员函数GetMostRecentlyDrawn可以获得一个SharedRendererState对象。这个SharedRendererState对象的创建过程可以参考前面Android WebView启动Chromium渲染引擎的过程分析一文，它记录了当前正在绘制的Android WebView的状态。

获得了与当前正在绘制的Android WebView关联的一个SharedRendererState对象之后，DeferredGpuCommandService类的成员函数RequestProcessGL就可以调用它的成员函数ClientRequestDrawGL请求App的Render Thread执行GPU命令，如下所示：

void SharedRendererState::ClientRequestDrawGL() {
  if (ui_loop_->BelongsToCurrentThread()) {
    ......
    ClientRequestDrawGLOnUIThread();
  } else {
    ......
    base::Closure callback;
    {
      base::AutoLock lock(lock_);
      callback = request_draw_gl_closure_;
    }
    ui_loop_->PostTask(FROM_HERE, callback);
  }
}

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

从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，SharedRendererState类的成员变量ui_loop_描述的就是Chromium的Browser端的Native UI Message Loop。通过这个Native UI Message Loop可以判断当前线程是否就是App的UI线程。如果是的话，那么SharedRendererState类的成员函数ClientRequestDrawGL就会直接调用另外一个成员函数ClientRequestDrawGLOnUIThread请求App的Render Thread执行GPU命令。

如果当前线程不是App的UI线程，那么SharedRendererState类的成员函数ClientRequestDrawGL就会向Chromium的Browser端的Native UI Message Loop发送一个Task。这个Task由SharedRendererState类的成员变量request_draw_gl_closure_描述，它绑定的函数为SharedRendererState类的成员函数ClientRequestDrawGLOnUIThread。这样做的目的是让SharedRendererState类的成员函数ClientRequestDrawGLOnUIThread运行在App的UI线程中，以便可以通过App的UI线程来请求App的Render Thread执行GPU命令。

SharedRendererState类的成员函数ClientRequestDrawGLOnUIThread的实现如下所示：

void SharedRendererState::ClientRequestDrawGLOnUIThread() {
  ......

  if (!client_on_ui_->RequestDrawGL(NULL, false)) {
    ......
  }
}

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

从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，SharedRendererState类的成员变量client_on_ui_指向的是一个Native层的AwContents对象。SharedRendererState类的成员函数ClientRequestDrawGLOnUIThread通过调用这个AwContents对象的成员函数RequestDrawGL请求App的Render Thread执行GPU命令，如下所示：

bool AwContents::RequestDrawGL(jobject canvas, bool wait_for_completion) {
  ......
  JNIEnv* env = AttachCurrentThread();
  ScopedJavaLocalRef<jobject> obj = java_ref_.get(env);
  .......
  return Java_AwContents_requestDrawGL(
      env, obj.obj(), canvas, wait_for_completion);
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，每一个Native层的AwContents对象在Java层都有一个对应的AwContents对象。这个Java层的AwContents对象就保存在Native层的AwContents对象的成员变量java_ref_中。AwContents类的成员函数RequestDrawGL通过JNI方法Java_AwContents_requestDrawGL调用上述的Java层AwContents对象的成员函数requestDrawGL，用来请求App的Render Thread执行GPU命令。

Java层的AwContents类的成员函数requestDrawGL的实现如下所示：

public class AwContents {
    ......

    @CalledByNative
    private boolean requestDrawGL(Canvas canvas, boolean waitForCompletion) {
        return mNativeGLDelegate.requestDrawGL(canvas, waitForCompletion, mContainerView);
    }

    ......
}

这个函数定义在文件external/chromium_org/android_webview/java/src/org/chromium/android_webview/AwContents.java中。

从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，AwContents类的成员变量mNativeGLDelegate指向的是一个WebViewNativeGLDelegate对象。AwContents类的成员函数requestDrawGL调用这个WebViewNativeGLDelegate对象的成员函数requestDrawGL请求App的Render Thread执行GPU命令，如下所示：

class WebViewChromium implements WebViewProvider,
          WebViewProvider.ScrollDelegate, WebViewProvider.ViewDelegate {
    ......

    private DrawGLFunctor mGLfunctor;
    ......

    private class WebViewNativeGLDelegate implements AwContents.NativeGLDelegate {
        @Override
        public boolean requestDrawGL(Canvas canvas, boolean waitForCompletion,
                View containerView) {
            if (mGLfunctor == null) {
                mGLfunctor = new DrawGLFunctor(mAwContents.getAwDrawGLViewContext());
            }
            return mGLfunctor.requestDrawGL(
                    (HardwareCanvas) canvas, containerView.getViewRootImpl(), waitForCompletion);
        }

        ......
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromium.java中。

WebViewNativeGLDelegate类的成员函数requestDrawGL首先判断外部类WebViewChromium的成员变量mGLFunctor是否指向了一个DrawGLFunctor对象。如果指向了，那么就会调用它的成员函数requestDrawGL请求App的Render Thread执行GPU命令。

另一方面，如果WebViewChromium类的成员变量mGLFunctor还没有指向一个DrawGLFunctor对象，那么WebViewNativeGLDelegate类的成员函数requestDrawGL就会创建这个DrawGLFunctor对象。创建过程如下所示：

class DrawGLFunctor {
    ......

    public DrawGLFunctor(long viewContext) {
        mDestroyRunnable = new DestroyRunnable(nativeCreateGLFunctor(viewContext));
        ......
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/DrawGLFunctor.java中。

DrawGLFunctor类的构造函数首先会调用成员函数nativeCreateGLFunctor获得一个Native层的DrawGLFunctor对象，然后再使用这个Native层的DrawGLFunctor对象创建一个DestroyRunnable对象，如下所示：

class DrawGLFunctor {
    ......

    private static final class DestroyRunnable implements Runnable {
        ......
        long mNativeDrawGLFunctor;
        DestroyRunnable(long nativeDrawGLFunctor) {
            mNativeDrawGLFunctor = nativeDrawGLFunctor;
        }

        ......
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/DrawGLFunctor.java中。

DestroyRunnable类的构造函数主要就是将参数nativeDrawGLFunctor描述的Native层DrawGLFunctor对象保存在成员变量mNativeDrawGLFunctor中。

接下来我们继续分析Native层的DrawGLFunctor对象的创建过程，也就是DrawGLFunctor类的成员函数nativeCreateGLFunctor的实现。wGLFunctor类的成员函数nativeCreateGLFunctor是一个JNI方法，它由C++层的函数CreateGLFunctor实现，如下所示：

jlong CreateGLFunctor(JNIEnv*, jclass, jlong view_context) {
  RaiseFileNumberLimit();
  return reinterpret_cast<jlong>(new DrawGLFunctor(view_context));
}

这个函数定义在文件frameworks/webview/chromium/plat_support/draw_gl_functor.cpp中。

从这里可以看到，函数CreateGLFunctor创建的是一个Native层的DrawGLFunctor对象。这个DrawGLFunctor对象是用来描述Chromium渲染引擎请求App的Render Thread执行的GPU操作集合。

这一步执行完成后，回到前面分析的WebViewNativeGLDelegate类的成员函数requestDrawGL中，接下来我们继续分析它调用外部类WebViewChromium类的成员变量mGLFunctor指向一个Java层的DrawGLFunctor对象的成员函数requestDrawGL请求App的Render Thread执行GPU命令，如下所示：

class DrawGLFunctor {
    ......

    public boolean requestDrawGL(HardwareCanvas canvas, ViewRootImpl viewRootImpl,
            boolean waitForCompletion) {
        ......

        if (canvas == null) {
            viewRootImpl.invokeFunctor(mDestroyRunnable.mNativeDrawGLFunctor, waitForCompletion);
            return true;
        }

        canvas.callDrawGLFunction(mDestroyRunnable.mNativeDrawGLFunctor);
        ......

        return true;
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/DrawGLFunctor.java中。

从前面的调用过程可以知道，参数canvas的值为null，另外一个参数waitForCompletion的值等于false。

当参数canvas的值为null的时候，表示Chromium渲染引擎直接请求App的Render Thread执行GPU命令。这种情况一般就是发生在Render端光栅化网页UI的过程中。

当参数canvas的值不等于null时，它指向一个Hardware Canvas，表示Chromium渲染引擎请求App的UI线程先将要执行的GPU命令记录在App UI的Display List中。等到该Display List同步给App的Render Thread，并且被App的Render Thread重放的时候，再执行请求的GPU命令。这种情况发生在Render端绘制网页UI的过程中。

另外一个参数waitForCompletion表示App的UI线程是否需要同步等待App的Render Thread执行完成请求的GPU命令。

在我们这个情景中，DrawGLFunctor类的成员函数requestDrawGL将会直接请求App的Render Thread执行GPU命令。这是通过调用参数viewRootImpl指向的一个ViewRootImpl对象的成员函数invokeFunctor实现的，如下所示：

public final class ViewRootImpl implements ViewParent,
        View.AttachInfo.Callbacks, HardwareRenderer.HardwareDrawCallbacks {
    ......

    public void invokeFunctor(long functor, boolean waitForCompletion) {
        ThreadedRenderer.invokeFunctor(functor, waitForCompletion);
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/view/ViewRootImpl.java中。

ViewRootImpl类的成员函数invokeFunctor会调用ThreadedRenderer类的静态成员函数invokeFunctor请求App的Render Thread执行GPU命令，如下所示：

public class ThreadedRenderer extends HardwareRenderer {
    ......

    static void invokeFunctor(long functor, boolean waitForCompletion) {
        nInvokeFunctor(functor, waitForCompletion);
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/view/ThreadedRenderer.java中。

ThreadedRenderer类的静态成员函数invokeFunctor调用另外一个静态成员函数nInvokeFunctor请求App的Render Thread执行GPU命令。

ThreadedRenderer类的静态成员函数nInvokeFunctor是一个JNI方法，它由C++层的函数android_view_ThreadedRenderer_invokeFunctor实现，如下所示：

static void android_view_ThreadedRenderer_invokeFunctor(JNIEnv* env, jobject clazz,
        jlong functorPtr, jboolean waitForCompletion) {
    Functor* functor = reinterpret_cast<Functor*>(functorPtr);
    RenderProxy::invokeFunctor(functor, waitForCompletion);
}

这个函数定义在文件frameworks/base/core/jni/android_view_ThreadedRenderer.cpp中。

从前面的分析可以知道，参数functorPtr描述的是一个Native层的DrawGLFunctor对象。这个DrawGLFunctor对象是从Functor类继承下来的，因此函数android_view_ThreadedRenderer_invokeFunctor可以将它转换为一个Functor对象。这个Functor对象会通过RenderProxy类的静态成员函数invokeFunctor提交给App的Render Thread处理，如下所示：

CREATE_BRIDGE2(invokeFunctor, RenderThread* thread, Functor* functor) {
    CanvasContext::invokeFunctor(*args->thread, args->functor);
    return NULL;
}

void RenderProxy::invokeFunctor(Functor* functor, bool waitForCompletion) {
    ATRACE_CALL();
    RenderThread& thread = RenderThread::getInstance();
    SETUP_TASK(invokeFunctor);
    args->thread = &thread;
    args->functor = functor;
    if (waitForCompletion) {
        // waitForCompletion = true is expected to be fairly rare and only
        // happen in destruction. Thus it should be fine to temporarily
        // create a Mutex
        Mutex mutex;
        Condition condition;
        SignalingRenderTask syncTask(task, &mutex, &condition);
        AutoMutex _lock(mutex);
        thread.queue(&syncTask);
        condition.wait(mutex);
    } else {
        thread.queue(task);
    }
}

这个函数定义在文件frameworks/base/libs/hwui/renderthread/RenderProxy.cpp中。

App的Render Thread可以通过调用RenderThread类的静态成员函数getInstance获得。获得了App的Render Thread之后，RenderProxy类的静态成员函数invokeFunctor就可以往它的消息队列发送一个Task。这个Task封装参数funtor描述的一个Native层的DrawGLFunctor对象，并且它绑定了由宏CREATE_BRIDGE2定义的函数invokeFunctor。

这意味着当上述Task被App的Render Thread调度执行的时候，函数invokeFunctor就会在App的Render Thread中执行，它主要就是通过调用CanvasContext类的静态成员函数invokeFunctor通知参数参数funtor描述的Native层DrawGLFunctor对象，现在可以执行GPU命令了。

从前面的调用过程可以知道，参数waitForCompletion的值等于false，表示当前线程（也就是App的UI线程）不用等待App的Render Thread执行完成请求的GPU命令，于是它就可以马上返回。

接下来我们就继续分析CanvasContext类的静态成员函数invokeFunctor的实现，如下所示：

void CanvasContext::invokeFunctor(RenderThread& thread, Functor* functor) {
    ATRACE_CALL();
    DrawGlInfo::Mode mode = DrawGlInfo::kModeProcessNoContext;
    if (thread.eglManager().hasEglContext()) {
        thread.eglManager().requireGlContext();
        mode = DrawGlInfo::kModeProcess;
    }

    thread.renderState().invokeFunctor(functor, mode, NULL);
}

这个函数定义在文件frameworks/base/libs/hwui/renderthread/CanvasContext.cpp中。

CanvasContext类的静态成员函数invokeFunctor主要就是通过调用一个RenderState对象的成员函数invokeFunctor通知参数funtor描述的一个Native层DrawGLFunctor对象执行GPU命令。这个RenderState对象记录了App的Render Thread的当前渲染状态，它可以通过调用参数thread描述的一个RenderThread对象的成员函数renderState获得。

如果此时App的Render Thread已经初始化好了OpenGL环境，那么RenderState类的成员函数invokeFunctor将会通知参数funtor描述的Native层DrawGLFunctor对象以DrawGlInfo::kModeProcess的模式执行GPU命令。否则的话，就以DrawGlInfo::kModeProcessNoContext的模式行。由于App的Render Thread一开始就会初始化OpenGL环境，因此我们将认为RenderState类的成员函数invokeFunctor将会通知参数funtor描述的Native层DrawGLFunctor对象以DrawGlInfo::kModeProcess的模式执行GPU命令。

RenderState类的成员函数invokeFunctor的实现如下所示：

void RenderState::invokeFunctor(Functor* functor, DrawGlInfo::Mode mode, DrawGlInfo* info) {
    interruptForFunctorInvoke();
    (*functor)(mode, info);
    resumeFromFunctorInvoke();
}

这个函数定义在文件frameworks/base/libs/hwui/RenderState.cpp中。

RenderState类的成员函数invokeFunctor主要就是调用了参数functor描述的一个Native层DrawGLFunctor对象的重载操作符函数()，用来通知它执行GPU命令，如下所示：

AwDrawGLFunction* g_aw_drawgl_function = NULL;

class DrawGLFunctor : public Functor {
 public:
  ......

  // Functor
  virtual status_t operator ()(int what, void* data) {
    ......

    AwDrawGLInfo aw_info;
    aw_info.version = kAwDrawGLInfoVersion;
    switch (what) {
      case DrawGlInfo::kModeDraw: {
        aw_info.mode = AwDrawGLInfo::kModeDraw;
        ......
        break;
      }
      case DrawGlInfo::kModeProcess:
        aw_info.mode = AwDrawGLInfo::kModeProcess;
        break;
      case DrawGlInfo::kModeProcessNoContext:
        aw_info.mode = AwDrawGLInfo::kModeProcessNoContext;
        break;
      case DrawGlInfo::kModeSync:
        aw_info.mode = AwDrawGLInfo::kModeSync;
        break;
      default:
        ALOGE("Unexpected DrawGLInfo type %d", what);
        return DrawGlInfo::kStatusDone;
    }

    // Invoke the DrawGL method.
    g_aw_drawgl_function(view_context_, &aw_info, NULL);

    return DrawGlInfo::kStatusDone;
  }

  ......
};

这个函数定义在文件frameworks/webview/chromium/plat_support/draw_gl_functor.cpp中。

DrawGLFunctor类的重载操作符函数()主要就是调用全局变量g_aw_drawgl_function描述的一个DrawGL函数执行GPU命令，并且告知该DrawGL函数，App的Render Thread当前处于什么状态。这个状态由参数what描述的GPU执行模式决定。

App的Render Thread有四种状态：

1. AwDrawGLInfo::kModeDraw：表示App的Render Thread正在重放App UI的Display List。

2. DrawGlInfo::kModeProcess：表示App的Render Thread正在执行外界请求的GPU命令，并且App的Render Thread当前具有OpenGL上下文。

3. AwDrawGLInfo::kModeProcessNoContext：表示App的Render Thread正在执行外界请求的GPU命令，但是App的Render Thread当前没有OpenGL上下文。

4, AwDrawGLInfo::kModeSync：表示App的Render Thread正在同步的App的UI线程的Display List。

在我们这个情景中，App的Render Thread正处于第2种状态。第3种状态几乎不会出现，我们不予考虑。第1种和第4种状态我们在接下来一篇文章分析Android WebView渲染网页UI的过程中再详细分析。

从前面的分析可以知道，全局变量g_aw_drawgl_function描述的DrawGL函数是由Android WebView在启动Chromium渲染引擎时注册的，它指向的函数为DrawGLFunction，它的实现如下所示：

static void DrawGLFunction(long view_context,
                           AwDrawGLInfo* draw_info,
                           void* spare) {
  // |view_context| is the value that was returned from the java
  // AwContents.onPrepareDrawGL; this cast must match the code there.
  reinterpret_cast<android_webview::AwContents*>(view_context)
      ->DrawGL(draw_info);
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

参数view_context描述的是一个Native层的AwContents对象。函数DrawGLFunction主要就是调用这个AwContents对象的成员函数DrawGL执行GPU命令，如下所示：

void AwContents::DrawGL(AwDrawGLInfo* draw_info) {
  if (draw_info->mode == AwDrawGLInfo::kModeSync) {
    if (hardware_renderer_)
      hardware_renderer_->CommitFrame();
    return;
  }

  ......

  ScopedAllowGL allow_gl;
  ......

  if (draw_info->mode != AwDrawGLInfo::kModeDraw) {
    ......
    return;
  }

  if (!hardware_renderer_) {
    hardware_renderer_.reset(new HardwareRenderer(&shared_renderer_state_));
    hardware_renderer_->CommitFrame();
  }

  hardware_renderer_->DrawGL(state_restore.stencil_enabled(),
                             state_restore.framebuffer_binding_ext(),
                             draw_info);
  ......
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

AwContents类的成员函数DrawGL根据App的Render Thread的当前不同的状态执行不同的操作。在分析这些操作之前，我们首先介绍AwContents类的成员变量hardware_renderer_。如果它的值不等于NULL，那么它就是指向一个HardwareRenderer对象。这个HardwareRenderer对象是Browser端用来合成网页UI的。

如果App的Render Thread的当前状态是AwDrawGLInfo::kModeSync，并且当前AwContents类的成员变量hardware_renderer_指向了一个HardwareRenderer对象，那么AwContents类的成员函数DrawGL就会调用这个HardwareRenderer对象的成员函数CommitFrame将Render端上一次绘制出来的网页UI同步到Browser端。

如果App的Render Thread的当前状态是AwDrawGLInfo::kModeProcess，那么AwContents类的成员函数DrawGL就会构造一个ScopedAllowGL对象。这个ScopedAllowGL对象在构造的过程中，就会通知DeferredGpuCommandService服务执行Render端之前请求执行的GPU命令。

如果App的Render Thread的当前状态是AwDrawGLInfo::kModeDraw，那么AwContents类的成员函数DrawGL同样先通过上述构造的ScopedAllowGL对象通知DeferredGpuCommandService服务执行Render端之前请求执行的GPU命令。此外，AwContents类的成员函数DrawGL还会调用成员变量hardware_renderer_指向了一个HardwareRenderer对象的成员函数DrawGL将从Render端同步过来的网页UI合成显示在屏幕中。如果这个HardwareRenderer对象还没有创建，那么就会进行创建，并且会在创建后将Render端上一次绘制出来的网页UI同步到Browser端来，以便接下来可以将它合成显示在屏幕中。

从前面的分析可以知道，App的Render Thread的当前状态是AwDrawGLInfo::kModeProcess，因此接下来AwContents类的成员函数DrawGL就会通过构造一个ScopedAllowGL对象来通知DeferredGpuCommandService服务执行Render端之前请求执行的GPU命令。这些GPU命令是用来光栅化网页的UI的。

ScopedAllowGL对象的构造过程如下所示：

base::LazyInstance<scoped_refptr<DeferredGpuCommandService> >
    g_service = LAZY_INSTANCE_INITIALIZER;
......

base::LazyInstance<base::ThreadLocalBoolean> ScopedAllowGL::allow_gl;
......

bool ScopedAllowGL::IsAllowed() {
  return allow_gl.Get().Get();
}

ScopedAllowGL::ScopedAllowGL() {
  DCHECK(!allow_gl.Get().Get());
  allow_gl.Get().Set(true);

  if (g_service.Get())
    g_service.Get()->RunTasks();
}

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

ScopedAllowGL类的构造函数首先是通过ScopedAllowGL类的静态成员变量allow_gl描述的一个线程局存储将当前线程标记为一个GPU线程，这样当前线程就可以直接执行GPU命令了。

全局变量g_service描述的就是一个DeferredGpuCommandService服务。ScopedAllowGL类的构造函数接下来就会调用这个DeferredGpuCommandService服务的成员函数RunTasks调度执行保存在它内部的一个Task队列中的Task了。DeferredGpuCommandService类的成员函数RunTasks我们在前面已经分析过了，这里不再复述。

从前面的分析可以知道，DeferredGpuCommandService服务内部的Task队列保存了一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。这意味着接下来InProcessCommandBuffer类的成员函数FlushOnGpuThread会在App的Render Thread中调用，它的实现如下所示：

void InProcessCommandBuffer::FlushOnGpuThread(int32 put_offset) {
  ......

  command_buffer_->Flush(put_offset);

  ......
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/service/in_process_command_buffer.cc中。

从前面的分析可以知道，InProcessCommandBuffer类的成员变量command_buffer_指向的是一个CommandBufferService对象。InProcessCommandBuffer类的成员函数FlushOnGpuThread调用这个CommandBufferService对象的成员函数Flush执行GPU命令，如下所示：

void CommandBufferService::Flush(int32 put_offset) {
  ......

  put_offset_ = put_offset;

  if (!put_offset_change_callback_.is_null())
    put_offset_change_callback_.Run();
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/service/command_buffer_service.cc中。

参数表示put_offset表示最新写入的GPU命令在Command Buffer中的位置。CommandBufferService类的成员函数Flush首先将这个位置记录在成员变量put_offset_中。

CommandBufferService类的成员函数Flush接下来又会检查成员变量put_offset_change_callback_是否指向了一个Callback。如果指向了一个Callback，那么就会调用它所绑定的函数来执行GPU命令。

从前面的分析可以知道，CommandBufferService类的成员变量put_offset_change_callback_指向了一个Callback。这个Callback绑定的函数为InProcessCommandBuffer类的成员函数PumpCommands。因此，接下来InProcessCommandBuffer类的成员函数PumpCommands会被调用。在调用期间，就会执行前面写入在Command Buffer中的GPU命令，如下所示：

void InProcessCommandBuffer::PumpCommands() {
  ......

  gpu_scheduler_->PutChanged();
}

这个函数定义在文件external/chromium_org/gpu/command_buffer/service/in_process_command_buffer.cc中。

从前面的分析可以知道，InProcessCommandBuffer类的成员变量gpu_scheduler_描述的是一个Gpu Scheduler。InProcessCommandBuffer类的成员函数PumpCommands调用这个Gpu Scheduler的成员函数PutChanged，用来通知它Command Buffer有新的GPU命令需要处理。这个Gpu Scheduler获得这个通知后，就会从Command Buffer中读出新写入的GPU命令，并且调用相应的OpenGL函数进行处理。这个处理过程可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

这样，我们就以Render端使用GPU光栅化网页UI的情景为例，分析了Android WebView的Render端执行GPU命令的过程。其它的情景，Render端也是通过In-Process Command Buffer GL接口请求App的Render Thread来执行GPU命令。

最后，我们分析Android WebView为Browser端创建In-Process Command Buffer GL接口的过程。有了In-Process Command Buffer GL接口之后，Browser端就可以像Render端一样，在App的Render Thread中执行GPU命令了。

Android WebView的Browser端的主要任务是将网页的UI合成在屏幕中。为了完成这个任务，Browser端会创建一个Hardware Renderer。Hardware Renderer又会为Browser端创建一个CC Layer Tree，目的是为了可以使用Chromium的CC模块来完成合成网页UI的任务。

Hardware Renderer会将它为Browser端创建的CC Layer Tree绘制在一个Parent Output Surface上。这个Parent Output Surface内部封装了一个In-Process Command Buffer GL接口。以后Chromium的CC模块就会通过这个In-Process Command Buffer GL接口合成网页的UI。

接下来，我们就从Browser端创建Hardware Renderer的过程开始，分析Browser端用来合成网页UI的In-Process Command Buffer GL接口的创建过程。

前面分析，App的Render Thread在AwContents类的成员函数DrawGL时提到，当App的Render Thread的处于AwDrawGLInfo::kModeDraw状态时，会检查Android WebView的Browser端是否已经创建了一个Hardware Renderer。如果还没有创建，那么就会进行创建。创建过程如下所示：

HardwareRenderer::HardwareRenderer(SharedRendererState* state)
    : ......,
      root_layer_(cc::Layer::Create()),
      ...... {
  ......

  layer_tree_host_ =
      cc::LayerTreeHost::CreateSingleThreaded(this, this, NULL, settings);
  layer_tree_host_->SetRootLayer(root_layer_);
  ......
}

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

HardwareRenderer类的构造函数主要就是为Browser端创建一个LayerTreeHost对象，并且保存成员变量layer_tree_host_中。这个LayerTreeHost对象描述的就是一个CC Layer Tree。这个CC Layer Tree是通过调用LayerTreeHost类的静态成员函数CreateSingleThreaded创建的，并且会将这个CC Layer Tree的Client指定为当前正在创建的Hardware Renderer，如下所示：

scoped_ptr<LayerTreeHost> LayerTreeHost::CreateSingleThreaded(
    LayerTreeHostClient* client,
    LayerTreeHostSingleThreadClient* single_thread_client,
    SharedBitmapManager* manager,
    const LayerTreeSettings& settings) {
  scoped_ptr<LayerTreeHost> layer_tree_host(
      new LayerTreeHost(client, manager, settings));
  layer_tree_host->InitializeSingleThreaded(single_thread_client);
  return layer_tree_host.Pass();
}

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

LayerTreeHost类的静态成员函数CreateSingleThreaded首先是创建了一个LayerTreeHost对象。这个LayerTreeHost对象描述的就是一个CC Layer Tree，它的创建过程如下所示：

LayerTreeHost::LayerTreeHost(LayerTreeHostClient* client,
                             SharedBitmapManager* manager,
                             const LayerTreeSettings& settings)
    : ......,
      client_(client),
      ...... {
  ......
}

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

LayerTreeHost类的构造函数主要是将参数client描述的一个HardwareRenderer对象保存成员变量client_中，作为当前正在创建的CC Layer Tree的Client。以后当前正在创建的CC Layer Tree将会通过这个Client为自己创建一个Output Surface。

回到前面分析的LayerTreeHost类的静态成员函数CreateSingleThreaded中，它接下来又会调用前面创建的LayerTreeHost对象的成员函数InitializeSingleThreaded，用来执行初始化工作，如下所示：

void LayerTreeHost::InitializeSingleThreaded(
    LayerTreeHostSingleThreadClient* single_thread_client) {
  InitializeProxy(SingleThreadProxy::Create(this, single_thread_client));
}

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

LayerTreeHost类的成员函数InitializeSingleThreaded首先是调用SingleThreadProxy类的静态成员函数Create创建了一个SingleThreadProxy对象，如下所示：

scoped_ptr<Proxy> SingleThreadProxy::Create(
    LayerTreeHost* layer_tree_host,
    LayerTreeHostSingleThreadClient* client) {
  return make_scoped_ptr(
      new SingleThreadProxy(layer_tree_host, client)).PassAs<Proxy>();
}

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

从这里可以看到，SingleThreadProxy类的静态成员函数Create创建的是一个SingleThreadProxy对象。这个SingleThreadProxy对象在创建的过程中，会将参数layer_tree_host指向的一个LayerTreeHost对象保存在自己的成员变量layer_tree_host_中，如下所示：

SingleThreadProxy::SingleThreadProxy(LayerTreeHost* layer_tree_host,
                                     LayerTreeHostSingleThreadClient* client)
    : Proxy(NULL),
      layer_tree_host_(layer_tree_host),
      ...... {
  ......
}

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

回到前面分析的LayerTreeHost类的成员函数InitializeSingleThreaded中，它获得了一个SingleThreadProxy对象之后，就会调用另外一个成员函数InitializeProxy对该SingleThreadProxy进行初始化，如下所示：

void LayerTreeHost::InitializeProxy(scoped_ptr<Proxy> proxy) {
  ......

  proxy_ = proxy.Pass();
  proxy_->Start();
}

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

LayerTreeHost类的成员函数InitializeProxy首先将参数proxy指向的一个SingleThreadProxy对象保存在成员变量proxy_中，然后再调用这个SingleThreadProxy对象的成员函数
Start创建一个LayerTreeHostImpl对象，如下所示：

void SingleThreadProxy::Start() {
  ......
  layer_tree_host_impl_ = layer_tree_host_->CreateLayerTreeHostImpl(this);
}

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

从前面的分析可以知道，SingleThreadProxy类的成员变量layer_tree_host_指向的是一个LayerTreeHost对象。SingleThreadProxy类的成员函数
Start调用这个LayerTreeHost对象的成员函数CreateLayerTreeHostImpl创建了一个LayerTreeHostImpl对象，并且保存在成员变量layer_tree_host_impl_。

从前面的分析就可以知道，Hardware Renderer在为Browser端创建CC Layer Tree的过程中，一共创建了LayerTreeHost、SingleThreadProxy和LayerTreeHostImpl三个对象。这三个对象一起描述了一个CC Layer Tree。

从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章可以知道，Render端的CC Layer Tree是通过调用LayerTreeHost类的静态成员函数CreateThreaded创建的。在创建的过程中，同样会创建一个LayerTreeHost对象和一个LayerTreeHostImpl对象。不过，它不会创建一个SingleThreadProxy对象，而是一个ThreadProxy对象。这三个对象同样是描述了一个CC Layer Tree。

ThreadProxy类和SingleThreadProxy类都是从Proxy类继承下来的。它们的最大区别在于前者描述的CC Layer Tree在绘制的过程中，会使用到两个线程。一个称为Main线程，另一个称为Compositor线程。这两个线程通过一个CC调度器进行协作，完成绘制网页UI的任务。后者描述的CC Layer Tree在绘制的过程中，只会使用一个线程，因此它不需要使用到CC调度器。

从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章可以知道，对于复杂的UI来说，使用两个线程绘制效率会更高。不过，对Android WebView的Browser端来说，它的UI结构是非常简单的（CC Layer Tree只包含两个节点），因此，它就不需要使用两个线程来绘制了。

回到前面分析的HardwareRenderer类的构造函数中，它除了为Browser端创建一个CC Layer Tree，还会调用Layer类的静态成员函数Create0创建一个CC Layer。这个CC Layer就作为Browser端的CC Layer Tree的根节点。

确保Android WebView的Browser端已经具有一个Hardware Renderer之后，前面分析的AwContents类的成员函数DrawGL就会调用这个Hardware Renderer的成员函数DrawGL来合成网页的UI，如下所示：

void HardwareRenderer::DrawGL(bool stencil_enabled,
                              int framebuffer_binding_ext,
                              AwDrawGLInfo* draw_info) {
  ......

  {
    ......
    layer_tree_host_->Composite(gfx::FrameTime::Now());
  }
  
  ......
}

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

从前面的分析可以知道，HardwareRenderer类的成员变量layer_tree_host_指向的是一个LayerTreeHost对象。HardwareRenderer类的成员函数DrawGL调用这个LayerTreeHost对象的成员函数Composite合成网页的UI，如下所示：

void LayerTreeHost::Composite(base::TimeTicks frame_begin_time) {
  ......
  SingleThreadProxy* proxy = static_cast<SingleThreadProxy*>(proxy_.get());

  if (output_surface_lost_)
    proxy->CreateAndInitializeOutputSurface();
  ......

  proxy->CompositeImmediately(frame_begin_time);
}

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

LayerTreeHost类的成员变量output_surface_lost_是一个布尔变量。当它的值等于true的时候，就表示CC模块还没有为当前正在处理的LayerTreeHost对象描述的CC Layer Tree创建过Output Surface，或者以前创建过，但是现在失效了。在这种情况下，LayerTreeHost类的成员函数Composite合成网页UI之前，先创建创建一个Output Surface。

从前面的分析可以知道，LayerTreeHost类的成员变量proxy_指向的是一个SingleThreadProxy对象。LayerTreeHost类的成员函数Composite就是通过调用这个SingleThreadProxy对象的成员函数CreateAndInitializeOutputSurface为当前正在处理的LayerTreeHost对象描述的CC Layer Tree创建Output Surface的。

有了Output Surface之后，LayerTreeHost类的成员函数Composite再调用上述SingleThreadProxy对象的成员函数CompositeImmediately合成网页的UI。这个过程我们在接下来一篇文章中再详细分析。

接下来，我们继续分析SingleThreadProxy类的成员函数CreateAndInitializeOutputSurface为Browser端的CC Layer Tree创建Output Surface的过程。在创建的过程中，就会创建一个In-Process Command Buffer GL接口，如下所示：

void SingleThreadProxy::CreateAndInitializeOutputSurface() {
  ......

  scoped_ptr<OutputSurface> output_surface =
      layer_tree_host_->CreateOutputSurface();

  ......
}

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

从前面的分析可以知道，SingleThreadProxy类的成员变量layer_tree_host_指向的是一个LayerTreeHost对象。SingleThreadProxy类的成员函数CreateAndInitializeOutputSurface调用这个LayerTreeHost对象的成员函数CreateOutputSurface为Browser端的CC Layer Tree创建一个Output Surface，如下所示：

scoped_ptr<OutputSurface> LayerTreeHost::CreateOutputSurface() {
  return client_->CreateOutputSurface(num_failed_recreate_attempts_ >= 4);
}

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

从前面的分析可以知道，LayerTreeHost类的成员变量client_指向的是一个HardwareRenderer对象。LayerTreeHost类的成员函数CreateOutputSurfaceBrowser调用这个HardwareRenderer对象的成员函数CreateOutputSurface为Browser端的CC Layer Tree创建一个Output Surface，如下所示：

scoped_ptr<cc::OutputSurface> HardwareRenderer::CreateOutputSurface(
    bool fallback) {
  ......

  scoped_refptr<cc::ContextProvider> context_provider =
      CreateContext(gl_surface_,
                    DeferredGpuCommandService::GetInstance(),
                    shared_renderer_state_->GetSharedContext());
  scoped_ptr<ParentOutputSurface> output_surface_holder(
      new ParentOutputSurface(context_provider));
  output_surface_ = output_surface_holder.get();
  return output_surface_holder.PassAs<cc::OutputSurface>();
}

这个函数定义在文件external/chromium_org/android_webview/browser/hardware_renderer.cc。

HardwareRenderer类的成员函数CreateOutputSurface为Browser端的CC Layer Tree创建的是一个Parent Output Surface。相应地，Render端的CC Layer Tree使用的Synchronous Compositor Output Surface也称为Child Output Surface。之所以将Render端的CC Layer Tree的Output Surface称为Child，而将Browser端的CC Layer Tree创建的是一个Parent，是因为Render端的CC Layer Tree的绘制结果会输出为Browser端的CC Layer Tree的一个节点的内容。这一点我们在接下来一篇文章分析Android WebView渲染网页UI的过程就会清楚地看到。

HardwareRenderer类的成员函数CreateOutputSurface在为Browser端的CC Layer Tree创建Parent Output Surface的时候，需要用到一个ContextProvider对象。这个ContextProvider对象是通过调用函数CreateContext创建的，如下所示：

scoped_refptr<cc::ContextProvider> CreateContext(
    scoped_refptr<gfx::GLSurface> surface,
    scoped_refptr<gpu::InProcessCommandBuffer::Service> service,
    gpu::GLInProcessContext* share_context) {
  ......

  scoped_ptr<gpu::GLInProcessContext> context(
      gpu::GLInProcessContext::Create(service,
                                      surface,
                                      surface->IsOffscreen(),
                                      gfx::kNullAcceleratedWidget,
                                      surface->GetSize(),
                                      share_context,
                                      false /* share_resources */,
                                      in_process_attribs,
                                      gpu_preference));
  ......

  return webkit::gpu::ContextProviderInProcess::Create(
      WebGraphicsContext3DInProcessCommandBufferImpl::WrapContext(
          context.Pass(), attributes),
      "Parent-Compositor");
}

这个函数定义在文件external/chromium_org/android_webview/browser/hardware_renderer.cc。

函数ContextProvider首先是调用GLInProcessContext类的静态成员函数Create创建了一个In-Process Command Buffer GL接口。

上述In-Process Command Buffer GL接口又会通过WebGraphicsContext3DInProcessCommandBufferImpl类的静态成员函数WrapContext封装在一个WebGraphicsContext3DInProcessCommandBufferImpl对象中。

最后，前面得到的WebGraphicsContext3DInProcessCommandBufferImpl对象又会通过ContextProviderInProcess类的静态成员函数Create封装在一个ContextProviderInProcess对象中返回给调用者。调用者有了这个ContextProviderInProcess对象之后，就可以创建一个Output Surface了。

GLInProcessContext类的静态成员函数Create、WebGraphicsContext3DInProcessCommandBufferImpl类的静态成员函数WrapContext和ContextProviderInProcess类的静态成员函数Create的实现，前面在分析Render端的CC Layer Tree使用的Synchronous Compositor Output Surface的创建过程时，已经分析过了，这里就不再复述。

这样，我们就可以知道，Browser端的CC Layer Tree使用的Output Surface里面包含了一个In-Process Command Buffer GL接口。CC模块在绘制Browser端的CC Layer Tree时，就会通过这个In-Process Command Buffer GL接口来执行GPU命令。这与我们前面分析的Render端执行GPU命令的过程是一致的。

至此，我们就分析了Android WebView为Render端和Browser端创建In-Process Command Buffer GL接口的过程，并且以Render端光栅化网页UI的情景为例，分析了Render端通过In-Process Command Buffer GL接口请求App的Render Thread执行GPU命令的过程。Browser端执行GPU命令的过程与Render端也是类似的。一旦Render端和Browser可以执行GPU命令，它们就可以使用硬件加速的方式渲染网页的UI。在接下来一篇文章中，我们就详细分析Android WebView使用硬件加速方式渲染网页UI的过程。敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/12/12 1:05:00 原文链接

阅读：34679 评论：6 查看评论

↧

Android WebView硬件加速渲染网页UI的过程分析

December 19, 2016, 12:58 am

≫ Next: 《Android系统源代码情景分析》连载回忆录：灵感之源

≪ Previous: Android WebView执行GPU命令的过程分析

Android WebView作为App UI的一部分，当App UI以硬件加速方式渲染时，它也是以硬件加速方式渲染的。Android WebView的UI来自于网页，是通过Chromium渲染的。Chromium渲染网页UI的机制与Android App渲染UI的机制是不一样的。不过，它们会一起协作完成网页UI的渲染。本文接下来就详细分析Android WebView硬件加速渲染网页UI的过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

从前面Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章可以知道，Android App在渲染UI一帧的过程中，经历以下三个阶段：

1. 在UI线程中构建一个Display List，这个Display List包含了每一个View的绘制命令。

2. 将前面构建的Display List同步给Render Thread。

3. Render Thread对同步得到的Display List进行渲染，也就是使用GPU执行Display List的绘制命令。

上述三个阶段如果能够在16ms内完成，那么App的UI给用户的感受就是流畅的。为了尽量地在16ms内渲染完成App的一帧UI，Android使用了以上方式对App的UI进行渲染。这种渲染机制的好处是UI线程和Render Thread可以并发执行，也就是Render Thread在渲染当前帧的Display List的时候，UI线程可以准备下一帧的Display List。它们唯一需要同步的地方发生第二阶段。不过，这个阶段是可以很快完成的。因此，UI线程和Render Thread可以认为是并发执行的。

Android WebView既然是App UI的一部分，也就是其中的一个View，它的渲染也是按照上述三个阶段进行的，如下所示：

图1 Android WebView硬件加速渲染网页UI的过程

在第一阶段，Android WebView会对Render端的CC Layer Tree进行绘制。这个CC Layer Tree描述的就是网页的UI，它会通过一个Synchronous Compositor绘制在一个Synchronous Compositor Output Surface上，最终得到一个Compositor Frame。这个Compositor Frame会保存在一个SharedRendererState对象中。

在第二阶段，保存在上述SharedRendererState对象中的Compositor Frame会同步给Android WebView会对Browser端的CC Layer Tree。Browser端的CC Layer Tree只有两个节点。一个是根节点，另一个是根节点的子节点，称为一个Delegated Renderer Layer。Render端绘制出来的Compositor Frame就是作为这个Delegated Renderer Layer的输入的。

在第三阶段，Android WebView会通过一个Hardware Renderer将Browser端的CC Layer Tree渲染在一个Parent Output Surface上，实际上就是通过GPU命令将Render端绘制出来的UI合成显示在App的UI窗口中。

接下来，我们就按照以上三个阶段分析Android WebView硬件加速渲染网页UI的过程。

从前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文可以知道，在App渲染UI的第一阶段，Android WebView的成员函数onDraw会被调用。从前面Android WebView执行GPU命令的过程分析一文又可以知道，Android WebView在Native层有一个BrowserViewRenderer对象。当Android WebView的成员函数onDraw被调用时，并且App的UI以硬件加速方式渲染时，这个Native层BrowserViewRenderer对象的成员函数OnDrawHardware会被调用，如下所示：

bool BrowserViewRenderer::OnDrawHardware(jobject java_canvas) {   
  ......  
  
  scoped_ptr<DrawGLInput> draw_gl_input(new DrawGLInput);  
  ......  
  
  scoped_ptr<cc::CompositorFrame> frame =  
      compositor_->DemandDrawHw(surface_size,  
                                gfx::Transform(),  
                                viewport,  
                                clip,  
                                viewport_rect_for_tile_priority,  
                                transform_for_tile_priority);  
  ......  

  frame->AssignTo(&draw_gl_input->frame);
  ......
  shared_renderer_state_->SetDrawGLInput(draw_gl_input.Pass()); 
 
  ......  
  return client_->RequestDrawGL(java_canvas, false);  
}

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

从前面Android WebView执行GPU命令的过程分析一文可以知道，BrowserViewRenderer类的成员变量compositor_指向的是一个SynchronousCompositorImpl对象。BrowserViewRenderer对象的成员函数OnDrawHardware会调用这个SynchronousCompositorImpl对象的成员函数DemandDrawHw对网页的UI进行绘制。

绘制的结果是得到一个Compositor Frame。这个Compositor Frame会保存在一个DrawGLInput对象中。这个DrawGLInput对象又会保存在BrowserViewRenderer类的成员变量shared_renderer_state_指向的一个SharedRendererState对象中。这是通过调用SharedRendererState类的成员函数SetDrawGLInput实现的。

BrowserViewRenderer类的成员变量client_指向的是一个AwContents对象。BrowserViewRenderer对象的成员函数OnDrawHardware最后会调用这个AwContents对象的成员函数RequestDrawGL请求在参数java_canvas描述的一个Hardware Canvas中增加一个DrawFunctorOp操作。这个DrawFunctorOp操作最终会包含在App的UI线程构建的Display List中。

接下来，我们首先分析SynchronousCompositorImpl类的成员函数DemandDrawHw绘制网页的UI的过程，如下所示：

scoped_ptr<cc::CompositorFrame> SynchronousCompositorImpl::DemandDrawHw(
    gfx::Size surface_size,
    const gfx::Transform& transform,
    gfx::Rect viewport,
    gfx::Rect clip,
    gfx::Rect viewport_rect_for_tile_priority,
    const gfx::Transform& transform_for_tile_priority) {
  ......

  scoped_ptr<cc::CompositorFrame> frame =
      output_surface_->DemandDrawHw(surface_size,
                                    transform,
                                    viewport,
                                    clip,
                                    viewport_rect_for_tile_priority,
                                    transform_for_tile_priority);
  ......
  return frame.Pass();
}

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

从前面Android WebView执行GPU命令的过程分析一文可以知道，SynchronousCompositorImpl类的成员变量output_surface_指向的是一个SynchronousCompositorOutputSurface对象。SynchronousCompositorImpl类的成员函数DemandDrawHw调用这个SynchronousCompositorOutputSurface对象的成员函数DemandDrawHw绘制网页的UI，如下所示：

scoped_ptr<cc::CompositorFrame>
SynchronousCompositorOutputSurface::DemandDrawHw(
    gfx::Size surface_size,
    const gfx::Transform& transform,
    gfx::Rect viewport,
    gfx::Rect clip,
    gfx::Rect viewport_rect_for_tile_priority,
    const gfx::Transform& transform_for_tile_priority) {
  ......

  InvokeComposite(transform,
                  viewport,
                  clip,
                  viewport_rect_for_tile_priority,
                  transform_for_tile_priority,
                  true);

  return frame_holder_.Pass();
}

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

SynchronousCompositorOutputSurface类的成员函数DemandDrawHw调用另外一个成员函数InvokeComposite绘制网页的UI。绘制完成后，就会得到一个Compositor Frame。这个Compositor Frame保存在SynchronousCompositorOutputSurface类的成员变量frame_holder_中。因此，SynchronousCompositorOutputSurface类的成员函数DemandDrawHw可以将这个成员变量frame_holder_指向的Compositor Frame返回给调用者。

SynchronousCompositorOutputSurface类的成员函数InvokeComposite的实现如下所示：

void SynchronousCompositorOutputSurface::InvokeComposite(
    const gfx::Transform& transform,
    gfx::Rect viewport,
    gfx::Rect clip,
    gfx::Rect viewport_rect_for_tile_priority,
    gfx::Transform transform_for_tile_priority,
    bool hardware_draw) {
  ......

  client_->BeginFrame(cc::BeginFrameArgs::CreateForSynchronousCompositor());

  ......
}

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

SynchronousCompositorOutputSurface类的成员变量client_是从父类OutputSurface继承下来的。从前面Chromium网页绘图表面（Output Surface）创建过程分析一文可以知道，它指向的是一个LayerTreeHostImpl对象。SynchronousCompositorOutputSurface类的成员函数InvokeComposite调用这个LayerTreeHostImpl对象的成员函数BeginFrame绘制网页的UI。

从前面Chromium网页渲染调度器（Scheduler）实现分析一文可以知道，当LayerTreeHostImpl类的成员函数BeginFrame被调用时，它就会CC模块的调度器执行一个BEGIN_IMPL_FRAME操作，也就是对网页的CC Layer Tree进行绘制。绘制的过程可以参考Chromium网页Layer Tree绘制过程分析、Chromium网页Layer Tree同步为Pending Layer Tree的过程分析和Chromium网页Pending Layer Tree激活为Active Layer Tree的过程分析这三篇文章。

由于Android WebView的Render端使用的是Synchronous Compositor，当前线程（也就是App的UI线程）会等待Render端的Compositor线程绘制完成网页的CC Layer Tree。从前面Chromium硬件加速渲染的UI合成过程分析一文可以知道，Compositor线程在绘制完成网页的CC Layer Tree的时候，会调用网页的Output Surface的成员函数SwapBuffers。

在我们这个情景中，网页的Output Surface是一个Synchronous Compositor Output Surface。这意味着当Compositor线程在绘制完成网页的CC Layer Tree时，会调用SynchronousCompositorOutputSurface类的成员函数SwapBuffers，如下所示：

void SynchronousCompositorOutputSurface::SwapBuffers(
    cc::CompositorFrame* frame) {
  ......

  frame_holder_.reset(new cc::CompositorFrame);
  frame->AssignTo(frame_holder_.get());

  ......
}

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

参数frame指向的Compositor Frame描述的就是网页的绘制结果。从前面Chromium硬件加速渲染的UI合成过程分析一文可以知道，这个Compositor Frame包含了一系列的Render Pass。每一个Render Pass都包含了若干个纹理，以及每一个纹理的绘制参数。这些纹理是在Render端光栅化网页时产生的。Browser端的Hardware Renderer所要做的事情就是将这些纹理渲染在屏幕上。这个过程也就是Browser端合成网页UI的过程。

SynchronousCompositorOutputSurface类的成员函数SwapBuffers会将参数frame描述的Compositor Frame的内容拷贝一份到一个新创建的Compositor Frame中去。这个新创建的Compositor Frame会保存在SynchronousCompositorOutputSurface类的成员变量frame_hodler_中。因此，前面分析的SynchronousCompositorOutputSurface类的成员函数InvokeComposite返回给调用者的就是当前绘制的网页的内容。

这一步执行完成后，回到前面分析的BrowserViewRenderer类的成员函数OnDrawHardware中，这时候它就获得了一个Render端绘制网页的结果，也就是一个Compositor Frame。这个Compositor Frame会保存在一个DrawGLInput对象中。这个DrawGLInput对象又会保存在BrowserViewRenderer类的成员变量shared_renderer_state_指向的一个SharedRendererState对象中。这是通过调用SharedRendererState类的成员函数SetDrawGLInput实现的，如下所示：

void SharedRendererState::SetDrawGLInput(scoped_ptr<DrawGLInput> input) {
  ......
  draw_gl_input_ = input.Pass();
}

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

SharedRendererState类的成员函数SetDrawGLInput将参数input指向的一个DrawGLInput对象保存成员变量draw_gl_input_中。

这一步执行完成后，再回到前面分析的BrowserViewRenderer类的成员函数OnDrawHardware中，接下来它会调用成员变量client_指向的一个Native层AwContents对象的成员函数RequestDrawGL请求在参数java_canvas描述的一个Hardware Canvas中增加一个DrawFunctorOp操作，如下所示：

bool AwContents::RequestDrawGL(jobject canvas, bool wait_for_completion) {
  ......

  JNIEnv* env = AttachCurrentThread();
  ScopedJavaLocalRef<jobject> obj = java_ref_.get(env);
  if (obj.is_null())
    return false;
  return Java_AwContents_requestDrawGL(
      env, obj.obj(), canvas, wait_for_completion);
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

在前面Android WebView执行GPU命令的过程分析一文中，我们已经分析过Native层AwContents类的成员函数RequestDrawGL的实现了，它主要就是调用Java层的AwContents类的成员函数requestDrawGL请求在参数canvas描述的Hardware Canvas中增加一个DrawFunctorOp操作。

Java层的AwContents类的成员函数requestDrawGL最终会调用到DrawGLFunctor类的成员函数requestDrawGL在参数canvas描述的Hardware Canvas中增加一个DrawFunctorOp操作，如下所示：

class DrawGLFunctor {
    ......

    public boolean requestDrawGL(HardwareCanvas canvas, ViewRootImpl viewRootImpl,
            boolean waitForCompletion) {
        ......

        if (canvas == null) {
            viewRootImpl.invokeFunctor(mDestroyRunnable.mNativeDrawGLFunctor, waitForCompletion);
            return true;
        }

        canvas.callDrawGLFunction(mDestroyRunnable.mNativeDrawGLFunctor);
        ......

        return true;
    }

    ......
}

这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/DrawGLFunctor.java中。

在前面Android WebView执行GPU命令的过程分析一文中，DrawGLFunctor类的成员函数requestDrawGL是在Render端光栅化网页UI的过程中调用的。这时候参数canvas的值等于null，因此DrawGLFunctor类的成员函数requestDrawGL会通过调用参数viewRootImpl指向的一个ViewRootImpl对象的成员函数invokeFunctor直接请求App的Render Thread执行GPU命令。

现在，当DrawGLFunctor类的成员函数requestDrawGL被调用时，它的参数canvas的值不等于null，指向了一个Hardware Canvas。在这种情况下，DrawGLFunctor类的成员函数requestDrawGL将会调用这个Hardware Canvas的成员函数callDrawGLFunction，将一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作，写入到它描述一个Display List中去。

被封装的Native层DrawGLFunctor对象，保存在Java层DrawGLFunctor类的成员变量mDestroyRunnable指向的一个DestroyRunnable对象的成员变量mNativeDrawGLFunctor中。这一点可以参考前面Android WebView执行GPU命令的过程分析一文。

从前面Android应用程序UI硬件加速渲染的Display List渲染过程分析一文可以知道，参数canvas描述的Hardware Canvas是通过一个GLES20Canvas对象描述的，因此接下来它的成员函数callDrawGLFunction会被调用，用来将一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作写入它描述一个Display List中去，如下所示：

class GLES20Canvas extends HardwareCanvas {
    ......

    @Override
    public int callDrawGLFunction(long drawGLFunction) {
        return nCallDrawGLFunction(mRenderer, drawGLFunction);
    }

    ......
}

这个函数定义在文件frameworks/base/core/java/android/view/GLES20Canvas.java中。

GLES20Canvas类的成员函数callDrawGLFunction调用另外一个成员函数nCallDrawGLFunction将参数drawGLFunction描述的一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作写入到当前正在处理的GLES20Canvas对象描述一个Display List中去。

GLES20Canvas类的成员函数nCallDrawGLFunction是一个JNI方法，它由C++层的函数android_view_GLES20Canvas_callDrawGLFunction实现，如下所示：

static jint android_view_GLES20Canvas_callDrawGLFunction(JNIEnv* env, jobject clazz,
        jlong rendererPtr, jlong functorPtr) {
    DisplayListRenderer* renderer = reinterpret_cast<DisplayListRenderer*>(rendererPtr);
    Functor* functor = reinterpret_cast<Functor*>(functorPtr);
    android::uirenderer::Rect dirty;
    return renderer->callDrawGLFunction(functor, dirty);
}

这个函数定义在文件frameworks/base/core/jni/android_view_GLES20Canvas.cpp中。

参数rendererPtr描述的是一个Native层的DisplayListRenderer对象。这个DisplayListRenderer对象负责构造App UI的Display List。函数android_view_GLES20Canvas_callDrawGLFunction所做的事情就是调用这个DisplayListRenderer对象的成员函数callDrawFunction将参数functionPtr描述的一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作写入到App UI的Display List中去，如下所示：

status_t DisplayListRenderer::callDrawGLFunction(Functor *functor, Rect& dirty) {
    // Ignore dirty during recording, it matters only when we replay
    addDrawOp(new (alloc()) DrawFunctorOp(functor));
    mDisplayListData->functors.add(functor);
    return DrawGlInfo::kStatusDone; // No invalidate needed at record-time
}

这个函数定义在文件frameworks/base/libs/hwui/DisplayListRenderer.cpp中。

DisplayListRenderer类的成员变量mDisplayListData指向的是一个DisplayListData对象。这个DisplayListData对象描述的就是App UI的Display List。因此，DisplayListRenderer对象的成员函数callDrawFunction就会将参数functor描述的一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作写入到它里面去。

这一步执行完成后，Android WebView就在App渲染一个帧的第一个阶段通知Render端绘制完成了网页的UI，并且往App UI的Display List写入了一个DrawFunctorOp操作。在第二阶段，App UI的Display List就会从App的UI线程同步给App的Render Thread。从前面Android应用程序UI硬件加速渲染的Display List渲染过程分析一文可以知道，在同步的过程中，RenderNode类的成员函数pushStagingDisplayListChanges地被调用，如下所示：

void RenderNode::pushStagingDisplayListChanges(TreeInfo& info) {
    if (mNeedsDisplayListDataSync) {
        mNeedsDisplayListDataSync = false;
        ......
        if (mDisplayListData) {
            for (size_t i = 0; i < mDisplayListData->functors.size(); i++) {
                (*mDisplayListData->functors[i])(DrawGlInfo::kModeSync, NULL);
            }
        }
        ......
    }
}

这个函数定义在文件frameworks/base/libs/hwui/RenderNode.cpp中。

这时候包含在App UI的Display List中的每一个DrawFunctorOp操作关联的Native层DrawGLFunctor对象的重载操作符函数()都会被调用，目的是让它执行一些同步操作。在我们这个情景中，就是将Render端绘制出来的UI同步到给Browser端。

在前面Android WebView执行GPU命令的过程分析一文中，我们已经分析过Native层DrawGLFunctor对象的重载操作符函数()的实现了，它最终会调用到Native层的AwContents类DrawGL将Render端绘制出来的UI同步到给Browser端，如下所示：

void AwContents::DrawGL(AwDrawGLInfo* draw_info) {
  if (draw_info->mode == AwDrawGLInfo::kModeSync) {
    if (hardware_renderer_)
      hardware_renderer_->CommitFrame();
    return;
  }

  ......
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

这时候App的Render Thread处于AwDrawGLInfo::kModeSync状态，因此AwContents类的成员函数DrawGL接下来将会调用成员变量hardware_renderer_指向的一个HardwareRenderer对象的成员函数CommitFrame将Render端绘制出来的UI同步到给Browser端，如下所示：

void HardwareRenderer::CommitFrame() {
  scoped_ptr<DrawGLInput> input = shared_renderer_state_->PassDrawGLInput();
  ......

  if (!frame_provider_ || size_changed) {
    ......

    frame_provider_ = new cc::DelegatedFrameProvider(
        resource_collection_.get(), input->frame.delegated_frame_data.Pass());

    delegated_layer_ = cc::DelegatedRendererLayer::Create(frame_provider_);
    ......

    root_layer_->AddChild(delegated_layer_);
  } else {
    frame_provider_->SetFrameData(input->frame.delegated_frame_data.Pass());
  }
}

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

从前面的分析可以知道，Render端在第一阶段已经将绘制出来的网页UI，保存在一个DrawGLInput对象中。这个DrawGLInput又保存在一个SharedRendererState对象中。HardwareRenderer类的成员变量shared_renderer_state_描述的就是这个SharedRendererState对象。因此，HardwareRenderer类的成员函数CommitFrame可以通过调用这个SharedRendererState对象的成员函数PassDrawGLInput获得保存在它内部的DrawGLInput对象，如下所示：

scoped_ptr<DrawGLInput> SharedRendererState::PassDrawGLInput() {
  base::AutoLock lock(lock_);
  return draw_gl_input_.Pass();
}

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

从前面的分析可以知道，用来描述Render端在第一阶段绘制出来的网页UI的DrawGLInput对象就保存在SharedRendererState类的成员变量draw_gl_input_中，因此SharedRendererState类的成员函数PassDrawGLInput就可以将这个员变量draw_gl_input_指向的DrawGLInput对象返回给调用者。

回到前面分析的HardwareRenderer类的成员函数CommitFrame中，这时候它获得了一个Render端在第一阶段绘制出来的UI，也就是一个DrawGLInput对象，接下来它就会判断之前是否已经为Browser端的CC Layer Tree创建过一个Delegated Renderer Layer。

如果还没有创建，或者以前创建过，但是现在Android WebView的大小发生了变化，那么HardwareRenderer类的成员函数CommitFrame就会创建用前面获得的DrawGLInput对象创建一个Delegated Renderer Layer，并且作为Browser端的CC Layer Tree的根节点的子节点。

另一方面，如果已经创建，并且Android WebView的大小没有发生变化，那么HardwareRenderer类的成员函数CommitFrame就会使用前面获得的DrawGLInput对象更新Delegated Renderer Layer的内容。

这一步执行完成后，Android WebView就在App渲染一个帧的第二个阶段将Render端绘制出来的网页UI同步给了Browser端。在第三阶段，Browser端就会将网页的UI合成在App的窗口中，这样就可以显示在屏幕中了。

从前面Android应用程序UI硬件加速渲染的Display List渲染过程分析一文可以知道，App的Render Thread在第三阶段会通过一个OpenGL Renderer渲染从App的UI线程同步过来的Display List，也就是执行它里面包含的渲染操作。从前面的分析可以知道，Android WebView在第一阶段往这个Display List写入了一个DrawFunctorOp操作，OpenGL Renderer会通过调用它的成员函数callDrawGLFunction执行这个操作，如下所示：

status_t OpenGLRenderer::callDrawGLFunction(Functor* functor, Rect& dirty) {
    ......

    mRenderState.invokeFunctor(functor, DrawGlInfo::kModeDraw, &info);
    ......

    return DrawGlInfo::kStatusDrew;
}

这个函数定义在文件frameworks/base/libs/hwui/OpenGLRenderer.cpp中。

参数funtor描述的就是与当前要执行的DrawFunctorOp操作关联的Native层DrawGLFunctor对象。OpenGLRenderer类的成员函数callDrawGLFunction会通过调用成员变量mRenderState指向的一个RenderState对象的成员函数invokeFunctor调用这个Native层DrawGLFunctor对象的重载操作符函数()，告知它App的Render Thread当前处于第三阶段，也就是DrawGlInfo::kModeDraw状态，它可以执行相应的GPU命令。

在前面Android WebView执行GPU命令的过程分析一文中，我们已经分析过RenderState类的成员函数invokeFunctor的实现了，它最终会调用到Native层的AwContents类DrawGL将绘制Browser端的CC Layer Tree，如下所示：

void AwContents::DrawGL(AwDrawGLInfo* draw_info) {
  if (draw_info->mode == AwDrawGLInfo::kModeSync) {
    ......
    return;
  }

  ......

  if (draw_info->mode != AwDrawGLInfo::kModeDraw) {
    ......
    return;
  }

  ......

  hardware_renderer_->DrawGL(state_restore.stencil_enabled(),
                             state_restore.framebuffer_binding_ext(),
                             draw_info);
  ......
}

这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

由于当前App的Render Thread处于AwDrawGlInfo::kModeDraw状态，因此AwContents类DrawGL会调用成员变量hardware_renderer_指向的一个HardwareRenderer对象的成员函数DrawGL，用来绘制Browser端的CC Layer Tree，如下所示：

void HardwareRenderer::DrawGL(bool stencil_enabled,
                              int framebuffer_binding_ext,
                              AwDrawGLInfo* draw_info) {
  ......

  {
    ......
    layer_tree_host_->Composite(gfx::FrameTime::Now());
  }

  ......
}

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

从前面Android WebView执行GPU命令的过程分析一文可以知道，HardwareRenderer类的成员变量layer_tree_host_指向的是一个LayerTreeHost对象。这个LayerTreeHost对象描述的就是Browser端的CC Layer Tree。HardwareRenderer类的成员函数DrawGL将会调用这个LayerTreeHost对象的成员函数Composite，以便绘制Browser端的CC Layer Tree，如下所示：

void LayerTreeHost::Composite(base::TimeTicks frame_begin_time) {
  ......
  SingleThreadProxy* proxy = static_cast<SingleThreadProxy*>(proxy_.get());

  .....

  proxy->CompositeImmediately(frame_begin_time);
}

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

从前面Android WebView执行GPU命令的过程分析一文可以知道，当前正在处理的LayerTreeHost对象的成员变量proxy_指向的是一个SingleThreadProxy对象，LayerTreeHost类的成员函数Composite调用这个SingleThreadProxy对象的成员函数CompositeImmediately绘制Browser端的CC Layer Tree，如下所示：

void SingleThreadProxy::CompositeImmediately(base::TimeTicks frame_begin_time) {
  ......

  LayerTreeHostImpl::FrameData frame;
  if (DoComposite(frame_begin_time, &frame)) {
    {
      ......
    }
    ......
  }
}

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

SingleThreadProxy类的成员函数CompositeImmediately主要是调用另外一个成员函数DoComposite绘制Browser端的CC Layer Tree，如下所示：

bool SingleThreadProxy::DoComposite(
    base::TimeTicks frame_begin_time,
    LayerTreeHostImpl::FrameData* frame) {
  ......

  bool lost_output_surface = false;
  {
    ......

    if (!layer_tree_host_impl_->IsContextLost()) {
      layer_tree_host_impl_->PrepareToDraw(frame);
      layer_tree_host_impl_->DrawLayers(frame, frame_begin_time);
      ......
    }
    
    ......
  }

  ......
}

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

从前面Android WebView执行GPU命令的过程分析一文可以知道，SingleThreadProxy类的成员变量layer_tree_host_impl_指向的是一个LayerTreeHostImpl对象。SingleThreadProxy类的成员函数DoComposite主要是调用这个LayerTreeHostImpl对象的成员函数PrepareToDraw和DrawLayers绘制Browser端的CC Layer Tree。

LayerTreeHostImpl类的成员函数PrepareToDraw和DrawLayers绘制CC Layer Tree的过程可以参考前面Chromium硬件加速渲染的UI合成过程分析一文。从前面Chromium硬件加速渲染的UI合成过程分析一文我们还可以知道，Chromium的Browser端在内部是通过一个Direct Renderer绘制CC Layer Tree的，而Render端是通过一个Delegated Renderer绘制CC Layer Tree的。Delegated Renderer并不是真的绘制CC Layer Tree，而只是将CC Layer Tree的绘制命令收集起来，放在一个Compositor Frame中。这个Compositor Frame最终会交给Browser端的Direct Renderer处理。Direct Renderer直接调用OpenGL函数执行保存在Compositor Frame的绘制命令。因此，当Browser端绘制完成自己的CC Layer Tree之后，加载在Android WebView中的网页UI就会合成显示在App的窗口中了。

至此，我们就分析完成了Android WebView硬件加速渲染网页UI的过程，也完成了对Android基于Chromium实现的WebView的学习。重新学习可以参考Android WebView简要介绍和学习计划一文。更多的学习信息可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/12/19 0:58:18 原文链接

阅读：38390 评论：5 查看评论

↧

《Android系统源代码情景分析》连载回忆录：灵感之源

January 10, 2017, 10:42 pm

≫ Next: 【MQ】ActiveMQ（二）——消息处理机制

≪ Previous: Android WebView硬件加速渲染网页UI的过程分析

上个月，在花了一年半时间之后，写了55篇文章，分析完成了Chromium在Android上的实现，以及Android基于Chromium实现的WebView。学到了很多东西，不过也挺累的，平均不到两个星期一篇文章。本来想休息一段时间后，再继续分析Chromium使用的JS引擎V8。不过某天晚上，躺在床上睡不着，鬼使神差想着去创建一个个人站点，用来连载《Android系统源代码情景分析》一书的内容。

事情是这样的，躺在床上睡不着，就去申请了一个域名，0xcc0xcd.com。域名申请到了，总不能不用吧。用来做什么呢？想起我写的那本书《Android系统源代码情景分析》，从2012年10月出版至今，也有四年多的时间了，得到了大家的厚受。不过网络上也逐渐的出现了一些盗版PDF。不用说，质量肯定很差。干脆我把这本书的内容在我的个人站点上放出来吧。后面征得了出版社的同意，就着手开始干了。

网站名称为“进击的程序员”，主要是为了配合0xcc0xcd.com这个域名。从Windows时代过来的老司机可能一眼就能看出这个域名是什么意思。看不懂的，如果大家有兴趣，后面我也可以详细说说，怀念一下逝去的青春。

从开始有想法，到把网站建好，以及将书前三章（准备知识、硬件抽象层、智能指针）的内容放上去，花了不到一个月的时间。在这不到一个月的时间里，学习到了挺多东西：申请域名、云服务器、域名解析、域名邮箱、网站备案以及开发网站等等。因为我一直都是做客户端开发，刚毕业几年做的是Windows客户端，后面做的是Android端，没有做过网站相关的开发，包含前端和后端，所以学习过程还是有些小波折。不过总体上来说还是比较顺利的。这也跟网站的技术选型有关吧。

现在不是提倡做全栈工程师吗？这个建站过程也算是小小地实践了一把。怕时间久了会忘记一些关键细节和踩过的坑，所以就计划把建站连载书的过程记录下来。也希望能够帮助到有兴趣做全栈工程师的同学们。

网站使用的是LNMP架构，如下图1所示：

图1 进击的程序员网站架构

网站运行在云服务器上，系统装的是Ubuntu 14.04，除了Nginx、PHP和MySQL，还搭了一个GIT仓库，用来管理网站源码。这个GIT仓库除了用来管理网站源码，还用来将源码分布到网站中去。

具体是这样的，在本地用自己的电脑开发网站（其实就是用vim编辑网页和PHP）。测试没有问题之后，就用git push命令将源码上传到GIT仓库。然后再登录到云服务器上，在网站根目录用git pull命令从GIT仓库中获得最新网站源码。

此外，在本地还搭建了一个管理后台。这个管理后台就是用来给管理员管理网站的。主要就是操作一下数据库，例如查看数据、插入数据、更新数据等等。正规的网站会专门提供一些页面供管理员操作。鉴于这个网站不是很正规，管理员又是一个技术控，于是就直接使用Python脚本来实现这个管理后台了，想要什么功能就直接写个脚本。

Oracle提供了一个Python版的MySQL数据库驱动库MySQL Connector/Python，通过它很容易用Python脚本操作MySQL中的数据。这样一个简单的管理后台就搭建起来了。

整个网站的架构非常简单，可以非常快上手，同时它又五脏俱全。网站的前端主要用Ajax、jQuery开发，后端没有用什么高大尚的框架，基本上是徒手写的PHP。主要是考虑这个网站要做的事情很简单，就是连载《Android系统源代码情景分析》的内容，基本功能就是浏览和评论。所以就以最简单最快的方式实现。

为了让大家利用碎片时间更好地阅读书的内容，网站在提供PC版的同时，也提供了移动版。移动版和PC版的功能是一样的，只是它们的页面表现形式不一样。所以网站在设计之初，就考虑了模块化和代码复用，用最小的成本获得同时实现PC端和移动端的功能。

不知道为什么，说起PHP，总是会想起“PHP是最好的语言”这句话。从这一个月的经历看，PHP是不是最好的语言不知道，但是用来建网站，PHP的确是最好的语言。用PHP和JS开发网站，效率比用Java/OC开发App，高多了。不过，网站的体验不如App。所以移动开发目前还是王道。

接下来，我会用一个系列的文章分享整个建站过程，包括：

1. 域名、云服务器、域名解析、网站备案、域名邮箱、CA证书申请

2. LNMP开发环境搭建，包括如何配置SSL加密的HTTPS站点

3. 支持SSH访问的GIT仓库搭建

4. 网站基本功能开发，PC版和移动版代码复用

5. 基于MySQL Connector/Python的管理后台开发

欢迎大家关注！想在线阅读《Android系统源代码情景分析》一书的，点击进击的程序员进入！

作者：Luoshengyang 发表于2017/1/10 22:42:11 原文链接

阅读：45265 评论：28 查看评论

↧

【MQ】ActiveMQ（二）——消息处理机制

November 17, 2017, 10:08 am

≫ Next: 【蓝桥杯】【丢手帕问题】

≪ Previous: 《Android系统源代码情景分析》连载回忆录：灵感之源

一、前言

上文中，小编提到安装ActiveMQ，但是对于ActiveMQ中消息是用什么样的形式存储的？下面小编就向大家介绍一下。

二、消息类型

对于消息的传递有两种类型：

点对点的，即一个生产者和一个消费者一一对应；

发布/订阅模式，即一个生产者产生消息并进行发送后，可以由多个消费者进行接收。

JMS定义了五种不同的消息正文格式，以及调用的消息类型，允许你发送并接收以一些不同形式的数据，提供现有消息格式的一些级别的兼容性。

StreamMessage – Java原始值的数据流
MapMessage–一套名称-值对
TextMessage–一个字符串对象
ObjectMessage–一个序列化的 Java对象
BytesMessage–一个字节的数据流

三、点对点Queue

3.1 Producer

生产者：生产消息，发送端。
把jar包添加到工程中。使用5.11.2版本的jar包。

第一步：创建ConnectionFactory对象，需要指定服务端ip及端口号。
第二步：使用ConnectionFactory对象创建一个Connection对象。
第三步：开启连接，调用Connection对象的start方法。
第四步：使用Connection对象创建一个Session对象。
第五步：使用Session对象创建一个Destination对象（topic、queue），此处创建一个Queue对象。
第六步：使用Session对象创建一个Producer对象。
第七步：创建一个Message对象，创建一个TextMessage对象。
第八步：使用Producer对象发送消息。
第九步：关闭资源。

@Test
    public void testQueueProducer() throws Exception {
        // 第一步：创建ConnectionFactory对象，需要指定服务端ip及端口号。
        //brokerURL服务器的ip及端口号
        ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://192.168.25.168:61616");
        // 第二步：使用ConnectionFactory对象创建一个Connection对象。
        Connection connection = connectionFactory.createConnection();
        // 第三步：开启连接，调用Connection对象的start方法。
        connection.start();
        // 第四步：使用Connection对象创建一个Session对象。
        //第一个参数：是否开启事务。true：开启事务，第二个参数忽略。
        //第二个参数：当第一个参数为false时，才有意义。消息的应答模式。1、自动应答2、手动应答。一般是自动应答。
        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        // 第五步：使用Session对象创建一个Destination对象（topic、queue），此处创建一个Queue对象。
        //参数：队列的名称。
        Queue queue = session.createQueue("test-queue");
        // 第六步：使用Session对象创建一个Producer对象。
        MessageProducer producer = session.createProducer(queue);
        // 第七步：创建一个Message对象，创建一个TextMessage对象。
        /*TextMessage message = new ActiveMQTextMessage();
        message.setText("hello activeMq,this is my first test.");*/
        TextMessage textMessage = session.createTextMessage("hello activeMq,this is my first test.");
        // 第八步：使用Producer对象发送消息。
        producer.send(textMessage);
        // 第九步：关闭资源。
        producer.close();
        session.close();
        connection.close();
    }

3.2 12.1.2. Consumer

消费者：接收消息。

第一步：创建一个ConnectionFactory对象。
第二步：从ConnectionFactory对象中获得一个Connection对象。
第三步：开启连接。调用Connection对象的start方法。
第四步：使用Connection对象创建一个Session对象。
第五步：使用Session对象创建一个Destination对象。和发送端保持一致queue，并且队列的名称一致。
第六步：使用Session对象创建一个Consumer对象。
第七步：接收消息。
第八步：打印消息。
第九步：关闭资源

@Test
    public void testQueueConsumer() throws Exception {
        // 第一步：创建一个ConnectionFactory对象。
        ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://192.168.25.168:61616");
        // 第二步：从ConnectionFactory对象中获得一个Connection对象。
        Connection connection = connectionFactory.createConnection();
        // 第三步：开启连接。调用Connection对象的start方法。
        connection.start();
        // 第四步：使用Connection对象创建一个Session对象。
        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        // 第五步：使用Session对象创建一个Destination对象。和发送端保持一致queue，并且队列的名称一致。
        Queue queue = session.createQueue("test-queue");
        // 第六步：使用Session对象创建一个Consumer对象。
        MessageConsumer consumer = session.createConsumer(queue);
        // 第七步：接收消息。
        consumer.setMessageListener(new MessageListener() {

            @Override
            public void onMessage(Message message) {
                try {
                    TextMessage textMessage = (TextMessage) message;
                    String text = null;
                    //取消息的内容
                    text = textMessage.getText();
                    // 第八步：打印消息。
                    System.out.println(text);
                } catch (JMSException e) {
                    e.printStackTrace();
                }
            }
        });
        //等待键盘输入
        System.in.read();
        // 第九步：关闭资源
        consumer.close();
        session.close();
        connection.close();
    }

四、发布订阅Topic

4.1 Producer

使用步骤：

第一步：创建ConnectionFactory对象，需要指定服务端ip及端口号。
第二步：使用ConnectionFactory对象创建一个Connection对象。
第三步：开启连接，调用Connection对象的start方法。
第四步：使用Connection对象创建一个Session对象。
第五步：使用Session对象创建一个Destination对象（topic、queue），此处创建一个Topic对象。
第六步：使用Session对象创建一个Producer对象。
第七步：创建一个Message对象，创建一个TextMessage对象。
第八步：使用Producer对象发送消息。
第九步：关闭资源。

@Test
    public void testTopicProducer() throws Exception {
        // 第一步：创建ConnectionFactory对象，需要指定服务端ip及端口号。
        // brokerURL服务器的ip及端口号
        ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://192.168.25.168:61616");
        // 第二步：使用ConnectionFactory对象创建一个Connection对象。
        Connection connection = connectionFactory.createConnection();
        // 第三步：开启连接，调用Connection对象的start方法。
        connection.start();
        // 第四步：使用Connection对象创建一个Session对象。
        // 第一个参数：是否开启事务。true：开启事务，第二个参数忽略。
        // 第二个参数：当第一个参数为false时，才有意义。消息的应答模式。1、自动应答2、手动应答。一般是自动应答。
        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        // 第五步：使用Session对象创建一个Destination对象（topic、queue），此处创建一个topic对象。
        // 参数：话题的名称。
        Topic topic = session.createTopic("test-topic");
        // 第六步：使用Session对象创建一个Producer对象。
        MessageProducer producer = session.createProducer(topic);
        // 第七步：创建一个Message对象，创建一个TextMessage对象。
        /*
         * TextMessage message = new ActiveMQTextMessage(); message.setText(
         * "hello activeMq,this is my first test.");
         */
        TextMessage textMessage = session.createTextMessage("hello activeMq,this is my topic test");
        // 第八步：使用Producer对象发送消息。
        producer.send(textMessage);
        // 第九步：关闭资源。
        producer.close();
        session.close();
        connection.close();
    }

4.2 Consumer

消费者：接收消息。

第一步：创建一个ConnectionFactory对象。
第二步：从ConnectionFactory对象中获得一个Connection对象。
第三步：开启连接。调用Connection对象的start方法。
第四步：使用Connection对象创建一个Session对象。
第五步：使用Session对象创建一个Destination对象。和发送端保持一致topic，并且话题的名称一致。
第六步：使用Session对象创建一个Consumer对象。
第七步：接收消息。
第八步：打印消息。
第九步：关闭资源

@Test
    public void testTopicConsumer() throws Exception {
        // 第一步：创建一个ConnectionFactory对象。
        ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("tcp://192.168.25.168:61616");
        // 第二步：从ConnectionFactory对象中获得一个Connection对象。
        Connection connection = connectionFactory.createConnection();
        // 第三步：开启连接。调用Connection对象的start方法。
        connection.start();
        // 第四步：使用Connection对象创建一个Session对象。
        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        // 第五步：使用Session对象创建一个Destination对象。和发送端保持一致topic，并且话题的名称一致。
        Topic topic = session.createTopic("test-topic");
        // 第六步：使用Session对象创建一个Consumer对象。
        MessageConsumer consumer = session.createConsumer(topic);
        // 第七步：接收消息。
        consumer.setMessageListener(new MessageListener() {

            @Override
            public void onMessage(Message message) {
                try {
                    TextMessage textMessage = (TextMessage) message;
                    String text = null;
                    // 取消息的内容
                    text = textMessage.getText();
                    // 第八步：打印消息。
                    System.out.println(text);
                } catch (JMSException e) {
                    e.printStackTrace();
                }
            }
        });
        System.out.println("topic的消费端03。。。。。");
        // 等待键盘输入
        System.in.read();
        // 第九步：关闭资源
        consumer.close();
        session.close();
        connection.close();
    }

五、小结

通过分析和用不与spring结合的测试方法来更加深刻的了解mq在具体的使用过程中的步骤。

都是引入相关jar包后，创建连接工厂，工厂创建相关的连接对象，连接对象打开，创建相关的会话，会话发起目的地并且创建生产者或者消费者，然后对消息进行处理，最后关闭连接。

下一篇博客小编会向大家介绍如何使用spring管理ActiveMQ。

作者：kisscatforever 发表于2017/11/17 10:08:12 原文链接

阅读：121 评论：0 查看评论

↧

【蓝桥杯】【丢手帕问题】

November 17, 2017, 10:29 am

≫ Next: Quartz-SchedulerListener解读

≪ Previous: 【MQ】ActiveMQ（二）——消息处理机制

【题目】
约瑟夫问题是个有名的问题：N个人围成一圈，从第一个开始报数，第M个将被杀掉，最后剩下一个，其余人都将被杀掉。
例如N=6，M=5，被杀掉的人的序号为5，4，6，2，3。最后剩下1号。

输入两个整数N,M
比如 6 5
输出被杀掉的人的序号
比如5 4 6 2 3 1
再比如：
输入 11 3
输出 3 6 9 1 5 10 4 11 8 2 7

【分析】
可以使用数组来模拟(猴子选大王)
也可以使用集合来模拟，这里采用集合模拟思路
建立一个整数集合，对其赋值，1~N
每次递增M-1，注意这里不是递增M
如果递增后数字的范围超过了集合的范围就对集合大小取模
删除掉相应的第M个人

【源码】

    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int N = sc.nextInt();
        int M = sc.nextInt();
        sc.close();
        //建立集合
        LinkedList<Integer> list = new LinkedList<Integer>();
        //为每个人编号1~N
        for (int i = 1; i <= N; i++) {
            list.add(i);
        }

        //标记变量，用来标记第M个人
        int a = 0;

        //开始循环模拟
        while (list.size() > 1) {
            //递增M-1，找到第M个人，这个数值有可能超出集合的上限范围
            a += M-1;
            //用a对集合的大小取模运算
            a = a % list.size();
            //打印并删除掉第M个人
            System.out.print(list.remove(a)+" ");
        }
        //把最后一个人打印并删除
        System.out.println(list.remove(0));

    }

【结果】
11 3
3 6 9 1 5 10 4 11 8 2 7

作者：bear_huangzhen 发表于2017/11/17 10:29:09 原文链接

阅读：107 评论：0 查看评论

↧

Quartz-SchedulerListener解读

November 17, 2017, 10:34 am

≫ Next: itext7学习笔记——第5章

≪ Previous: 【蓝桥杯】【丢手帕问题】

概述

SchedulerListener 是在 Scheduler 级别的事件产生时得到通知，不管是增加还是移除 Scheduler 中的 Job，或者是 Scheduler 遭遇到了严重的错误时。那些事件多是关于对 Scheduler 管理的，而不是专注于 Job 或 Trigger 的。

org.quartz.SchedulerListener 接口包含了一系列的回调方法，它们会在 Scheduler 的生命周期中有关键事件发生时被调用。

SchedulerListener接口方法解读

我们先看下SchedulerListener的源码

public interface SchedulerListener {     
   public void jobScheduled(Trigger trigger);     
    public void jobUnscheduled(String triggerName, String triggerGroup);     
    public void triggerFinalized(Trigger trigger);     
    public void triggersPaused(String triggerName, String triggerGroup);     
    public void triggersResumed(String triggerName,String triggerGroup);     
    public void jobsPaused(String jobName, String jobGroup);     
    public void jobsResumed(String jobName, String jobGroup);     
    public void schedulerError(String msg, SchedulerException cause);     
    public void schedulerShutdown();     
}

jobScheduled() 和 jobUnscheduled()：Scheduler 在有新的 JobDetail 部署或卸载时调用这两个中的相应方法。
triggerFinalized() ：当一个 Trigger 来到了再也不会触发的状态时调用这个方法。除非这个 Job 已设置成了持久性，否则它就会从 Scheduler 中移除。
triggersPaused()：Scheduler 调用这个方法是发生在一个 Trigger 或 Trigger 组被暂停时。假如是 Trigger 组的话，triggerName 参数将为 null。
triggersResumed()：Scheduler 调用这个方法是发生成一个 Trigger 或 Trigger 组从暂停中恢复时。假如是 Trigger 组的话，triggerName 参数将为 null。
jobsPaused()：当一个或一组 JobDetail 暂停时调用这个方法。
jobsResumed()：当一个或一组 Job 从暂停上恢复时调用这个方法。假如是一个 Job 组，jobName 参数将为 null。
schedulerError()：在 Scheduler 的正常运行期间产生一个严重错误时调用这个方法。错误的类型会各式的，但是下面列举了一些错误例子：

初始化 Job 类的问题
试图去找到下一 Trigger 的问题
JobStore 中重复的问题
数据存储连接的问题

你可以使用 SchedulerException 的 getErrorCode() 或者 getUnderlyingException() 方法或获取到特定错误的更详尽的信息。

schedulerShutdown()：Scheduler 调用这个方法用来通知 SchedulerListener Scheduler 将要被关闭。

示例

Job复用TriggerListener中的SimpleJob1

详见 Quartz-TriggerListener解读

自定义SchedulerListener

package com.xgj.quartz.quartzItself.listener.schedulerListener;

import org.quartz.JobDetail;
import org.quartz.JobKey;
import org.quartz.SchedulerException;
import org.quartz.SchedulerListener;
import org.quartz.Trigger;
import org.quartz.TriggerKey;

public class MySchedulerListener implements SchedulerListener {

    @Override
    public void jobScheduled(Trigger trigger) {
        System.out.println("MySchedulerListener jobScheduled trigger");

    }

    @Override
    public void jobUnscheduled(TriggerKey triggerKey) {
        System.out.println("MySchedulerListener jobScheduled triggerKey");

    }

    @Override
    public void triggerFinalized(Trigger trigger) {
        System.out.println("MySchedulerListener triggerFinalized");

    }

    @Override
    public void triggerPaused(TriggerKey triggerKey) {
        System.out.println("MySchedulerListener triggerPaused");

    }

    @Override
    public void triggersPaused(String triggerGroup) {
        System.out.println("MySchedulerListener triggersPaused");

    }

    @Override
    public void triggerResumed(TriggerKey triggerKey) {
        System.out.println("MySchedulerListener triggerResumed triggerKey");

    }

    @Override
    public void triggersResumed(String triggerGroup) {
        System.out.println("MySchedulerListener triggerResumed triggerGroup");

    }

    @Override
    public void jobAdded(JobDetail jobDetail) {
        System.out.println("MySchedulerListener jobAdded");
    }

    @Override
    public void jobDeleted(JobKey jobKey) {
        System.out.println("MySchedulerListener jobDeleted");

    }

    @Override
    public void jobPaused(JobKey jobKey) {
        System.out.println("MySchedulerListener jobPaused jobKey");

    }

    @Override
    public void jobsPaused(String jobGroup) {
        System.out.println("MySchedulerListener jobsPaused jobGroup");

    }

    @Override
    public void jobResumed(JobKey jobKey) {
        System.out.println("MySchedulerListener jobResumed  jobKey");

    }

    @Override
    public void jobsResumed(String jobGroup) {
        System.out.println("MySchedulerListener jobsResumed  jobGroup");

    }

    @Override
    public void schedulerError(String msg, SchedulerException cause) {
        System.out.println("MySchedulerListener schedulerError");

    }

    @Override
    public void schedulerInStandbyMode() {
        System.out.println("MySchedulerListener schedulerInStandbyMode");

    }

    @Override
    public void schedulerStarted() {
        System.out.println("MySchedulerListener schedulerStarted");

    }

    @Override
    public void schedulerStarting() {
        System.out.println("MySchedulerListener schedulerStarting");

    }

    @Override
    public void schedulerShutdown() {
        System.out.println("MySchedulerListener schedulerShutdown");

    }

    @Override
    public void schedulerShuttingdown() {
        System.out.println("MySchedulerListener schedulerShuttingdown");

    }

    @Override
    public void schedulingDataCleared() {
        System.out.println("MySchedulerListener schedulingDataCleared");

    }

}

调度类

package com.xgj.quartz.quartzItself.listener.schedulerListener;

import static org.quartz.JobBuilder.newJob;
import static org.quartz.TriggerBuilder.newTrigger;

import org.quartz.JobDetail;
import org.quartz.Scheduler;
import org.quartz.SchedulerFactory;
import org.quartz.SchedulerListener;
import org.quartz.SchedulerMetaData;
import org.quartz.Trigger;
import org.quartz.impl.StdSchedulerFactory;

import com.xgj.quartz.quartzItself.listener.triggerListener.SimpleJob1;

public class SchedulerListenerDemo {

    public static void main(String[] args) throws Exception {

        System.out.println("------- 初始化 ----------------------");

        // Scheduler
        SchedulerFactory schedulerFactory = new StdSchedulerFactory();
        Scheduler scheduler = schedulerFactory.getScheduler();

        // 添加监听器
        SchedulerListener schedulerListener = new MySchedulerListener();
        scheduler.getListenerManager().addSchedulerListener(schedulerListener);

        // Job
        JobDetail job = newJob(SimpleJob1.class).withIdentity("job1", "group1")
                .build();

        // Tirgger
        Trigger trigger = newTrigger().withIdentity("trigger1", "group1")
                .startNow().build();

        // 将job任务加入到调度器
        scheduler.scheduleJob(job, trigger);

        // 开始任务
        System.out.println("------- 开始执行调度器 Scheduler ----------------");
        scheduler.start();

        try {
            System.out.println("------- 等待 30 秒... --------------");
            Thread.sleep(30L * 1000L);
        } catch (Exception e) {
            e.printStackTrace();
        }

        scheduler.shutdown(true);
        System.out.println("------- 关闭调度器 -----------------");

        SchedulerMetaData metaData = scheduler.getMetaData();
        System.out.println("~~~~~~~~~~  执行了 "
                + metaData.getNumberOfJobsExecuted() + " 个 jobs.");

    }
}

运行结果

------- 初始化 ----------------------
INFO  StdSchedulerFactory - Using default implementation for ThreadExecutor
INFO  SimpleThreadPool - Job execution threads will use class loader of thread: main
INFO  SchedulerSignalerImpl - Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
INFO  QuartzScheduler - Quartz Scheduler v.2.2.3 created.
INFO  RAMJobStore - RAMJobStore initialized.
INFO  QuartzScheduler - Scheduler meta-data: Quartz Scheduler (v2.2.3) 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED'
  Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
  NOT STARTED.
  Currently in standby mode.
  Number of jobs executed: 0
  Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 10 threads.
  Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered.

INFO  StdSchedulerFactory - Quartz scheduler 'DefaultQuartzScheduler' initialized from default resource file in Quartz package: 'quartz.properties'
INFO  StdSchedulerFactory - Quartz scheduler version: 2.2.3
MySchedulerListener jobAdded
MySchedulerListener jobScheduled trigger
------- 开始执行调度器 Scheduler ----------------
MySchedulerListener schedulerStarting
INFO  QuartzScheduler - Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
MySchedulerListener schedulerStarted
------- 等待 30 秒... --------------

Job1 - 任务key group1.job1执行时间：2017-11-16 22:14:33
MySchedulerListener triggerFinalized
MySchedulerListener jobDeleted
INFO  QuartzScheduler - Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED shutting down.
INFO  QuartzScheduler - Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED paused.
MySchedulerListener schedulerInStandbyMode
MySchedulerListener schedulerShuttingdown
MySchedulerListener schedulerShutdown
INFO  QuartzScheduler - Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED shutdown complete.
------- 关闭调度器 -----------------
~~~~~~~~~~  执行了 1 个 jobs.

示例源码

代码已托管到Github—> https://github.com/yangshangwei/SpringMaster

作者：yangshangwei 发表于2017/11/17 10:34:43 原文链接

阅读：123 评论：0 查看评论

↧

itext7学习笔记——第5章

November 17, 2017, 10:48 am

≫ Next: Python垃圾回收机制

≪ Previous: Quartz-SchedulerListener解读

前言

在之前的第1到第3章，我们总是从头开始用iText创建一个新的PDF文档。在第4章的最后几个例子中，我们使用了一个现有的PDF文档，利用现有的PDF来读取表单并填写了自己的表单或者预填充定义的表单。在本章，我们会使用PdfReader读取一个存在的PDF文件，或者使用PdfWriter对象来创建一个新的PdfDocument。

添加注释和内容

在前面的章节中，我们读取了一个带有表单的PDF文档，然后填充了里面的内容。在这个章节中，我们会进行深入的操作。我们首先添加一个文档注释，一些文本和一个新的复选框，如下图：

itext5-1

接下来就是我们在第四章里面添加注释和内容里面的代码一样了：

PdfDocument pdfDoc =
    new PdfDocument(new PdfReader(src), new PdfWriter(dest));
// add content
pdfDoc.close();

我们在//add content部分添加相应的内容，首先，我们通过PdfDocument实例来向一个页面里面添加注释：

PdfAnnotation ann = new PdfTextAnnotation(new Rectangle(400, 795, 0, 0))
    .setTitle(new PdfString("iText"))
    .setContents("Please, fill out the form.")
    .setOpen(true);
pdfDoc.getFirstPage().addAnnotation(ann);

如果我们想添加内容到内容流里面，我们需要创建一个PdfCancas对象。我们可以传入一个PdfPage对象传入PdfCanvas的构造函数：

PdfCanvas canvas = new PdfCanvas(pdfDoc.getFirstPage());
canvas.beginText().setFontAndSize(
        PdfFontFactory.createFont(FontConstants.HELVETICA), 12)
        .moveText(265, 597)
        .showText("I agree to the terms and conditions.")
        .endText();

添加文本的代码和我们在第2章写的代码差不多。无论您是从头开始创建文档还是将内容添加到现有文档，都可以使用我们写的代码。当然，向PdfAcroForm实例添加字段也是跟之前的例子一样的：

PdfAcroForm form = PdfAcroForm.getAcroForm(pdfDoc, true);
PdfButtonFormField checkField = PdfFormField.createCheckBox(
        pdfDoc, new Rectangle(245, 594, 15, 15),
        "agreement", "Off", PdfFormField.TYPE_CHECK);
checkField.setRequired(true);
form.addField(checkField);

最后，既然我们已经添加了一个多余的字段，我们想要改变reset的动作：

form.getField("reset").setAction(PdfAction.createResetForm(
    new String[]{"name", "language", "experience1", "experience2",
    "experience3", "shift", "info", "agreement"}, 0))

改变表单字段的属性

之前的第四章的例子中，我们是填充了表单的内容。在这里，我们可以尝试改变字段的属性，添加或者删除。

PdfAcroForm form = PdfAcroForm.getAcroForm(pdfDoc, true);
Map<String, PdfFormField> fields = form.getFormFields();
fields.get("name").setValue("James Bond").setBackgroundColor(Color.ORANGE);
fields.get("language").setValue("English");
fields.get("experience1").setValue("Yes");
fields.get("experience2").setValue("Yes");
fields.get("experience3").setValue("Yes");
List<PdfString> options = new ArrayList<PdfString>();
options.add(new PdfString("Any"));
options.add(new PdfString("8.30 am - 12.30 pm"));
options.add(new PdfString("12.30 pm - 4.30 pm"));
options.add(new PdfString("4.30 pm - 8.30 pm"));
options.add(new PdfString("8.30 pm - 12.30 am"));
options.add(new PdfString("12.30 am - 4.30 am"));
options.add(new PdfString("4.30 am - 8.30 am"));
PdfArray arr = new PdfArray(options);
fields.get("shift").setOptions(arr);
fields.get("shift").setValue("Any");
PdfFont courier = PdfFontFactory.createFont(FontConstants.COURIER);
fields.get("info")
    .setValue("I was 38 years old when I became a 007 agent.", courier, 7);

在这里我们关注下面的几行：

行3：我们设置name字段的值为James Bond,同时我们设置这个字段的背景色为Color.ORANGE
行9-17：创建了一个Java List来添加更多的选项(行8-15),然后把这个List转换成PdfArray(行16),最后使用这个array来更新shift字段
行19-21：我们创建了一个新的PdfFont，然后使用这个新的字体和新的字体大小作为info字段的设置值方法的参数。

让我们看看加入这些代码以后是否有所改变，如图：

itext5-2

我们可以看到shift字段有了更多的选项，但是我们没有看见name字段的背景，我们是不能清楚info字段是否改变。是否发生错误了呢？其实是没有错误的，所有字段当前是被突出显示的而且蓝色的突出色覆盖了背景颜色，我们可以点击Highlight Existing Fields来看看还会发生什么，如图：

itext5-3

一切跟我们期望的一样。但是我们没有遇到这样一种情况：在关闭PdfDocument之前，我们加入了form.flattenFields();语句，这时候表单就锁定，我们就没有了表单，针对这种情况，我们会在下一章探讨。现在，我们来看看我们是不是还能对没有表单的pdf文档进行一些其他的操作。

添加页眉、页脚和水印

我们回忆在一下第三章里面的UFO信息的PDF，我们会创建一个相似的ufo.pdf文件：

itext5-4

可以看出我们创建的ufo.pdf并没有第三章创建的那样炫酷，如果我们往里面添加一个页眉和一个页脚（显示第几页/总页数）还有水印，该如何做呢，如下图：

itext5-5

在上图中，我们不像第三章那样在添加页脚的时候不知道总的页数，现在我们知道了总的页数，可以添加”1” of “4”，”2” of “4”等

从头创建文档时，可以为总页数创建一个占位符（placeholder）。一旦创建了所有的页面，我们就可以将该页面的总数添加到该占位符，但这不在本介绍性教程的范围之内。

如下代码展示了如何在已知的文档的每一页中添加内容：

PdfDocument pdfDoc =
    new PdfDocument(new PdfReader(src), new PdfWriter(dest));
Document document = new Document(pdfDoc);
Rectangle pageSize;
PdfCanvas canvas;
int n = pdfDoc.getNumberOfPages();
for (int i = 1; i <= n; i++) {
    PdfPage page = pdfDoc.getPage(i);
    pageSize = page.getPageSize();
    canvas = new PdfCanvas(page);
    // add new content
}
pdfDoc.close();

我们使用pdfDoc对象来创建一个Document实例。我们将要使用这个document对象来添加内容。我们同时也会使用pdfDoc对象来找到原始PDF的总页数。我们遍历所有所有的页数，获得每一页的PdfPage对象。以下代码是//add new content所做得东西：

//Draw header text
canvas.beginText().setFontAndSize(
        PdfFontFactory.createFont(FontConstants.HELVETICA), 7)
        .moveText(pageSize.getWidth() / 2 - 24, pageSize.getHeight() - 10)
        .showText("I want to believe")
        .endText();
//Draw footer line
canvas.setStrokeColor(Color.BLACK)
        .setLineWidth(.2f)
        .moveTo(pageSize.getWidth() / 2 - 30, 20)
        .lineTo(pageSize.getWidth() / 2 + 30, 20).stroke();
//Draw page number
canvas.beginText().setFontAndSize(
        PdfFontFactory.createFont(FontConstants.HELVETICA), 7)
        .moveText(pageSize.getWidth() / 2 - 7, 10)
        .showText(String.valueOf(i))
        .showText(" of ")
        .showText(String.valueOf(n))
        .endText();
//Draw watermark
Paragraph p = new Paragraph("CONFIDENTIAL").setFontSize(60);
canvas.saveState();
PdfExtGState gs1 = new PdfExtGState().setFillOpacity(0.2f);
canvas.setExtGState(gs1);
document.showTextAligned(p,
        pageSize.getWidth() / 2, pageSize.getHeight() / 2,
        pdfDoc.getPageNumber(page),
        TextAlignment.CENTER, VerticalAlignment.MIDDLE, 45);
canvas.restoreState();

总共的步骤分为四部：

页眉(行2-6)：我们使用第二章谈及的低等级的文本api来在每一页的最上方添加"I want to believe"
页脚线(行8-11)：我们使用低等级的画图api来在每一页的底部画线
包含页码的页脚(行13-19)：我们使用低等级的文本api在每一页底部添加当前页号，"of",以及总的页数。
水印(行21-28)：我们创建一个带有文本的Paragrah来当做水印。然后我们改变画布的透明性。最后我们添加这个Paragrah到文档中，使用showTextAligned()方法使水印定位在每一页的中间，并45度倾斜。

在这里，我们添加水印的时候做了一些特殊的工作。我们改变了canvas对象的图像状态，然后我们在document的每一页中添加了文本，在内部，iText会发现我们已经使用了当前页的PafCanvas实例，同时showTextAligned会想同一个canvas写入内容，这种方式，我们可以使用低级api和一些简单方法(如高级api)的结合(可以和第三章的添加水印相比较，确实是方便了不少)。在本章最后的例子中，我们会改变页面的大小和upf.pdf的每一页的方向。

改变页面大小和方向

新的pdf文档效果如下：

itext5-6

我们可以发现每一页面变得更大了，而且第二页的颠倒了，向下了。让我们来看看代码：

PdfDocument pdfDoc =
    new PdfDocument(new PdfReader(src), new PdfWriter(dest));
float margin = 72;
for (int i = 1; i <= pdfDoc.getNumberOfPages(); i++) {
    PdfPage page = pdfDoc.getPage(i);
    // change page size
    Rectangle mediaBox = page.getMediaBox();
    Rectangle newMediaBox = new Rectangle(
            mediaBox.getLeft() - margin, mediaBox.getBottom() - margin,
            mediaBox.getWidth() + margin * 2, mediaBox.getHeight() + margin * 2);
    page.setMediaBox(newMediaBox);
    // add border
    PdfCanvas over = new PdfCanvas(page);
    over.setStrokeColor(Color.GRAY);
    over.rectangle(mediaBox.getLeft(), mediaBox.getBottom(),
            mediaBox.getWidth(), mediaBox.getHeight());
    over.stroke();
    // change rotation of the even pages
    if (i % 2 == 0) {
        page.setRotation(180);
    }
}
pdfDoc.close();

可以发现，这里我们不需要Document实例，我们只需要PdfDocument实例就够啦。我们遍历所有的页面(行4)和获取每一页的PdfPage实例(行5)：

一个页面可以有不同的边界，其中/MediaBox基本上就是页面大小了(详情了可以百度PDF MediaBox)，然后我们获取一个Rectangle作为原页面的边界(行7)，根据这个边界来创建一英尺更大的边Rectangle来当做新的页面边界大小，最后我们使用setMediaBox()来改变页面大小
我们创了页面的PdfCanvas对象，然后使用灰色画笔画出了mediaBox的边界(行14-17)
偶数页，我们把页面旋转180度(行19)

改变已知存在的PDF文档需要关于PDF的很多知识，比如/MediaBox的概念。我们为了使举的例子看起来简单，我们会规避一些其他的细节，例如在上面一个例子中，我们没有检查文档中有CropBox对象，如果有这个对象的话，使/MediaBox变大不会带来任何视觉上的变换。所以将会花上更多篇章来深入讨论这些问题。

总结

    在之前的篇章中，我们学习了交互式的PDF表单。在本章中，我们继续操作这些表单：添加注释，一些文本和额外的字段，我们在填充表单的同时还改变了字段的一些属性。
    然后我们讨论了那些没有交互的PDF文档，首先，我们添加了页眉、页脚和水印，然后我们改变了已知文档的页面大小和方向。
    在下一个章节中，我们会缩放和平铺已知文档，然后我们会学会如何将多个文档组合成一个PDF

PS:我的itext7专栏上线啦，里面都是我精心翻译和整理的关于itext7的知识，求大家关注一波，之前也收到了一些打赏和鼓励，我会继续更新itext7，分享最新的知识！

作者：u012397189 发表于2017/11/17 10:48:57 原文链接

阅读：108 评论：0 查看评论

↧

Python垃圾回收机制

November 17, 2017, 11:11 am

≫ Next: python: hasattr()、setattr()、getattr()、delattr() 内建函数

≪ Previous: itext7学习笔记——第5章

Python的GC模块主要运用了“引用计数”（reference counting）来跟踪和回收垃圾。在引用计数的基础上，还可以通过“标记-清除”（mark and sweep）解决容器对象可能产生的循环引用的问题。通过“分代回收”（generation collection）以空间换取时间来进一步提高垃圾回收的效率。

一、引用计数

在Python中，大多数对象的生命周期都是通过对象的引用计数来管理的。从广义上来讲，引用计数也是一种垃圾收集机制，而且也是一种最直观，最简单的垃圾收集技术。

原理：当一个对象的引用被创建或者复制时，对象的引用计数加1；当一个对象的引用被销毁时，对象的引用计数减1；当对象的引用计数减少为0时，就意味着对象已经没有被任何人使用了，可以将其所占用的内存释放了。

虽然引用计数必须在每次分配和释放内存的时候加入管理引用计数的动作，然而与其他主流的垃圾收集技术相比，引用计数有一个最大的有点，即“实时性”，任何内存，一旦没有指向它的引用，就会立即被回收。而其他的垃圾收集计数必须在某种特殊条件下（比如内存分配失败）才能进行无效内存的回收。

引用计数机制执行效率问题：引用计数机制所带来的维护引用计数的额外操作与Python运行中所进行的内存分配和释放，引用赋值的次数是成正比的。而这点相比其他主流的垃圾回收机制，比如“标记-清除”，“停止-复制”，是一个弱点，因为这些技术所带来的额外操作基本上只是与待回收的内存数量有关。

如果说执行效率还仅仅是引用计数机制的一个软肋的话，那么很不幸，引用计数机制还存在着一个致命的弱点，正是由于这个弱点，使得侠义的垃圾收集从来没有将引用计数包含在内，能引发出这个致命的弱点就是循环引用（也称交叉引用）。

问题说明：

循环引用可以使一组对象的引用计数不为0，然而这些对象实际上并没有被任何外部对象所引用，它们之间只是相互引用。这意味着不会再有人使用这组对象，应该回收这组对象所占用的内存空间，然后由于相互引用的存在，每一个对象的引用计数都不为0，因此这些对象所占用的内存永远不会被释放。比如：

a=[]
b=[]
a.append(b)
b.append(b)
printa
[[[…]]]
printb
[[[…]]]

这一点是致命的，这与手动进行内存管理所产生的内存泄露毫无区别。要解决这个问题，Python引入了其他的垃圾收集机制来弥补引用计数的缺陷：“标记-清除”，“分代回收”两种收集技术。

二、标记-清除

“标记-清除”是为了解决循环引用的问题。可以包含其他对象引用的容器对象（比如：list，set，dict，class，instance）都可能产生循环引用。

我们必须承认一个事实，如果两个对象的引用计数都为1，但是仅仅存在他们之间的循环引用，那么这两个对象都是需要被回收的，也就是说，它们的引用计数虽然表现为非0，但实际上有效的引用计数为0。我们必须先将循环引用摘掉，那么这两个对象的有效计数就现身了。假设两个对象为A、B，我们从A出发，因为它有一个对B的引用，则将B的引用计数减1；然后顺着引用达到B，因为B有一个对A的引用，同样将A的引用减1，这样，就完成了循环引用对象间环摘除。

但是这样就有一个问题，假设对象A有一个对象引用C，而C没有引用A，如果将C计数引用减1，而最后A并没有被回收，显然，我们错误的将C的引用计数减1，这将导致在未来的某个时刻出现一个对C的悬空引用。这就要求我们必须在A没有被删除的情况下复原C的引用计数，如果采用这样的方案，那么维护引用计数的复杂度将成倍增加。

原理：“标记-清除”采用了更好的做法，我们并不改动真实的引用计数，而是将集合中对象的引用计数复制一份副本，改动该对象引用的副本。对于副本做任何的改动，都不会影响到对象生命走起的维护。

这个计数副本的唯一作用是寻找root object集合（该集合中的对象是不能被回收的）。当成功寻找到root object集合之后，首先将现在的内存链表一分为二，一条链表中维护root object集合，成为root链表，而另外一条链表中维护剩下的对象，成为unreachable链表。之所以要剖成两个链表，是基于这样的一种考虑：现在的unreachable可能存在被root链表中的对象，直接或间接引用的对象，这些对象是不能被回收的，一旦在标记的过程中，发现这样的对象，就将其从unreachable链表中移到root链表中；当完成标记后，unreachable链表中剩下的所有对象就是名副其实的垃圾对象了，接下来的垃圾回收只需限制在unreachable链表中即可。

三、分代回收

背景：分代的垃圾收集技术是在上个世纪80年代初发展起来的一种垃圾收集机制，一系列的研究表明：无论使用何种语言开发，无论开发的是何种类型，何种规模的程序，都存在这样一点相同之处。即：一定比例的内存块的生存周期都比较短，通常是几百万条机器指令的时间，而剩下的内存块，起生存周期比较长，甚至会从程序开始一直持续到程序结束。

从前面“标记-清除”这样的垃圾收集机制来看，这种垃圾收集机制所带来的额外操作实际上与系统中总的内存块的数量是相关的，当需要回收的内存块越多时，垃圾检测带来的额外操作就越多，而垃圾回收带来的额外操作就越少；反之，当需回收的内存块越少时，垃圾检测就将比垃圾回收带来更少的额外操作。为了提高垃圾收集的效率，采用“空间换时间的策略”。

原理：将系统中的所有内存块根据其存活时间划分为不同的集合，每一个集合就成为一个“代”，垃圾收集的频率随着“代”的存活时间的增大而减小。也就是说，活得越长的对象，就越不可能是垃圾，就应该减少对它的垃圾收集频率。那么如何来衡量这个存活时间：通常是利用几次垃圾收集动作来衡量，如果一个对象经过的垃圾收集次数越多，可以得出：该对象存活时间就越长。

作者：qq_29287973 发表于2017/11/17 11:11:10 原文链接

阅读：87 评论：0 查看评论

↧