我目前正在重新设计我的一个应用程序，该应用程序通过从网站获取原始数据而不是官方API来更新其内部SQLite数据库。
由于这很容易出错，我想将数据处理从客户端转移到后端服务器。 这个想法是让一个脚本每天在服务器上运行多次 - 类似于之前的客户端行为 - 并将数据存储在Firebase实时数据库中。然后，所有客户端不再需要自己处理数据，而是从Firebase DB请求解析后的数据。
我只是想知道保持数据同步的最佳方法是什么。 我想出了两个想法，但由于我对Firebase不太熟悉，我不知道什么更可取。
首先，我可以想象通过在某些节点上使用keepSynced()和setPersistenceEnabled()来保持客户端上的数据同步。 但我不确定当应用程序处于后台时，这是否会使数据保持最新。我也担心这种方法的电池和网络使用。 第三点是同时连接的数量，我质疑这种方法，每个客户端都会一直连接，对吧？
第二种方法是使用 FCM 在客户端感兴趣的节点之一发生变化时通知客户端，例如使用 Firebase Cloud Functions 侦听事件并触发消息。 然后客户端将goOnline()与数据库同步并再次goOffline()。这将避免大量的连接，并减少电池和网络使用。 但是我不确定如何在离线时将所有数据保留在设备上？ 我不想使用 SQLite 数据库将数据保留在设备上。setPersistenceEnabled()是否足以在设备上保留特定数量的数据库注释？
还是两者兼而有之？根据云消息在所需的节点和goOnline()/goOffline()上设置keepSynced()和setPersistenceEnabled()？
欢迎根据自己的到期日提供任何帮助或建议！
您的第一种方法是尝试确保 Android 应用始终与 Firebase 数据库后端建立开放连接。这之前已经问过/尝试过(见这里，这里)，绝对是可能的。但是您将与Android更新作斗争，这些更新专门试图通过应用程序中的此类行为来减少电池使用量。
第二种方法确实更好。我经常将其称为"推送同步"，因为您正在发送推送通知(通过 FCM)以触发数据同步。(另外：这是"拉动同步"模式的文字游戏，因此许多应用程序都遵循)。使用这种方法的应用程序的一个例子是Google从2016年开始的AndroidI/O应用程序，其代码在Github上。代码有点复杂，但实际的同步在这里，(iirc)它是通过这个触发的。
FCM 对您来说将是一个不错的选择，因为仅使用推送数据而不使用通知，因为这会强制在移动应用程序的 onReceive 方法中接收发送到的数据。如果您的设备处于离线状态，它将在再次联机时再次重新发送数据。
每当后端发生任何更改时，都会使用其预先保存的令牌将推送数据发送到您的设备。