为IndexedDB连接打开问题分配浏览器内存

busg9geu  于 2022-12-09  发布在  IndexedDB
关注(0)|答案(1)|浏览(365)

设置

大家好,我的组织已经为用户构建了一个Angular PWA,以便用户在他们的公司Surface Go设备上离线工作。该PWA需要在用户断开连接时查看和编辑各种数据,因此我们研究并决定使用IndexedDB(Idb)。用户可以在办公室、离线和外出时下载各种文件、PDF和图像,在应用程序(Idb)中捕捉新照片,并在返回时将这些照片上传回我们的服务器。
我们将大型JSON和blob对象存储在Idb中,以跟踪所有内容,用户可以按照良好的工作流程进行下载、处理和上传。我们还密切关注浏览器中的存储,以确保Surfaces符合限制。
PWA加载在Windows上的MS Edge(Version 96.0.1054.62 (Official build) (64-bit))中,PWA安装在他们的桌面上,像一个本地应用程序一样运行。

问题

这几个月来一直运行良好,但用户现在开始遇到PWA在导航到我们的应用程序时崩溃的问题。打开浏览器,导航到URL,应用程序加载2-3秒,然后整个浏览器崩溃(所有标签页和窗口)。用户报告上传和存储照片(每个3 MB)当第一次崩溃发生时。然后用户就无法使用了,再也不能通过任何方式访问应用程序,所以挑衅地似乎在某个地方出现了一个引爆点。
我们已经将问题缩小到浏览器的内存(RAM)问题。当应用程序启动并建立与Idb的连接时,内存会根据存储在其中的数据量急剧增加。看看Windows中的本地文件系统,受到影响的用户在他们的Idb中存储了超过4.5GB的数据(这就是所有的数据)。

将browser .exe加载到Visual Studio中并导航到应用程序,我们可以看到结果。一旦调用indexeddb.open,就会显示内存中的峰值。

Chrome(在本例中)会抛出内存错误。
我们也尝试过增加浏览器的可用内存量,我们已经能够复制出受影响用户的Idb文件(C:\Users{user}\AppData\Local\Microsoft\Edge\User Data\Default\IndexedDB),将它们交换到我们的机器上,并能够在本地重现崩溃。

系统内存也出现了同样的峰值,但显然还有更多的内存可以给予。
就目前而言,我们的用户是死在水里,无法打开应用程序,无法访问他们的数据。原始Idb文件是不可读的,我们采取的每一个提取数据的解决方案(https://github.com/amyboyd/indexeddb-to-json)都以同样的方式失败。

问题

1.我们可以通过其他方式为浏览器分配更多的内存吗?
1.我们可以在没有浏览器的情况下从Idb中提取数据吗?
1.当我们以其他方式打开Idb时,是否可以避免内存问题?

raogr8fs

raogr8fs1#

好的,几个月后,我们能够实现一种不同的方法,它绕过IndexedDB并使用File System API。这有它自己的缺点,但它通过从IndexedDB中获取原始文件解决了我的所有问题。
关于IndexedDB本身,我们发现了一些关于我们存储在那里的图像的非常具体的问题,因为它们都是base64编码并存储为字符串。似乎当IndexedDB存储这些大字符串(3- 4 MB)时,它必须在唤醒时解码它们,以便稍后根据需要正确地渲染它们。
根据与数据库建立初始连接时必须执行此操作的大字符串的数量,它会导致巨大的内存峰值(解码数百个base64字符串),并最终使浏览器崩溃,因为IndexedDB和浏览器引擎完全崩溃。
我们无法深入挖掘IndexedDB在幕后是如何工作的,以及它在幕后做了什么,这是Google的创造者的一些专有魔法?我希望在WWWC有更多标准知识的人能提供更多的数据。我很想知道它在幕后是如何工作的,以及为什么我们不能访问文件系统上的原始数据。
TLDR;不要在IndexedDB中存储大型base64编码字符串。

相关问题