轉自 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
document
輸入事件正在調研...
