ContentProviderとCursorLoaderによる多方向ViewPagerのパフォーマンスの問題

Question

SupportViewPagerを含むアクティビティに基づいて、またその中にVerticalViewPagersを含むフラグメントである、MultiDirectional Pagingアプリケーションを作成しようとしています。どちらのViewPagerもFragmentStatePagerAdapterを使用しており、データはCursorLoadersを介してロードされたContentProviderから取得しています。垂直フラグメントには、水平フラグメントと垂直フラグメント位置の名前を持つ単なるTextViewが含まれています。

私が遭遇している問題は、水平に最後までページを何度もやり直すと、UIが遅れてしまうことです。これを行うほど、遅れが増え、最終的にUIが更新されることなく、最初から最後までページングすることができます。水平方向にページを重ねるほど、UIの遅れは悪化します。

厳密なモードを有効にして、UIスレッドで作業が多すぎるかどうかを確認しましたが、そうではありません。私はまた、LeakCanaryがメモリリークを見つけることができるかどうかを調べようとしましたが、まだ何も見つけていません。

Traceview経由でトレースを開始したばかりですが、まだ始まったばかりなので、私はまだ問題を特定していません（Traceviewもあまりよく知らないけど、それに取り組んでいます）。

ここでは、水平方向に少しずつページングした後、最後にページングするときのAndroidモニターの外観を示します。ページングが垂直方向にうまく動作することに気づくでしょう。

ここに表示されているスパイクは、VSync Delayとして色分けされています。また、アプリケーションを実行してそこに置くと、ガベージコレクタが実行されるまでメモリが徐々に上昇し、メモリがクリアされ、ゆっくりと上昇が再び続くことに気付きました。

私の最初の考えは、ローダーが間違っているか、ローダーとネストされたViewPagersに問題があることです。

ここで何を試みているのか、ローダーなどで間違っていることが根本的に間違っていますか？私はこれを掘り下げていくつもりですが、その間に私の問題が何であるか他の人から何か考えを得ることを望んでいました。

私はあなたがプロジェクトをプルダウンし、それを実行し、最初のアプリの起動時に使用すると、ツールバーにある「+」ボタンをクリックする必要があります場合はhttps://github.com/hooked82/MultiDirectionalPaging

で発見することができ、非常に基本的なサンプルアプリケーションを作成しましたデータベースを作成します。それはジョーの答えパーhttps://github.com/castorflex/VerticalViewPager

UPDATE 2016年8月1日 からVerticalViewPagerを使用している

VerticalViewPagerのアダプタをスワップアウトするとき、原因がinflationsとビューの破壊の量です。アダプタを新しいデータで更新しないバグが原因で、私のカスタムFragmentStatePagerAdapterにswapCursor（）を実装できませんでした。私がswapCursor（）を実装するのであれば、良好な水平ページングを得ることができますが、データセットの変更を通知されたときにアダプタのUIは更新されません。

カスタムCursorRecyclerViewのためにVerticalViewPagerを交換して、同じ機能を得ることができましたが、RecyclerViewの適切なタイミングを設定してVerticalViewPagerを模倣する必要があります。

助けてくれてありがとう、ジョー！

Answer 1

問題は、水平スクロールで発生するフラグメントトランザクションの数です。

1）任意のビューページャには、最大で3つのフラグメントが表示されます。位置v1の垂直線については、3つの断片v0、v1およびv2がある。 v1からv2にスクロールすると、v0のフラグメントが破棄され、v3が次のスクロールを予期して作成されます。

したがって、垂直スクロールごとに、最大2つのフラグメント操作が発生することがあります。

2）同じことが水平方向に存在します。位置h1にフラグメントh0、h1、h2が作成されているとします。今度は、縦方向の断片も作成されるので、各水平方向の断片に対して最大3つの垂直断片があります。今、物事は面白いです。あなたが各水平フラグメントのv1であると仮定すると、次のようになります（悪い場合）h1からh2にスクロールします。最初のh0は破壊されますが、h0が所有するv0、v1、v2フラグも破棄されます。次に、最小v0/v1でh3が作成されます。しかし、以前にv1にスクロールした場合は、その位置を覚えていてv2も作成します。

したがって、水平スクロールごとに、最小6回のフラグメント操作と最大8回のスクロール（つまり、最大4倍の高価）が発生します。インフレーション/クリーンアップを見ると、これは本当に速く乗算され、パフォーマンスの問題を引き起こします。

少なくとも、垂直スクロールを処理するにはリサイクラビューを使用する方がよいでしょう。おそらく、スクロール・イベントをインターセプトして、ビュー・ページャーが部分スクロールで実行するページをスナップする「シミュレート」する必要があります。