Android Firebase-.setPersistenceEnabled（true）时启动时间慢

Question

我正在开发一个简单的APOD应用程序，在其中显示RecyclerView用户可以滚动浏览的天文学图片。我启用了FirebaseDatabase.setPersistenceEnabled(true);此功能，以便用户可以离线使用该应用程序并减少连接/下载带宽。问题是，如果我设置FirebaseDatabase.setPersistenceEnabled(true);，我的应用程序启动时间会明显更长（启用6秒与禁用1.5秒）。我了解用户首次启动应用程序时，加载时间应该更长（因为设置了持久性），但是，由于应用程序不查询在线Firebase服务器，因此随后的每次启动应用程序都不应显着缩短吗？

为了避免一次加载很多行，我SingleValueEventListeners逐一触发了两行。第一个加载100行，并使用循环遍历databaseSnapshot AsyncTask，然后显示图像。然后，我调用第二个，SingleValueEventListener并以相同的方式遍历第二个。第二个SingleValueEventListener加载剩余的数据，范围是101-7000。

下面是我的GlobalApp延伸课程Application。这是我启用持久性的地方。接下来的2种方法是我加载数据的位置。

扩展应用程序类别

public class GlobalApp extends Application {

@Override
public void onCreate() {
    super.onCreate();

    FirebaseDatabase mDatabaseReference = FirebaseDatabase.getInstance();

    mDatabaseReference.setPersistenceEnabled(true);

    }
}

初始负荷

 private void initialLoad() {

    databaseReference.child("apod").orderByChild("date").limitToLast(100).addListenerForSingleValueEvent(new ValueEventListener() {
        @Override
        public void onDataChange(DataSnapshot dataSnapshot) {

            new LoadFirebase().execute(dataSnapshot);

        }

        @Override
        public void onCancelled(DatabaseError databaseError) {

        }
    });

}

二次负荷

private void secondLoad() {

   final String secondKey = firebaseKeys.get(firebaseKeys.size() - 1);

    databaseReference.child("apod").orderByChild("date").endAt(secondKey).addListenerForSingleValueEvent(new ValueEventListener() {
        @Override
        public void onDataChange(DataSnapshot dataSnapshot) {

            new SecondLoadFirebase().execute(dataSnapshot);

        }

        @Override
        public void onCancelled(DatabaseError databaseError) {

        }
    });

}

如果我使用启动应用程序FirebaseDatabase.setPersistenceEnabled(true);，则Logcat填写以下内容：

04-18 18:22:22.649 2884-2915/com.foo.apod W/CursorWindow: Window is full: requested allocation 1344 bytes, free space 752 bytes, window size 2097152 bytes
04-18 18:22:22.733 2884-2915/com.foo.apod W/CursorWindow: Window is full: requested allocation 1821 bytes, free space 1124 bytes, window size 2097152 bytes
04-18 18:22:22.798 2884-2915/com.foo.apod W/CursorWindow: Window is full: requested allocation 1580 bytes, free space 1516 bytes, window size 2097152 bytes
04-18 18:22:22.868 2884-2915/com.foo.apod W/CursorWindow: Window is full: requested allocation 1574 bytes, free space 656 bytes, window size 2097152 bytes
04-18 18:22:22.920 2884-2915/com.foo.apod W/CursorWindow: Window is full: requested allocation 1455 bytes, free space 228 bytes, window size 2097152 bytes
04-18 18:22:22.973 2884-2915/com.foo.apod W/CursorWindow: Window is full: requested allocation 1579 bytes, free space 1000 bytes, window size 2097152 bytes
04-18 18:22:23.055 2884-2915/com.foo.apod W/CursorWindow: Window is full: requested allocation 1557 bytes, free space 756 bytes, window size 2097152 bytes
04-18 18:22:23.120 2884-2915/com.foo.apod W/CursorWindow: Window is full: requested allocation 1263 bytes, free space 620 bytes, window size 2097152 bytes

随后是一堆GC调用：

04-18 18:22:26.290 2884-2891/com.foo.apod I/art: Background partial concurrent mark sweep GC freed 171401(23MB) AllocSpace objects, 0(0B) LOS objects, 15% free, 85MB/101MB, paused 2.120ms total 151.451ms
04-18 18:22:29.153 2884-2891/com.foo.apod I/art: Background partial concurrent mark sweep GC freed 552106(22MB) AllocSpace objects, 4(1096KB) LOS objects, 15% free, 84MB/100MB, paused 868us total 158.171ms
04-18 18:22:29.647 2884-2891/com.foo.apod I/art: Background sticky concurrent mark sweep GC freed 211953(18MB) AllocSpace objects, 0(0B) LOS objects, 14% free, 85MB/100MB, paused 2.590ms total 114.968ms
04-18 18:22:30.122 2884-2891/com.foo.apod I/art: Background sticky concurrent mark sweep GC freed 482294(17MB) AllocSpace objects, 43(3MB) LOS objects, 3% free, 96MB/100MB, paused 1.440ms total 100.242ms
04-18 18:22:31.091 2884-2906/com.foo.apod V/FA: Inactivity, disconnecting from the service

看来问题可能出在SQLite上，因为Firebase在那里存储了数据。我将Stetho添加到我的应用程序中，并尝试在浏览器中查看数据库（认为我以某种方式在启用持久性的情况下创建了重复项），但是我无法访问该数据库，它什么也没显示。

有人知道为什么会这样吗？花了永远的时间才找出问题的根源。

如果您需要其他代码，请告诉我。

谢谢

Answer 1

不幸的是，Firebase Realtime Database并未对其离线查询实现属性索引。如果您在某个位置（在您的情况下为/ apod）进行查询，则即使只有很少的数目（100甚至是1），也需要扫描该位置的所有缓存数据才能找到匹配的结果）匹配您的查询。因此，我认为您的速度缓慢可能是由于扫描了已存储的7000多个条目。

作为一种解决方法，如果您可以组织数据以使您可以在更细的位置进行读取（例如/ apod / 2017/04 /带有〜30个要查询的条目），则可能会大大加快速度。