关于Firebase实时数据库离线同步队列及免费版限制的技术咨询

Hey there! Let's break down your questions based on your Kotlin + Firebase setup and that offline sync code you shared.

问题1：当离线同步队列中仍有待同步表单时关闭应用，会出现什么情况？ #

No need to worry about losing those pending submissions—Firebase handles this automatically:

• The Firebase Realtime Database SDK persists all pending write operations (like your setValue(inspec) call) to a local SQLite database on the device. These operations won't disappear when you close the app.
• When you reopen the app later and the device regains internet access, the SDK will automatically detect the pending operations in the local queue and sync them to the cloud in the order they were created.
• If a sync fails (due to network issues, permission problems, etc.), the SDK will retry automatically until the operation succeeds or you manually cancel it (using methods like cancelPendingWrites()).

问题2：该同步队列是否存在限制（如大小、表单数量），尤其是Firebase实时数据库免费版的限制情况？ #

Let's split this into two parts: the queue itself, and the free-tier specific limits.

同步队列本身的限制 #

• The Firebase SDK doesn't have a hard-coded limit on the number or total size of pending operations in the offline queue. That said, you're constrained by the device's local storage—if you have hundreds of large pending forms, you'll eventually eat up the device's available space, which could cause app issues.
• A single write operation (like one Inspection object) can't exceed 16MB—this is a global limit for Firebase Realtime Database, whether you're online or offline. If your future image-included forms cross this threshold, the write will fail immediately and won't be added to the queue.

Firebase免费版（Spark计划）的额外限制 #

These quota limits will impact your offline sync once the operations go online:

• Cloud Storage: The free tier only gives you 1GB of cloud storage. If the total data from your pending forms plus existing cloud data exceeds this, syncs will fail.
• Bandwidth: You get 10GB of download bandwidth and 1GB of upload bandwidth per day. A flood of offline submissions syncing at once could burn through this quota quickly, blocking further syncs until the quota resets.
• Concurrent Connections: The free tier allows up to 100 concurrent connections. This mostly affects real-time read syncs, but if dozens of devices are syncing offline forms at the same time, you might hit this limit temporarily.

小提示：关于你的代码 #

You called ref.keepSynced(true) in your code—this keeps the Inspections node synced with the cloud for read operations (great for keeping local data fresh). But write operations' offline sync is enabled by default in Firebase, so you don't need this line specifically for pending submissions. It's still useful if your app needs to read the Inspections data in real-time, though.

Here's your code for reference:

val ref = FirebaseDatabase.getInstance().getReference("Inspections")
ref.keepSynced(true)
val fdbTubingId = ref.push().key
val inspec = Inspection(ds, fdbTubingId.toString(), uniqueID, fac, ss, tid, fType, Q1Aa, Q1Bb, Q1Cc, Q1CComment, Q2Aa, Q2Bb, Q2Cc, Q2Dd, Q2CComment, Q3Aa, Q3Bb, Q3CAa, Q3CBb, Q3CCc, Q3CComment, Q4Aa, Q4Bb, Q4Cc, Q4Dd, Q4CComment, Q5Aa, Q5Bb, Q5CComment, Q6Aa, Q6CComment)
if (fdbTubingId != null) {
    ref.child(fdbTubingId).setValue(inspec).addOnCompleteListener {
        Toast.makeText(applicationContext, "Inspection saved successfully", Toast.LENGTH_LONG).show()
    }
}

内容的提问来源于stack exchange，提问作者Tiuing Gum