问：

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

特别是如果进程是 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视图序列化有关）：内容渲染后的UIWebView序列化。仍然没有解决方案。

更新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：

这个问题非常相似：如何在 Firefox/Chrome 中保存选项卡的内存状态？

更新7：

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