当前位置：文档之家 › Chromium扩展(Extension)的页面(Page)加载过程分析

Chromium扩展(Extension)的页面(Page)加载过程分析

  • 格式：doc
  • 大小：152.50 KB
  • 文档页数：15

Chromium扩展（Extension）的页面（Page）加载过程分析Chromium的Extension Page其实就是网页，因此它们的加载过程与普通网页相同。

常见的Extension Page有Background Page和Popup Page。

其中，Background Page在浏览器窗口初始化完成后自动加载，之后运行在后台中。

Popup Page在用户点击地址栏右边的按钮时加载，并且显示在弹窗中。

本文接下来就分析Extension Page的加载过程。

Extension Page是加载在Extension Process中的，如图1所示：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会被调用，如下所示：[cpp] view plain copy 在CODE上查看代码片派生到我的代码片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_中。

参数browser指向的是一个Browser对象。

这个Browser对象描述的就是一个新打开的浏览器窗口，ChromeNotificationObserver类的成员函数OnBrowserWindowReady首先调用它的成员函数profile获得浏览器在启动过程中创建的Profile，然后再根据这个Profile获得一个ProcessManager对象。

有了这个ProcessManager对象之后，就可以调用它的成员函数OnBrowserWindowReady，用来通知它有一个新的浏览器窗口打开了。

浏览器启动时创建Profile的过程，以及根据Profile创建ProcessManager对象的过程，可以参考前面Chromium 扩展（Extension）加载过程分析一文。

ProcessManager类的成员函数OnBrowserWindowReady在执行的过程中，就会为当前加载的Extension创建Background Page，如下所示：[cpp] view plain copy 在CODE上查看代码片派生到我的代码片void ProcessManager::OnBrowserWindowReady() {......CreateBackgroundHostsForProfileStartup();}这个函数定义在文件external/chromium_org/extensions/browser/process_ 中。

ProcessManager类的成员函数OnBrowserWindowReady调用另外一个成员函数CreateBackgroundHostsForProfileStartup为当前加载的Extension创建Background Page，如下所示：[cpp] view plain copy 在CODE上查看代码片派生到我的代码片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_中。

在前面Chromium扩展（Extension）加载过程分析一文提到，Chromium的Browser 进程在启动的时候，会将那些状态设置为Enabled的Extension保存在一个Extension Registry 的Enabled List中。

ProcessManager类的成员函数CreateBackgroundHostsForProfileStartup主要就是遍历这个Enabled List中的每一个Extension，并且调用函数CreateBackgroundHostForExtensionLoad检查它们是否指定了Background Page。

如果指定了，那么就会进行加载。

函数CreateBackgroundHostForExtensionLoad的实现如下所示：[cpp] view plain copy 在CODE上查看代码片派生到我的代码片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_ 中。

函数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获得的，如下所示：[cpp] view plain copy 在CODE上查看代码片派生到我的代码片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_中。

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。

合集下载

Chromium的GPU进程启动过程分析

Chromium的GPU进程启动过程分析

Chromium的GPU进程启动过程分析 Chromium除了有Browser进程和Render进程，还有GPU进程。GPU进程负责Chromium的GPU操作，例如Render进程通过GPU进程离屏渲染网页，Browser进程也是通过GPU进程将离屏渲染好的网页显示在屏幕上。Chromium之所以将GPU操作运行在独立进程中，是考虑到稳定性问题。毕竟GPU操作是硬件相关操作，硬件的差异性会引发一定的不稳性。本文分析GPU进程的启动过程。

GPU进程由Browser进程负责启动，它的启动过程与Render进程的启动过程是类似的，因此在阅读本文之前，最好先阅读一文。不过，GPU进程启动之后，Browser进程会与它建立两个IPC通道。一个IPC通道用来传输普通的IPC消息，另一个IPC通道专门用来执行GPU操作，称为GPU通道。类似地，Render进程需要执行GPU操作时，也会通过Browser进程与GPU进程建立一个专门用来执行GPU操作的IPC通道。Render进程之所以要通过Browser进程间接地与GPU进程建立GPU通道，是因为GPU进程是由Browser进程启动的，Render进程对它一无所知。

以上描述的Browser进程、Render进程和GPU进程的关系可以通过图1概括，如下所示：

在图1中，Browser进程与Render进程的IPC通道的建立过程可以参考前面一文，本文只分析以下三部分内容： 1. Browser进程与GPU进程的IPC通道的建立过程。 2. Browser进程与GPU进程的GPU通道的建立过程。 3. Render进程与GPU进程的GPU通道的建立过程。 Browser进程通过一个GpuProcessHost对象描述由它启动的GPU进程。GPU进程启动起来之后，会创建一个GpuProcess对象用来与Browser进程进行IPC。接下来，Browser进程中的GpuProcessHost对象会通过已经建立起来的IPC通道请求GPU进程中创建一个GPU通道，以便以后可以执行GPU操作。

chrome_扩展

chrome_扩展


Chrome扩展
5）、plugin.h要点剖析
这些都是必须显示声明，并待实现的接口！其中最需要我们关注 的是Invoke接口，它负责Javascript调用时的指令分发。
Chrome扩展
6）、中核心接口的实现
Chrome扩展
7）、PluginTemplate.h中定义NPAPI的接口
浏览器扩展开发下(Chrome)
赵先烈 zhaoxianlie@
目录
•
• • • • • • • • • • •
一、Chrome扩展
1.1、我们能在Chrome上开发些什么？ 1.2、 Chrome扩展的用户界面 1.3、 Chrome扩展的工作原理 1.4、Chrome扩展的结构 1.5、manifest.json详解 1.6、NPAPI 1.7、实战Chrome扩展开发 1.8、扩展实例剖析-IcafeHelper 1.9、Chrome扩展开发学习资源 1.10、Chrome扩展开发总结 附：关于Chrome浏览器
Chrome扩展
4）、一个普通的NPAPI目录结构
左图所示为一个完整的NPAPI插件的C++项 目结构。 Header中，npapi.h、npfunctions.h、 npruntime.h、nptypes.h为NPAPI标配文件， plugin.h、PluginTemplate.h为NPAPI接口的定义 文件。 Source中，np_、npp_为 NPAPI标配文件，、 是NPAPI接口实现的文件， 同 时还是NPAPI的dll入口。
仅对icafe页面注入相关js，而且all_frames必须设为true，设置操 作tab和contextMenu的权限
Chrome扩展
3）、右键菜单的创建过程 a）、icafe页面打开以后，页面会被注入icafe-helper.js，同时会
Selenium启动Chrome插件（ChromeExtensions）

Selenium启动Chrome插件（ChromeExtensions）

Selenium启动Chrome插件（ChromeExtensions）需求描述：在使⽤WebDriver启动Chrome浏览器时式启动⼀个默认设置(⽐较⼲净)的浏览器，但是我在⾃动化测试的过程中需要⽤到插件。

实现⽅法：其⼀：启动浏览器的同时直接取安装包.crx⽂件进⾏安装；下载所需要的插件安装包⽂件.crx,存储到本地，或者存储到项⽬⽂件夹⾥⾯。

然后代码如下：public class openPDFinFirefox extends PdfPage{public WebDriver driver =null;@BeforeMethodpublic void startUp() {ChromeOptions options = new ChromeOptions();/** ⽅法2：安装包直接安装(.crx⽂件)*/options.addExtensions(new File("test/resources/Extensions/pdf-viewer_v2.0.673.crx"));//插件⽂件直接放到项⽬⽂件夹下,当然你需要的插件请⾃⾏下载。

driver = new ChromeDriver(options);driver.manage().window().maximize();/* FireFox 浏览器* *///driver = new FirefoxDriver();}@Testpublic void test() throws Exception {String url = "https://";driver.get(url);Thread.sleep(10);//到这⾥你应该是可以看到你想要的插件了}@AfterMethodpublic void closeBrowser() {driver.close();//driver.quit();}}其⼆：加载本地已经安装的插件。

Chromium的Render进程启动过程分析

Chromium的Render进程启动过程分析

Chromium的Render进程启动过程分析转:罗升阳 2015-08-24 01:06:51 24918 收藏 4分类专栏：⽼罗的Android之旅版权在配置多进程的情况下，Chromium的⽹页渲染和JS执⾏在⼀个单独的进程中进⾏。

这个进程称为Render进程，由Browser进程启动。

在Android平台中，Browser进程就是Android应⽤程序的主进程，⽽Render进程就是Android应⽤程序的Service进程，它们通过UNIX Socket进⾏通信。

本⽂就详细分析Chromium的Browser进程启动Render进程的过程。

⽼罗的新浪微博：/shengyangluo，欢迎关注！《Android系统源代码情景分析》⼀书正在进击的程序员⽹（）中连载，点击进⼊！Render进程启动完成之后，将与Browser进程建⽴以下的IPC通道，如图1所⽰：图1 Browser进程与Render进程的IPC通信过程在Browser进程中，⼀个RenderProcessHost对象⽤来描述它所启动的⼀个Render进程，⽽⼀个RenderViewHost对象⽤来描述运⾏在⼀个Render进程中的⼀个⽹页，我们可以将它理解为浏览器中的⼀个TAB。

这两个对象在Render进程中都有⼀个对等体，它们分别是⼀个RenderProcess对象和⼀个RenderView对象。

这⾥说的对等体，就是它们是Browser进程和Render进程进⾏IPC的两个端点，类似于TCP/IP⽹络堆栈中的层对层通信。

例如，RenderViewHost和RenderView之间的IPC通信，就代表了Browser进程请求Render进程加载、更新和渲染⼀个⽹页。

RenderViewHost和RenderView之间的IPC通信，实际上是通过⼀个UNIX Socket进⾏的。

这个UNIX Socket的两端分别被封装为两个Channel对象，分别运⾏在Browser进程和Render进程各⾃的IO线程中。