【问题标题】：How to serialize/deserialize Chrome tab (its DOM/RenderTree))?如何序列化/反序列化 Chrome 选项卡（其 DOM/RenderTree））？
【发布时间】：2014-07-14 15:44:37
【问题描述】：

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

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

更新：

我知道，它看起来效率低下（即每个选项卡进程占用大约 80 mb 的 RAM，并且以序列化形式占用更多），但如果可以实现它仍然很有趣吗？假设的应用程序：将 Web 应用程序细粒度序列化到磁盘并在之后恢复它，就像它不会（可能除了会话令牌）被关闭

更新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 定义了 DOM 的 Load & Save 接口

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

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

更新5：

这里 [Rendering in Webkit (2009): https://www.youtube.com/watch?v=RVnARGhhs9w] 这家伙谈到了在渲染过程中出现的不同树（源文本 -> DOM 树 -> RenderObject 树 -> RenderStyles -> LineBoxes/Layers）。那么是否可以序列化最后的结构（RenderStyles -> LineBoxes/Layers）并在恢复选项卡时仅重新创建它们，而不是再次完整的渲染过程？作为可能的应用程序，我找到了“复制选项卡”命令实现：现在它再次以从头开始呈现在完整页面上的方式工作（从 URL 加载）。如果“复制选项卡”只是克隆数据结构并仅重新渲染图形，而不是数据结构本身，那也很好。

更新6：

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

更新7：

“进程迁移”对于解决方案是否合理？

【问题讨论】：

好问题。你找到保存标签状态的解决方案了吗？

标签： google-chrome dom serialization tabs ram

【解决方案1】：

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

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

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

【讨论】：