如何避免本地网络应用程序数据被删除？

Question

我们希望我们的网络应用可以离线使用，主要是在移动设备上。我们已经使用服务工作者为此编写了代码。应用程序数据存储在 IndexedDb 中，应用程序代码（html、js、css 等）存储在 SW 缓存中。到现在为止还挺好。我们知道用户可以删除浏览器缓存和我们的数据，这不是问题。但是浏览器本身擦除应用程序数据呢？我们还没有找到一个全面的规范，我们发现的主要信息是：

1)目前标记为“实验性”的StorageManager功能（自 2016 年起）；

2）从谷歌很短的文章在这里它（也从2016）。

代码示例如下：

if (navigator.storage && navigator.storage.persist)
  navigator.storage.persist().then(granted => {
    if (granted)
      alert("Storage will not be cleared except by explicit user action");
    else
      alert("Storage may be cleared by the UA under storage pressure.");
  });

谷歌文章说：

当本地机器上的存储空间紧张时（“在存储压力下”），用户代理会自动清除存储空间以腾出更多可用空间。当然，对于离线应用来说，这可能是不幸的，因为它们可能还没有将数据同步到服务器，或者它们可能是用户希望离线工作的应用（如音乐播放器）；所以存储规范为给定域定义了两种不同的存储模式——“尽力而为”和“持久”。当然，默认模式是“尽力而为”。“尽力而为”（又名“非持久”）域的存储可以自动清除，无需中断或询问用户。但是，不会自动清除“持久”数据。（如果系统在清除所有非持久性数据后仍处于存储压力下，

...

从 Chrome 55 开始，如果满足以下任一条件，Chrome 将自动授予持久化权限：

• 该站点已添加书签（并且用户有 5 个或更少的书签）
• 该网站具有很高的网站参与度
• 该站点已添加到主屏幕
• 该站点已启用推送通知

在所有其他情况下，该权限将被自动拒绝。

目标是确保用户可以依赖他们最喜欢的网络应用程序，而不会发现他们突然被清除了。

这是针对 Chrome 55 的，假设信息是最新的。乍一看，他们的目标听起来很合理，但是如果您仔细观察，该实现是针对“大”站点（如 Google）而不是面向任务的利基应用程序的。

确实，在 Chrome 80+ 的各种 Android 手机上测试时，持久化总是被拒绝，没有用户交互。所以，它是“尽力而为”。

我们本可以在这里停止调查并收工。毕竟，当前的手机和 PC 的存储量非常大，而我们只使用了几百 KB，所以应该没问题。问题是，我们不是：在带有 Chrome 的全新旗舰 Android 手机上进行测试，我们的代码只需要几秒钟的摆弄就会被擦除（关闭和打开页面几次就足够了）。在其他平台上它是不同的，但 Android+Chrome 将得到最多的使用。

奇怪的是，只有 SW 缓存（<100KB）中的代码被擦除，而较大的 IndexedDb 则没有。所以我们尝试将代码也放在 IndexedDb 中，这样看起来更“持久”，但是管理它的代码也更复杂，所以感觉有点hackish。

是我们一个人遇到这个问题吗？如果没有，你们是如何处理的？

额外的问题：是否有关于该主题的更多最新文档？

Answer 1

如果我理解正确的话，主要问题是Android 上的 Chrome 浏览器会不断清空不满足自动授予持久权限的Chrome 条件的网站的浏览器缓存。

到目前为止，我还没有遇到过这种情况，但我观察到了这种行为，您引用自https://developers.google.com/web/updates/2016/06/persistent-storage - 我只是不知道到目前为止，它已明确记录。

我看到一些网站强制执行持久用户数据存储的三种方式：

1. 反复要求用户将网站添加到主屏幕和/或启用推送通知。我观察到这个请求经常以某种方式出现在虚假标志下，即“订阅通知以表达您的赞赏”，而不是“我们是否允许持久存储数据”。甚至可能会发展到“安装我们的应用程序”本质上意味着将全屏 Chrome 实例添加到移动设备的主屏幕，而不是应用程序商店中的真实应用程序。

2. 有些网站提供 Chrome 扩展程序，允许他们在那里存储内容，甚至获得更多访问权限。我个人并不建议这种方法，它在某种程度上给有安全意识的用户带来了一种奇怪的感觉。

3. 另一种选择是一种混合方法，您提供一个本机应用程序，它实际上只是一个定制的浏览器。如果乍一看这听起来很奇怪，请耐心听我说。事实上，这个选项很容易使用，例如在 React Native 中作为react-native-webbrowser 组件。这显然需要编程工作，但不少新闻网站似乎都使用这种方法。

选项 1 和 2 都坚持使用 Chrome，但显然不适用于您，因为您只是想避免打扰用户。

选项 3 是非常规的，但可能是一个值得考虑的选项。只有程序员用户可能会意识到他们在某种程度上被愚弄了，安装了本质上只是浏览器的东西。尽管如此，这确实是一个干净的解决方案：应用程序商店负责访问权限控制，并且您可以让用户完全选择如何处理数据。