我正在开发一个简单的 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/