Firebase Android离线性能

当在单个节点下存储大约5000个子节点时，当使用脱机功能时，初始化firebase变得非常缓慢。执行第一个查询大约需要30秒。初始化后，执行后续查询（例如列出前25个子节点）所需时间不到一秒钟

我正在使用以下属性来启用脱机功能： Firebase.getDefaultConfig（）.setPersistenceEnabled（true）； firebase.keepSynced（真）

我的结构如下所示：

<root>
 |-my-app-name
   |-<uid>
     |-node
       |-sub node 1
       |-...
       |-sub node 5000

---

PS：这是一个交叉帖子：

初始化意味着

设置值

到该节点，对吗？因此，在一个节点下初始化5000个子节点大约需要30秒对我来说是非常不寻常的。我曾在一个节点下处理过几乎相同大小的数据，但性能要好得多。因此，我不确定在单个子节点下放置了多少属性，但无论如何，我想您需要再次检查性能。我认为您正在使用

setValue

上的

onCompleteListener

来计算初始化数据所花费的时间，因为UI视图没有提供准确的时间，并且通常比实际操作时间慢

最好，我想列出所有（而不是每页25），但我 请理解，这是不可能的，因为没有类似游标的 机制（如Android为SQLite提供的）可用于 火基

虽然我不太确定您的目的，但对于这类情况，我可以建议您同时维护Sqlite和Firebase数据库。让我澄清一下

其想法是在用户的手机中为特定用户维护相同的Firebase数据库副本。因此，本地数据库可以在需要时完全满足您的需要。您可以查询数据库，并可以使用您有过丰富经验的

CursorLoader

它还有其他一些优点。您可以使用自己的机制处理脱机同步。当internet关闭时，将要同步的数据存储在本地Sqlite数据库中，然后当连接打开时，您将在

广播接收器中得到一个回调。然后，您可以轻松地
setValue
将脱机数据传输到Firebase。当然，Firebase让这变得更简单，但无论如何，由于您非常关心性能，您可以尝试一下

当您的应用程序做了太多工作时，您发布的GC的行为是常见的。Firebase基本上使用
WebSocket
来维护与远程数据库的连接。因此，我认为您需要检查是否与Firebase数据库保持不必要的连接。当不再需要侦听器时，尝试使用
RemovelListener

Firebase在初始化时是否评估整个数据库

我还不确定你所说的初始化是什么意思，但是是的，如果你为
setValue
再次将同一个节点带到该节点，它会用新的数据集替换以前的数据
 因此，对数据进行分片，使一个根节点最多包含200个子节点似乎是目前的答案。我正在对碎片设置.keepSynced（true），这将导致更好的性能

为了在单个回收器视图中显示分片列表，我创建了一个类FirebaseArray，它是FirebaseArray的集合，将多个数组聚合到一个可观察的集合中。


我还修改了FirebaseRecyclerAdapter，将FirebaseArray用作底层数据结构，而不是单个FirebaseArray。使用一些方法扩展接口，以添加额外的Firebase路径（即碎片）。


这些路径在“加载更多”事件时添加（例如，在无休止滚动的情况下）

private void loadMore（）{
最终视图=getView（）；
if（null！=视图）{
final RecyclerView RecyclerView=（RecyclerView）视图.findViewById（R.id.recycler\u视图）；
最终FirebaseRecyclerAdapter2适配器=（FirebaseRecyclerAdapter2）recyclerView.getAdapter（）；
addQuery（nextQuery（））；
}
}
从磁盘上的数据构建内部数据模型需要时间。虽然该过程可能在Firebase SDK中得到优化，但您无法控制。您唯一的控制是缓存更少的数据。将.keepSynced（true）设置为多个“子”路径而不是单个“根”路径是否有帮助？例如，.keepSynced（true），.keepSynced（true）等，而不是.keepSynced（true）？换句话说，数据模型是作为一个整体读取的，还是针对单个Firebase路径（例如，当第一次访问该路径时）的延迟读取的？@Niels您找到解决方案了吗？@VonD我正在尝试对数据进行分片，以便一个根节点最多包含200个子节点。我正在设置。在碎片上保持同步（正确），第一印象是性能要好得多。但由于这是一个周日下午的项目，我还没有找到时间来验证我所有的假设。一旦我有了，我会发布一个明确的答案。@Niels好的，非常感谢>初始化意味着该节点的setValue，对吗？否，在firebase.setContext（）和firebase.getDefaultConfig（）.setPersistenceEnabled（true）中初始化firebase。我在我的Android应用程序子类onCreate（）方法中执行这些操作。为了澄清，已经创建了5000个节点。当我想列出这些节点（例如，在RecyclerView中）时，我会看到在执行实际查询之前有很长（约30秒）的初始延迟。>Firebase基本上使用WebSocket来维护与远程数据库的连接。<当我在Android Studio中查看网络使用率图表时，网络使用率是零对零。当我禁用网络访问时（例如，通过禁用测试设备上的WiFi），也会出现此问题。
04-01 15:59:12.029 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 43005(1717KB) AllocSpace objects, 0(0B) LOS objects, 4% free, 31MB/32MB, paused 5.674ms total 57.402ms
04-01 15:59:13.415 2222-2240/abcdef W/art: Suspending all threads took: 6.600ms
04-01 15:59:13.424 2222-2245/abcdef W/art: Suspending all threads took: 9.339ms
04-01 15:59:13.433 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 7097(281KB) AllocSpace objects, 0(0B) LOS objects, 0% free, 32MB/32MB, paused 11.175ms total 27.105ms
04-01 15:59:13.821 2222-2245/abcdef I/art: Background partial concurrent mark sweep GC freed 101674(5MB) AllocSpace objects, 18(530KB) LOS objects, 35% free, 28MB/44MB, paused 3.400ms total 152.664ms
04-01 15:59:15.107 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 394024(15MB) AllocSpace objects, 0(0B) LOS objects, 20% free, 30MB/38MB, paused 1.865ms total 152.182ms
04-01 15:59:15.817 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 218328(8MB) AllocSpace objects, 0(0B) LOS objects, 19% free, 31MB/38MB, paused 1.711ms total 112.325ms
04-01 15:59:16.451 2222-2240/abcdef W/art: Suspending all threads took: 27.786ms
04-01 15:59:16.465 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 190591(7MB) AllocSpace objects, 0(0B) LOS objects, 18% free, 31MB/38MB, paused 1.832ms total 107.416ms
04-01 15:59:16.472 2222-2245/abcdef W/art: Suspending all threads took: 6.823ms
04-01 15:59:17.084 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 178714(6MB) AllocSpace objects, 0(0B) LOS objects, 15% free, 32MB/38MB, paused 1.717ms total 105.529ms
04-01 15:59:17.629 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 163584(6MB) AllocSpace objects, 0(0B) LOS objects, 14% free, 33MB/38MB, paused 1.743ms total 110.764ms
04-01 15:59:18.941 2222-2240/abcdef W/art: Suspending all threads took: 5.078ms
04-01 15:59:19.691 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 95627(3MB) AllocSpace objects, 0(0B) LOS objects, 8% free, 35MB/38MB, paused 7.190ms total 86.171ms
04-01 15:59:19.961 2222-2240/abcdef W/art: Suspending all threads took: 18.208ms
04-01 15:59:20.965 2222-2245/abcdef W/art: Suspending all threads took: 5.254ms
04-01 15:59:20.990 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 55899(2MB) AllocSpace objects, 0(0B) LOS objects, 5% free, 36MB/38MB, paused 6.799ms total 66.923ms
04-01 15:59:22.495 2222-2240/abcdef W/art: Suspending all threads took: 45.180ms
04-01 15:59:22.509 2222-2245/abcdef W/art: Suspending all threads took: 14.254ms
04-01 15:59:22.562 2222-2245/abcdef I/art: Background partial concurrent mark sweep GC freed 198174(6MB) AllocSpace objects, 3(487KB) LOS objects, 32% free, 33MB/49MB, paused 16.949ms total 215.369ms
04-01 15:59:23.811 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 392437(15MB) AllocSpace objects, 0(0B) LOS objects, 18% free, 35MB/43MB, paused 1.936ms total 168.222ms
04-01 15:59:24.480 2222-2240/abcdef W/art: Suspending all threads took: 22.464ms
04-01 15:59:24.497 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 227043(8MB) AllocSpace objects, 0(0B) LOS objects, 18% free, 35MB/43MB, paused 1.723ms total 117.855ms
04-01 15:59:25.173 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 203910(7MB) AllocSpace objects, 0(0B) LOS objects, 16% free, 36MB/43MB, paused 1.694ms total 112.618ms
04-01 15:59:25.181 2222-2245/abcdef W/art: Suspending all threads took: 7.301ms
04-01 15:59:25.784 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 185627(7MB) AllocSpace objects, 0(0B) LOS objects, 14% free, 37MB/43MB, paused 1.719ms total 115.362ms
04-01 15:59:26.345 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 167066(6MB) AllocSpace objects, 0(0B) LOS objects, 13% free, 37MB/43MB, paused 1.651ms total 106.055ms
04-01 15:59:26.865 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 154535(6MB) AllocSpace objects, 0(0B) LOS objects, 11% free, 38MB/43MB, paused 1.644ms total 104.888ms
04-01 15:59:28.357 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 151375(5MB) AllocSpace objects, 33(671KB) LOS objects, 9% free, 39MB/43MB, paused 2.740ms total 104.176ms
04-01 15:59:29.006 2222-2240/abcdef W/art: Suspending all threads took: 19.232ms
04-01 15:59:29.060 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 133554(5MB) AllocSpace objects, 29(580KB) LOS objects, 10% free, 39MB/43MB, paused 1.563ms total 100.220ms
04-01 15:59:30.173 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 131062(4MB) AllocSpace objects, 31(637KB) LOS objects, 9% free, 39MB/43MB, paused 1.653ms total 102.705ms
04-01 15:59:31.245 2222-2245/abcdef I/art: Background sticky concurrent mark sweep GC freed 122085(4MB) AllocSpace objects, 26(522KB) LOS objects, 8% free, 39MB/43MB, paused 2.380ms total 100.776ms
04-01 15:59:32.024 2222-2240/abcdef W/art: Suspending all threads took: 20.662ms

private void loadMore() {

    final View view = getView();
    if (null != view) {
        final RecyclerView recyclerView = (RecyclerView) view.findViewById(R.id.recycler_view);
        final FirebaseRecyclerAdapter2<Visit, VisitViewHolder> adapter = (FirebaseRecyclerAdapter2<Visit, VisitViewHolder>) recyclerView.getAdapter();
        adapter.addQuery(nextQuery());
    }
}