如何序列化/反序列化Chrome标签(其DOM/RenderTree))？

Question

如何序列化一个完整的过程？

特别是如果该过程是Chrome的标签(带有渲染的DOM).是否可以完全序列化Chrome选项卡/(选项卡的DOM),然后再次反序列化？因此,选项卡不需要再次从选项卡的URL通过HTTP(S)请求HTML,也不需要在RAM中构建DOM,而是只需加载DOM并发送到渲染(到OS/GPU？) .

更新:

我知道,它看起来效率低下(即每个选项卡进程需要大约80 MB的RAM以及更多的序列化形式),但是如果有可能实现它仍然很有趣吗？假设的应用程序:将Web应用程序细粒度地序列化到磁盘并在之后恢复,就像它不会(可能除会话令牌之外)一样

UPDATE2:

我刚刚找到了一个关于这个问题背后的想法的帖子:http://mac-os-forge.2317878.n4.nabble.com/DOM-Serialization-td173772.html.但是讨论结束没有结果(只是有人认为这是不切实际的).该帖子来自2010年.

UPDATE3:

有一个类似于此的问题(仅与iOS应用程序相关,仍与Web视图序列化有关):在呈现内容后的UIWebView序列化.仍然没有解决方案

UPDATE4:

有人讲述

DOM Level 3定义了DOM的Load&Save接口

http://marc.info/?l=webkit-dev&m=126432160427677

它是否与保存和加载渲染的DOM内存模型有关？

Update5:

这里[渲染Webkit(2009):https://www.youtube.com/watch？v = RVnARGhhs9w ]这个人谈论渲染过程中出现的不同树(源文本 - > DOM树 - > RenderObject树 - > RenderStyles - > LineBoxes/Layers).那么是否可以序列化最后的结构(RenderStyles - > LineBoxes/Layers)并在还原选项卡时仅重新创建它们,而不是再次完成整个渲染过程？作为可能的应用程序,我找到了"Duplicate Tab"命令实现:现在它的工作方式是从完整页面开始再次渲染(从URL加载)."复制选项卡"只是克隆数据结构并仅重新渲染图形而不是数据结构本身也是很好的.

Update6:

这个问题非常相似:如何在Firefox/Chrome中保存标签的内存状态？

Update7:

"流程迁移"对解决方案来说是否合理？

Answer 1

摘自http://www.chromium.org/developers/design-documents/oop-iframes/oop-iframes-rendering#TOC-Background

“当每个节点被添加到 DOM 树时，会调用它的 Attach() 方法来创建一个关联的渲染器”

因此，您始终需要在 RAM 中重新创建 DOM，因为它不用作先前存在的渲染器的输入，但也会触发渲染创建。