本文共 904 字,大约阅读时间需要 3 分钟。
在实现CanTK-Runtime的过程中,我们曾在V8引擎基础上模拟过浏览器的LocaleStorage功能。这种实现相对简单,因为在那个时候我们认为同一时间只会有一个游戏运行,因此文件操作可以放到后台线程中执行。不过,随着时间的推移,我们发现Chrome的实现却变得非常复杂,主要包含以下四个部分:
首先,Chrome会根据IDL文件生成绑定代码,这些代码位于gen/blink/bindings/modules/v8/V8Storage.cpp
。这些代码起到桥梁作用,负责将JavaScript与C++代码连接起来。当JS调用某个函数时,参数会被拆解并传递给C++函数执行,执行完成后,结果又会返回给JS。
其次,这些绑定代码会调用WebKit中的WebKit/Source/modules/storage
模块。这个模块负责对接浏览器的JS API,并进行一些参数校验和安全检查后,调用WebStorageArea
接口进行操作。
令人惊讶的是,WebStorageArea
接口的真正实现类WebStorageAreaImpl
不在浏览器核心进程,而在content/renderer/dom_storage
目录中。但这里也有一些值得注意的地方:虽然Render
进程处理网页渲染,但存储操作并不直接在Render
进程执行。为了优化性能并且允许多个标签共享同一个存储,真正的文件系统操作被 outsourcing 到了服务进程组。客户端代理只负责在Render
进程中进行转接,而不必直接处理文件数据。
最后,核心的数据库操作则在浏览器的主进程中完成,由Sqlite
引擎管理。这些代码存在于content/browser/dom_storage
目录中,负责处理实际的数据存取和持久化。
通过这四个部分,Chrome实现了LocaleStorage功能,它不仅支持本地存储,还能根据需求卸载存储空间,以符合浏览器安全和性能要求。这一设计充分考虑了不同运行环境下的优化需求,确保了在复杂的网络环境下也能稳定运行。
转载地址:http://dawkk.baihongyu.com/