google blink的设计计划： Out-of-Progress iframes

转自 http://www.chromium.org/developers/design-documents/oop-iframes

这是chromimu工程内部的一份计划文档，并未付诸实施。但是，我们可以根据它来学习一下google的思想。

这篇文章是对我们计划的一个总体描述，作为 Site Isolation project的一部分。

我们的目的包括在多进程内跟踪iframe；在进程间调用和跟踪脚本；支持frame内跨进程导航；发送输入事件到正确的进程。

Frame概述

我们期望将chromimu的tab-level的逻辑变成frame-level的，这样，每个frame就可以在不同的进程中存在。

背景

一般情况下，那些有脚本相互调用的网页需要存活在同一个进程（如果他们在同一站点），或者需要有一种方法能够彼此传递消息（如果他们在不同的站点）。chromium管理这些关系，是通过将所有页面都放在同一个BrowseringInstance对象中，并把具有同一个BrowsingInstance对象的页按照站点分组放在SiteInstance对象中（在   Process Models中有描述）。

BrowsingInstance通常只包含一个tab，但是当网页使用window.open或者 targeted link时，它也可以包含多个tab. 需要注意到，BrowsingInstance并不知道一个窗口内table的数量，因为手动创建的tab在他们自己的BrowsingInstance中。

为支持像postMessage这种跨进程交互，chromium必须在其他进程的BrowsingInstance中保存一个"可换出的(swapped out)"版本的DOMWindow，作为一个代理。

例如下图

如果站点A的一个网页，可以在它自己的进程内部找到一个代表占地B的活动tab的可换出的DOMWindow。这个DOMWindow将会传递postMessage调用到站点B的对应的进程中的对应页面。

对于out-of-process iframes，chromium也需要跟踪这些可换出DOMWindow，就像对待tab那样。

浏览器进程

在浏览器进程，chromium必须为每个tab跟踪整个frame树。WebContenst将管理以额FrameTreeNode对象树，和当前页的frame树对应。每个FrameTreeNode将包含frame的信息（如，frame的名字），它将负责frame中的跨进程导航，并支持其他进程frame传递过来的消息。

渲染进程

在每个渲染进程，chromium必须跟踪BrowsingInstance中的每个frame的DONWindow，让javascript代码能够找到frame并发送消息给他们。我们需要最小化每个DOMWindow的开销。

我们计划将frame相关的逻辑，从content模块的RenderView和RenderViewHost类中分离，放入一个新的RenderFame和RenderFrameHost类中。这些新的类将分配他们自己的远程id好，以便IPC消息能够识别他们。我们将为每个活动的Frame提供一个RenderFrame类，而且，在其他进程的BrowsingInstance中，我们将提供一个对应的、廋的“可换出“的RenderFrame对象。下图展示了一个包含了两个tab的BrowsingInstance,每个tab包括两个子frame，这些可换出的代理对象，用虚线表示。

blink内部

在blink内部，我们希望能够明确区分出真实的活动frame和那些只是包含代理对象的可换出的Frame。

从概念上，活动Frame包含一个普通的DOMWindow和一个Document，而可换出的Frame包含一个RemoteDomWindow，并没有Document。

我们计划重构Frame，以便Document只通过DOWindow(从Frame中移除直接对 Document的依赖)来访问，这会影响到很大一部分代码。

使用这种方法，可以让我们通过"swappedout://"URL和IPC消息过滤来淘汰当前可换出的逻辑，因为RemoteDOMWindow将没有Document。

这意味着，blink中的代码不能假定Document能够在一个进程中全部遍历。它可能需要改变例如Editor和焦点跟踪这一类代码。

注意：我们正在调研如何减少这些可换出RenderFrame和DOMWindow对象的内存占用，它将比现在的chromium占用更多的内存。

今天，一个BrowsingInstance的内存需求是O(tabs * processes)，而且，大部分BrowsingInstance值包含1到2个tab。新的模型将需要 O（frames*processes)。

这将会使用更多的内存。因为frame的属性将远大于tab的数量，并且，不同站点的frame将会增加更多的进程。

幸运的是，有很多机会可以减少内存的开销。

导航

chromium将在子frame间支持跨进程的导航。不同于现在，让渲染进程拦截所有的导航并觉得是否让浏览器进程处理，新的模型将在浏览器进程的网络栈中处理这些导航。

如果导航跨越了站点的边界，浏览器进程将会交换frame的渲染进程。浏览器进程之所以能够做到这一点，是因为它直到所有的frame树，并且在上层决定。

实现这一点，需要适配 TransferNavigationResourceThrottle对象，并给IO线程以足够的信息，以便它能够判断是否需要交换。

tab的历史会话也将因子frame在不同进程渲染而变得复杂。当前，blink小心的跟踪渲染进程中每个HistoryItem中的frame树，而浏览器进程使用NavigationEntry仅仅跟踪每个后退/前进条目。我们将移除blink的HistoryController中的frame跟踪逻辑，并保持在浏览器进程中直接跟踪每个frame的导航。

我们将用更贴近HTML5标准的方法来表示tab的历史会话。相比为没额HistroyItem clone Frame树的做法，我将在浏览器进程中跟踪每个frame的历史会话，并为后退和前进导航使用分离的“joint session history"列表。列表中的每个条目都将使用一个树指向frame对应的历史会话。

渲染

为了能够在不同进程渲染iframe和它的父页，浏览器进程将在渲染进程间传递信息，帮助GPU进程以正确的顺序和位置来渲染图像。也写逻辑可能适配或者部分用在BrowserPlugin上。

这部分的设计见 separate docu ment

 

输入事件

正在调研...