首先，你遇到的核心问题是本地持久化的写入记录堆积（75000+条且持续增长），导致每次应用启动时restoreWrites方法需要遍历巨量数据，直接拖垮了CPU和内存。这不是不可避免的情况，也不用急着迁移到Firestore，先试试下面的修复方案：

一、先定位写入堆积的原因 #

• 检查Firebase控制台的Database规则：如果写入权限配置有问题（比如权限不足、规则限制），会导致大量本地写入无法同步到服务器，一直堆积在本地持久化存储中。
• 排查应用内的写入逻辑：有没有循环中重复写入同一路径、离线时持续生成大量写入，或者网络恢复后没有正常触发同步的情况？这些都会让写入记录越积越多。
• 你可以通过[[[[[reference repo] persistenceManager] storageEngine] writesDB] allKeys]打印具体的写入路径，判断这些是未同步的有效写入，还是历史残留的无效记录。

二、修复方案 #

1. 清理堆积的本地写入记录 #

如果确认是无效的未同步写入（比如权限问题导致永远同步不了的记录），可以调用：

[FIRDatabase database].persistenceManager.purgeOutstandingWrites;

⚠️ 注意：这个操作会清空所有还没同步到服务器的本地修改，一定要确保用户的重要数据已经同步，或者在执行前给用户明确提示。

你也可以做一个阈值判断，比如启动时检查本地写入数量，如果超过某个值（比如1000条），就自动触发清理，避免堆积到数万条的程度。

2. 优化写入操作 #

• 合并批量写入：用updateChildValues代替多次单独的setValue，把多个写入操作合并成一次，减少本地写入记录的数量。
• 避免重复写入：检查代码中是否有重复触发写入的逻辑（比如监听回调中再次写入同一路径），这会快速堆积写入记录。
• 按需控制持久化：对于临时数据的写入（比如状态缓存），可以考虑使用内存级别的存储，或者在写入后及时清理，避免占用持久化空间。

3. 升级Firebase SDK #

旧版本的Realtime Database SDK可能存在持久化写入自动清理的bug，建议升级到最新版本，官方可能已经修复了这类堆积问题。

4. 确保同步正常触发 #

监听设备的网络状态，当网络从离线恢复到在线时，可以主动触发一次同步操作（比如调用目标路径的keepSynced(true)），帮助本地写入尽快同步到服务器，减少堆积。

三、是否需要迁移到Firestore？ #

如果上述方案都无法解决问题，或者你的应用场景更适合Firestore的文档模型、复杂查询能力，再考虑迁移。但迁移需要修改大量代码，成本较高，优先解决当前的写入堆积问题是更高效的选择。

附你提供的性能分析调用栈： #

9.41 min 93.2% 0 s _dispatch_workloop_worker_thread$VARIANT$mp 0x109890
9.41 min 93.2% 0 s _pthread_wqthread
9.41 min 93.2% 0 s _dispatch_workloop_worker_thread$VARIANT$mp
9.41 min 93.2% 0 s _dispatch_root_queue_drain_deferred_wlh$VARIANT$mp
9.41 min 93.2% 0 s _dispatch_queue_invoke$VARIANT$mp
9.37 min 92.9% 0 s _dispatch_queue_serial_drain$VARIANT$mp
9.37 min 92.9% 0 s _dispatch_client_callout
9.37 min 92.9% 0 s _dispatch_call_block_and_release
8.78 min 87.0% 0 s -[FRepo deferredInit]
8.77 min 87.0% 0 s -[FRepo restoreWrites]
7.30 min 72.3% 0 s -[__NSArrayM enumerateObjectsWithOptions:usingBlock:]
6.55 min 64.9% 1.00 ms __22-[FRepo restoreWrites]_block_invoke
5.69 min 56.3% 4.00 ms -[FSyncTree applyUserMergeAtPath:changedChildren:writeId:]
5.67 min 56.2% 8.00 ms -[FWriteTree addMergeAtPath:changedChildren:writeId:]
5.63 min 55.8% 5.00 ms -[FCompoundWrite addCompoundWrite:atPath:]
5.63 min 55.8% 0 s -[FImmutableTree forEach:]
5.63 min 55.8% 1.00 ms -[FImmutableTree forEachPathSoFar:withBlock:]
3.43 min 34.0% 1.00 ms -[FArraySortedDictionary enumerateKeysAndObjectsReverse:usingBlock:]
3.42 min 33.9% 3.00 ms __45-[FImmutableTree forEachPathSoFar:withBlock:]_block_invoke
3.32 min 32.9% 7.00 ms -[FImmutableTree forEachPathSoFar:withBlock:]
3.31 min 32.8% 6.00 ms __42-[FCompoundWrite addCompoundWrite:atPath:]_block_invoke
3.22 min 31.9% 9.00 ms -[FCompoundWrite addWrite:atPath:]

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