0

私はかなり複雑な UI を持っています - 多くのビューとかなりの階層があります。私はこれを切り詰めようと取り組んでいますが、本当に奇妙なことに気づきました。

UI はバッキング モデルから更新されます。モデルが変更されると、バックグラウンド スレッドでモデルを再計算し、UI スレッドで更新されたモデルをさまざまなコンポーネントに渡して、それらの情報を再表示します。モデルが渡され、すべての (たとえば) textview.setText 呼び出しが行われるまでに、約 200 ～ 300 ミリ秒かかります。ただし、更新機能が終了してから最大 5 秒間は、UI は実際には更新されません。

ddms のメソッド プロファイリング ツールを使用して何が起こっているかを確認しました。更新が終了してから数秒で、大量の測定とレイアウトの呼び出しが行われているようです。いくつかの場所で onLayout をオーバーライドしました。値を 1 つだけ指定すると、UI 全体が再測定されてレイアウトされます。

だから私の質問は、これが正常かどうかです。更新に時間がかかることがわかりますが、5 秒は長いように思えます。アプリの起動時に UI が表示されるまでに数秒かかることがあるため、UI が複雑すぎるのではないかと考えています。これは、Android 4.0.4 を搭載した Galaxy Tab 10.1 にあります。

ありがとう

4

1 に答える 1

0

結局のところ、layout_weight は非常にコストがかかる可能性があります。アプリケーションのメイン パネルは、同じカスタム ビューの 2 つのインスタンスで構成され、layout_weight を使用して半分に分割されました。

<LinearLayout ...>
    <CustomView 
        android:layout_height="match_parent"
        android:layout_width="0dp"
        android:layout_weight="1" />
    <CustomView 
        android:layout_height="match_parent"
        android:layout_width="0dp"
        android:layout_weight="1" />
</LinearLayout>

アプリケーション全体でいくつかのタイミング メソッドをスタックし、hierarchyviewer と共に、レイアウト中に、線形レイアウトへの onMeasure 呼び出しごとに、onMeasure が各カスタム ビューで 4 回呼び出されていることを発見しました。各 onMeasure 呼び出しには約 300 ～ 400 ミリ秒かかり (先ほど述べたように、これは複雑なレイアウトです)、ビュー全体が実際にレイアウトされるまでに 3 秒以上かかりました。

ビューが変更されるたびに (編集テキストにテキストが追加された場合など)、重みに基づいてカスタム ビューの幅が更新されます。重みを使用してデバイスの初期サイズを設定するだけで、各カスタム ビューはサイズを調整できませんでした (どちらも画面の幅の半分であるため)。カスタム ビューの layout_weight 属性を削除し、追加しました。これを onCreate のコードに追加します。

int halfScreenWidth = ...;
for(View v : new View[]{customViewA, customViewB})
{
    LinearLayout.LayoutParams lp = (LinearLayout.LayoutParams) v.getLayoutParams();
    lp.width = halfScreenWidth;
    v.setLayoutParams(lp);
}

この変更により、各カスタム ビューへの onMeasure 呼び出しの数が 4 から 2 に減少し、大幅な節約になりました。したがって、ここで学んだ教訓は、実行時にビューを実際にサイズ変更可能にする必要がない場合は、XML の layout_weight に依存するよりも、コードで幅を計算する方がよいということです。

于 2013-04-28T23:45:38.980 に答える