2016-04-04 10 views
8

1つのノードの下に約5000個のサブノードを保存すると、オフライン機能を使用するとファイアベースの初期化が非常に遅くなります。最初のクエリが実行されるまでに30秒かかります。一度初期化されると、後続のクエリを実行する(例えば、最初の25のサブノードをリストする)には、1秒未満がかかる。Firebase Androidのオフラインパフォーマンス

私はオフライン機能を有効にするために以下のプロパティを利用しています: Firebase.getDefaultConfig()。setPersistenceEnabled(true); firebase.keepSynced(true);

私の構造は次のようになります。同期

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

キープが<uid>ノードに設定されています。サブノードはRecycler Viewに表示されます。できれば、私はすべてのリストを(25ページではなく)リストしたいと思いますが、Firebaseを操作するために利用できるカーソルのような機構(AndroidがSQLite用に提供しているようなもの)がないので、これは不可能であると理解しています。

これは設計によるものですが、私のデータ構造を改訂しますか?または、別の方法で初期化時間を短縮できますか?

以下にいくつかのログを提供しました。ご覧のとおり、多くのガーベジコレクションが行われています。 Firebaseは初期化時にデータベース全体を評価しますか?

ありがとうございます! ニールス

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 

PS:これは、クロスポストです:https://groups.google.com/forum/#!topic/firebase-talk/migEAwv26ns

+2

ディスクのデータから内部データモデルを構築するには時間がかかります。プロセスがFirebase SDKで最適化される可能性はありますが、そのプロセスを制御する方法はありません。唯一のコントロールは少ないデータをキャッシュすることです。 –

+0

.keepSynced(true)を単一の 'root'パスの代わりに複数の 'sub'パスに設定すると便利ですか?例えば。 .keepSynced(true)、 .keepSynced(true)などの代わりに.keepSynced(true)? つまり、個々のFirebaseパス(たとえば、初めてパスにアクセスしたときなど)に対して、データモデルが全体または遅延して読み込まれていますか? – Niels

+0

@Nielsあなたは解決策を見つけましたか? – VonD

答えて

0

したがって、1つのルートノードに最大200のサブノードが含まれるようにデータをシャーディングすると、今のところ答えがあるようです。私は設定しています.keep(true)をshardに設定すると、パフォーマンスが大幅に向上します。

シャードリストを1つのリサイクラビューに表示するために、FirebaseArrayのクラスであるFirebaseArraysクラスを作成しました。このクラスは、複数の配列を単一の観測可能なコレクションに集約します。
https://gist.github.com/ndefeijter/2191f8a43ce903c5d9ea69f02c7ee7e9

Iはまた、代わりに単一FirebaseArrayの基礎となるデータ構造としてFirebaseArraysを使用するFirebaseRecyclerAdapter適応。インターフェースは、いくつかの方法を使用して拡張され、Firebaseパス(すなわち、シャード)を追加する。
https://gist.github.com/ndefeijter/d98eb5f643b5faf5476b8a611de912c1

これらのパスは、「負荷の高い」イベント(たとえば、無限のスクロールの場合)で追加されます。

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()); 
    } 
} 
1

の初期化は、そのノードの右にsetValueを意味しますか?したがって、〜30秒かかる単一のノードの下で5000のサブノードを初期化することは、私にとっては非常に珍しいようです。私は、パフォーマンスがはるかに優れ、単一のノードでほぼ同じサイズのデータ​​を処理しました。ですから、あなたは単一のサブノードの下にどれくらいの属性を置いているのか分かりませんが、とにかくパフォーマンスを再度確認する必要があります。私はonCompleteListenersetValueに使って、データを初期化するのに費やした時間を計算していると思います。UIビューは正確な時間を提供せず、実際の動作時間よりも遅いことが多いからです。

好ましくは、 での作業のために利用可能(AndroidはSQLiteのために提供される)私は(代わりにページごとの25の)すべての一覧を表示したいと思いますが、 メカニズムのような何もカーソルが存在しないので、私はこれが不可能であることを理解し ファイアベース。

私はあなたの目的についてはあまりよく分かりませんが、これらのタイプのケースでは、SqliteとFirebaseの両方のデータベースを維持することをお勧めします。私を明確にしましょう。

アイデアは、ユーザーの電話機内の特定のユーザーのFirebaseデータベースの同じコピーを維持することです。必要に応じてローカルデータベースが目的を完全に果たすことができるようにします。あなたはデータベースを照会することができ、あなたは一握りの経験を持ってCursorLoaderを使うことができます。

その他の利点もあります。独自のメカニズムでオフライン同期を処理できます。インターネットがダウンしている場合は、後で同期するデータをローカルのSqliteデータベースに保存し、接続が確立したらBroadcastReceiverでコールバックを取得します。その後、簡単にsetValueのオフラインデータをFirebaseに送信することができます。Firebaseはこれをもっと簡単にしますが、とにかく、パフォーマンスを非常に心配しているので、これを試すことができます。

投稿したGCの動作は、アプリケーションがあまりにも多くの作業をしているときには通常です。 Firebaseは基本的にWebSocketを使用してリモートデータベースへの接続を維持します。 Firebaseデータベースへの不要な接続を維持しているかどうかを確認する必要があると思います。リスナーが不要になったときにremoveListenerを使用してください。

Firebaseは初期化時にデータベース全体を評価しますか?

私は、あなたが初期化することによって意図した内容はまだわからないんだけど、あなたはそのノードへsetValueのために再度同じノードを取っている場合は、はい、それはデータの新しいセットと以前のデータに置き換えられます。

+0

>初期化とは、そのノードのsetValueを意味しますか? いいえ、Firebase.setContext()およびFirebase.getDefaultConfig()。setPersistenceEnabled(true)のようにfirebaseを初期化しています。私はAndroidアプリケーションサブクラスのonCreate()メソッドでそれらを行います。明確にするために、すでに5000のノードが作成されています。 これらのノードを一覧表示する場合(RecyclerViewなど)、実際のクエリが実行されるまでに非常に長い(〜30秒)初期遅延があります。 – Niels

+0

> Firebaseは基本的にWebSocketを使用してリモートデータベースへの接続を維持します。 < Androidスタジオの[ネットワーク使用状況]グラフを確認すると、ネットワークの使用率はゼロになります。この問題は、ネットワークアクセスを無効にすると発生します(テストデバイスでWiFiを無効にするなど)。 – Niels

関連する問題