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