如何序列化一个完整的过程?
特别是如果该过程是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:
解决方案是否适合“流程迁移”?
最佳答案
摘自http://www.chromium.org/developers/design-documents/oop-iframes/oop-iframes-rendering#TOC-Background
“将每个节点添加到DOM树后,将在其上调用attach()方法,该方法将创建关联的渲染器”
因此,您将始终需要在RAM中重新创建DOM,因为它不用作先前存在的渲染器的输入,而是会触发渲染的创建。
关于google-chrome - 如何序列化/反序列化Chrome标签(其DOM/RenderTree)?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23860445/