Firestore 作为离线持久化机制有多可靠？
How reliable is Firestore as an offline persistence mechanism?
我目前使用 Firebase Firestore 作为从各种来源检索数据的主要后端。我还使用 Android 的 Room 作为我的移动后端。当 phone 收到数据时，它会存储在 Room 数据库中，以防用户几天甚至几周都不会再次上网。
查看设备文件后，我看到 firestore 将数据保存在 /data/data/<your-app>/databases 目录下的文件中。
文件看起来像这样
我已经阅读了 firestore 上的离线持久性文档，但没有说明离线持久性有多持久它提到数据被缓存但没有缓存多长时间。我的问题是，Firestore 的离线持久性的持久性如何。有人会推荐使用它而不是使用功能完备的本地数据库来存储可能不会在很长一段时间（几天、几周）内同步的数据吗？
一旦重新建立连接，似乎已经可以很好地处理同步数据。我只是担心在某些时候该文件可能会被系统删除并且用户会丢失所有内容。
官方文档中没有说明离线持久性有多持久，因为它无法预测。这个问题不能有确切的答案，比如 4 周之类的，因为这取决于您离线时发生了多少次写入操作。
我建议您不要将 Cloud Firestore 用作仅离线数据库。它真正被设计为一个在线实时数据库，可以在断开连接的中短时间内工作。
离线时，它会保留所有写入操作的队列。随着此队列的增长，本地操作和应用程序启动将变慢。但是您需要知道，即使您重新启动设备，这些操作也会持续存在。您不会丢失任何数据。
在 Android（截至撰写本文时）Firestore 使用 SQLite 作为持久性机制。因此，对于断断续续的离线 activity，您的性能或耐用性应该没有问题。
但是，如果您要离线几天或几周（如您所说），您应该注意以下事项：
性能
由于 Cloud Firestore 主要用于在线使用，因此尚未同步到服务器的待处理写入将保留在队列中。如果您在没有联机解决它们的情况下执行许多待处理的写入，该队列将会增长并且会降低您的整体 read/write 性能。 Cloud Firestore 的大部分性能保证来自后端的索引和复制，但当您仅离线操作时，这些优化中的大部分都不存在。
冲突
Firestore 的基本冲突解决模型是 "last write wins"。因此，如果您有许多离线客户端写入同一个文档，只有最后一个在线的客户端才会 "win" 并保留他们的更改。
特征
Firestore 的大部分功能都可以离线使用，但有一个主要例外：交易。交易只能在您在线时执行。因此，如果您的应用程序使用交易，如果不进行一些特殊处理，它将无法在离线状态下正常工作。
我目前使用 Firebase Firestore 作为从各种来源检索数据的主要后端。我还使用 Android 的 Room 作为我的移动后端。当 phone 收到数据时，它会存储在 Room 数据库中，以防用户几天甚至几周都不会再次上网。
查看设备文件后，我看到 firestore 将数据保存在 /data/data/<your-app>/databases 目录下的文件中。
文件看起来像这样
我已经阅读了 firestore 上的离线持久性文档，但没有说明离线持久性有多持久它提到数据被缓存但没有缓存多长时间。我的问题是，Firestore 的离线持久性的持久性如何。有人会推荐使用它而不是使用功能完备的本地数据库来存储可能不会在很长一段时间（几天、几周）内同步的数据吗？
一旦重新建立连接，似乎已经可以很好地处理同步数据。我只是担心在某些时候该文件可能会被系统删除并且用户会丢失所有内容。
官方文档中没有说明离线持久性有多持久，因为它无法预测。这个问题不能有确切的答案，比如 4 周之类的，因为这取决于您离线时发生了多少次写入操作。
我建议您不要将 Cloud Firestore 用作仅离线数据库。它真正被设计为一个在线实时数据库，可以在断开连接的中短时间内工作。
离线时，它会保留所有写入操作的队列。随着此队列的增长，本地操作和应用程序启动将变慢。但是您需要知道，即使您重新启动设备，这些操作也会持续存在。您不会丢失任何数据。
在 Android（截至撰写本文时）Firestore 使用 SQLite 作为持久性机制。因此，对于断断续续的离线 activity，您的性能或耐用性应该没有问题。
但是，如果您要离线几天或几周（如您所说），您应该注意以下事项：
性能
由于 Cloud Firestore 主要用于在线使用，因此尚未同步到服务器的待处理写入将保留在队列中。如果您在没有联机解决它们的情况下执行许多待处理的写入，该队列将会增长并且会降低您的整体 read/write 性能。 Cloud Firestore 的大部分性能保证来自后端的索引和复制，但当您仅离线操作时，这些优化中的大部分都不存在。
冲突
Firestore 的基本冲突解决模型是 "last write wins"。因此，如果您有许多离线客户端写入同一个文档，只有最后一个在线的客户端才会 "win" 并保留他们的更改。
特征
Firestore 的大部分功能都可以离线使用，但有一个主要例外：交易。交易只能在您在线时执行。因此，如果您的应用程序使用交易，如果不进行一些特殊处理，它将无法在离线状态下正常工作。