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

Question

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

特别是如果该过程是Chrome的标签(及其呈现的DOM)。是否可以完全序列化Chrome选项卡/(选项卡的DOM)，然后再次进行反序列化？ ，以便该选项卡无需再次从选项卡的URL通过HTTP(S)请求HTML ，也不需要在RAM中构建DOM，而是只需加载DOM并发送以呈现(到OS/GPU) ？)。

更新:

我知道，它看起来效率很低(即每个选项卡进程占用大约80 mb的RAM，并且以序列化的形式占用更多内存)，但是否有可能实现它仍然很有趣？假想的应用程序:将Web应用程序细化到磁盘的序列化并在以后还原它，就像它不会关闭(可能是 session token 除外)一样

更新2:

我刚刚找到了关于该问题背后的想法的线索:http://mac-os-forge.2317878.n4.nabble.com/DOM-Serialization-td173772.html。但是最后的讨论没有结果(只是有人发现这不切实际)。该线程来自2010年。

更新3:

有一个与此类似的问题(仅与iOS应用有关，仍然与Web View序列化有关):UIWebView serialization after content has been rendered。仍然没有解决方案。

更新4:

有人讲

DOM Level 3 defines Load & Save interface of DOM

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

与保存和加载呈现的DOM内存模型有关吗？

更新5:

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

更新6:

这个问题非常相似: How to save a tab's memory state in Firefox/Chrome?

更新7:

解决方案是否适合“流程迁移”？

Answer 1

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

“将每个节点添加到DOM树后，将在其上调用attach()方法，该方法将创建关联的渲染器”

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