Android Firebase - .setPersistenceEnabled(true) 时启动时间缓慢

标签 android firebase firebase-realtime-database

我正在开发一个简单的 APOD 应用程序,其中显示用户可以滚动浏览的天文图片的 RecyclerView。我启用了 FirebaseDatabase.setPersistenceEnabled(true);,以便用户可以离线使用该应用并减少连接/下载带宽。问题是,如果我设置 FirebaseDatabase.setPersistenceEnabled(true);,我的应用程序启动时间会明显更长(启用 6 秒 vs 禁用 1.5 秒)。我知道用户第一次启动应用程序时,加载时间应该更长(因为设置了持久性),但应用程序的每次后续启动是否都应该显着缩短,因为它不查询在线 Firebase 服务器?

为了避免一次加载多行,我依次触发两个 SingleValueEventListener。第一个加载 100 行并使用 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到我的应用程序并尝试在浏览器中查看数据库(认为我以某种方式创建启用了持久性的重复项),但我无法访问数据库,它什么也没显示。

有人知道为什么会发生这种情况吗?花了很长时间才找出问题的根源。

如果您需要更多代码,请告诉我。

谢谢

最佳答案

遗憾的是,Firebase 实时数据库未实现其离线查询的属性索引。如果您在某个位置(在您的情况下为/apod)执行查询,则需要扫描该位置的所有缓存数据才能找到匹配的结果,即使只有少量(100 甚至 1 )与您的查询匹配。所以我认为您的缓慢可能是由于扫描了您存储的 7000 多个条目。

作为一种解决方法,如果您可以组织数据,以便可以在更细粒度的位置读取(例如/apod/2017/04/有大约 30 个条目可供查询),这可能会大大加快速度。

关于Android Firebase - .setPersistenceEnabled(true) 时启动时间缓慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43483953/

相关文章:

android - 在最后一步使用 HoloEverywhere 时出错

android - 将数据从一个 fragment 传递到另一个 fragment 的空指针异常

javascript - 使用 Firebase 监听嵌套更改的正确方法是什么?

javascript - 使用 FireBase 在 Ionic 3 中获取带有列名称的值

java - 无法以编程方式启动 DialogPreference(抛出空指针异常)

java - 从Firebase数据库获取最后一个节点到textview android

firebase - Firestore读取具有自身条件的规则

javascript - 在 LoginService 中等待加载的用户数据

java - 获取包含具有特定值的子对象的节点

java - 改变 Activity 方向的填充