Android Room相对于Cloud Firestore的持久本地存储有何优势？

Question

我的Android应用程序使用大量的结构化数据来向用户提供合适的建议，因此本地数据库似乎很合适。Room / DAO / ViewModel看起来是一个不错的体系结构，并且对底层实现有足够的抽象。里面的数据不会经常改变，并且一旦改变就只能单向流动：从服务器一直到用户设备中的本地数据库，再也没有其他方式。即使该应用很可能定期在线，对于大多数查询还是可以从本地数据进行处理的。

我正在使用Google Firebase处理后端服务，并使用Cloud Firestore数据库存储数据在服务器端。Firestore为脱机使用提供了用户数据的本地缓存，这比实现和同步自己的数据库要简单得多。是否有充分的理由避免这种方法？

还有一些类似的问题，例如： Firestore作为离线持久性机制的可靠性如何？或Firebase Cloud Firestore中的部分脱机同步。我认为这是不同的，因为我不是在寻找长期的离线持久性，而是一个可靠的本地副本，以避免不必要的数据传输。

Answer 1

这两种类型的数据库之间存在巨大差异。该厅持久性库提供了SQLite的一个抽象层，允许更强大的数据库访问，同时云计算公司的FireStore是为移动，网络和服务器开发的灵活，可扩展的实时数据库。

Firestore并非设计为用作唯一的脱机数据库，而是可以用作Room的，而是将其设计为在线实时数据库，可以在短时间到中间断开期间工作。Cloud Firestore使用SQLite作为其持久性机制。因此，如果您说用户主要是在线的，那么您的性能或耐用性就不会有问题。

其中的数据不会经常更改，并且当它发生时仅会单向流动：

如果您决定在某个时间点更改此流程，请记住，当用户设备脱机时，尚未同步到服务器的挂起的写入将保留在队列中。如果您没有在线同步就执行太多写操作，则该队列将快速增长，并且不仅会减慢写操作的速度，还会减慢您的读操作的速度。

因此，如果您考虑使用Cloud Firestore的离线持久性功能，请注意，默认情况下，此功能实际上已在Android和iOS上启用，因此您无需执行任何操作。

并回答您的第一个问题：

Android Room相对于Cloud Firestore的持久本地存储有何优势？

我已经说过，这两个数据库都是不同的，并且用途不同，但是对于您的用例（考虑使用合理的限制），Firestore数据库的缓存副本将帮助您解决这一问题。