1

ActionBar のタブを使用して UI を操作しています。タブを切り替えるとき、現在アクティビティでタブクリックイベントを管理しており、FragmentManager を使用して必要に応じてアタッチとデタッチを呼び出しています。

フラグメントがアタッチされるたびに、ライフサイクル全体を実行し、新しいビューを作成して、すべてのデータを再度ロードします。onSaveInstanceState と onActivityCreated で指定された Bundle を使用して、GUI 要素 (主にリストのスクロール位置) を更新しています。

これは正常に機能していますが、多くのオーバーヘッドがあります。私の場合、リストには 300 ほどのレコードが含まれている可能性があり、タブを切り替えるときに顕著な遅延が発生します。

速度を上げるために、ルート ビューを onCreateView にクラス変数として保存しています。次に、フラグメントがアタッチされた結果として onCreateView が再度呼び出されると、ルート ビューの非 null 値をテストし、ビューを再膨張させる代わりにそれを返します。この保存されたビューにはまだ適切なデータ セットがあり、この場合はデータの読み込みもバイパスします。もちろん、バックグラウンドで OS によって Fragment が破棄された場合は、ビューとデータを完全に再構築する必要があります。

私の質問は、これが有効なアプローチであるかどうかです。心配するメモリの問題がない限り、マイナス面はありません。

4

1 に答える 1

1

これは最善の方法ではありません。その理由は次のとおりです。

最初にルート ビューを作成すると、すべてのビューがActivityのコンテキストを使用して膨張します。これが破棄されてから、 を this の新しいインスタンスにActivity再アタッチしようとすると、問題が発生します。FragmentActivity

第 2 に、ルート ビューが使用されていないときに、完全に膨張したルート ビューをそのままにしておくと、メモリがひどく消費されます。現在、あなたが言及したレコードはどのViewにも保存されていませんが、リストビューには、作成したアダプターへの参照があり、ビューとともにそのアダプターをメモリに保持しています。それはただ座っているだけの大量のデータです。

適切な推奨事項を提供するには、最終的にメモリ使用量とパフォーマンスの間に線を引く必要があります。このアプリを公開する場合は、多くの劣ったハードウェア デバイスがあることを念頭に置いてください。

1 つのオプションは、既に行っていることです。これは、savedInstanceStateデタッチされているときに変数を利用することです。これに 300 レコードを入れてみて、Bundleそのパフォーマンスを確認できます。データが作成したクラスである場合は、Parcelableインターフェイスを実装し (これを適切に実装する方法については、ドキュメントBundleを参照してください)、 に格納してから、後で取得して新しいアダプターを作成します。View添付ファイル間で sへの参照を保持しないことを強くお勧めします。

于 2012-04-15T07:13:18.287 に答える