-1

ネストされた RelativeLayout が多数使用されている場合にパフォーマンスの問題が発生しました。

たとえば、UI ルートとして RelativeLayout があり、すべてのコンテナー (ボタン、ラベル、テキストビュー、イメージビュー) が RelativeLayout + Android ベースのコンポーネント (例: aButton = RelativeLayout + ImageView + TextView) である場合、4 の複雑なビューでボタン、3 つの画像、6 つのラベルで、最大 15 個の入れ子になった RelativeLayouts が得られます。

RelativeLayout には非常に複雑な onMeasure メソッドがあり、すべての子のサイズを計算してレイアウトのサイズを決定します。15 ～ 20 個の入れ子になった RelativeLayouts の複雑なビューのサイズを計算するには、5 秒かかります。これは多すぎます。onMeasure はすべての呼び出しの中で最もコストがかかります。描画は測定よりもずっと速く終了します。<=UPD=>
Android のネイティブ ビューを使用して複雑なものを構築するという提案が表示されないようにする
には、すべてにすべてを追加する機能が必要です。そのため、すべてのコンテナは単なる View ではなく、ViewGroup でなければなりません。また、重力や配置などの RelativeLayout 機能も大いに役立ちます。そのため、多くの RelativeLayout が使用されています。 <=/UPD=>

誰かがこれらのパフォーマンスの問題を抱えていましたか?
RelativeLayout を他のレイアウトに置き換えると問題が解決しますか?
または、これらのネストされたレイアウトをすべて削除することが、問題に対処する唯一の方法ですか?
パフォーマンスの問題が発生することなくネストできるレイアウトの数を知っている人はいますか?

4

3 に答える 3

2

それは間違いなくあなたのテストデバイスに依存します。ただしhierarchyviewer、ビューを削除するには、（ツールディレクトリ内で）ビューの不要なネストがないかどうかを確認する必要があります。

また、aButtonは株のように聞こえますImageButton。したがって、少なくともそれを標準ソリューションに置き換えることができます。

いくつかのコードを投稿した場合、ストックソリューションで置き換えることができるアイテムが他にあるかどうかを判断する方が簡単な場合があります。

于 2010-12-09T07:38:18.977 に答える
0

relativelayout の全体的なポイントは、それらを n 次までネストする必要がないということです。コンポーネントごとに 1 つではなく、いくつかの RelativeLayout を使用しないのはなぜですか?

于 2011-01-03T13:37:19.630 に答える
0

いくつかのテストの後、ネストされたレイアウトが 12 個を超えるとパフォーマンスに大きな影響を与えるという結論に達しました。
平均して、10 ～ 11 個のネストされたレイアウトが正常に機能するはずです。
たとえば、デバイスでは 6 秒、エミュレータでは 9 秒で、各ディスプレイに 12 の子を持つ 12 のネストされたレイアウト。

于 2010-12-09T11:17:16.740 に答える