カスタムビューを最適化する
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
操作や状態間の遷移に応答するビューを適切に設計する場合は、ビューが高速に動作するようにしてください。再生中に UI の動作が遅くなったり途切れたりしないようにするには、アニメーションが常に 60 フレーム/秒で動作していることを確認します。
表示速度を上げる
ビューを高速化するには、頻繁に呼び出されるルーチンから不要なコードを削除します。最初に onDraw()
を使用します。これにより、費用対効果が最大になります。特に、onDraw()
での割り当てを削除します。割り当てによってガベージ コレクションが発生し、スタッタリングが発生する可能性があるためです。初期化時またはアニメーション間でオブジェクトを割り当てます。アニメーションの実行中に割り当てを行わないでください。
onDraw()
を簡潔にすることに加えて、呼び出し頻度は可能な限り少なくします。onDraw()
の呼び出しは、ほとんどの場合、invalidate()
の呼び出しの結果であるため、invalidate()
の不要な呼び出しは除外します。
もう 1 つの非常に高コストな処理として、レイアウトのトラバースがあります。ビューが requestLayout()
を呼び出すと、Android UI システムはビュー階層全体を走査して、各ビューに必要なサイズを見つけます。競合する測定値が見つかった場合は、階層を複数回走査することがあります。UI デザイナーは、ネストされた ViewGroup
オブジェクトからなる深い階層を作成することがあります。このような深いビュー階層はパフォーマンスの問題を引き起こすため、ビュー階層は可能な限り浅くします。
複雑な UI がある場合は、カスタム ViewGroup
を作成してレイアウトを実行することを検討してください。組み込みビューとは異なり、カスタムビューでは、子のサイズと形状についてアプリ固有の仮定を行うことができるため、測定値を計算するために子を走査する必要がなくなります。
たとえば、すべての子ビューに合わせてサイズを調節しないカスタム ViwGroup
を使用すると、すべての子ビューを測定するオーバーヘッドを回避できます。さまざまなユースケースに対応する組み込みレイアウトを使用する場合、この最適化は実現できません。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],null,["# Optimize a custom view\n\nWhen you have a well-designed view that responds to gestures and transitions between states, make\nsure the view runs fast. To avoid a UI that feels sluggish or stutters during playback, make sure\nanimations consistently run at 60 frames per second.\n\nSpeed up your view\n------------------\n\nTo speed up your view, eliminate unnecessary code from routines that are called frequently. Start\nwith\n[onDraw()](/reference/android/view/View#onDraw(android.graphics.Canvas)),\nwhich gives you the biggest payback. In particular, eliminate allocations in `onDraw()`,\nbecause allocations might lead to a garbage collection that causes a stutter. Allocate objects\nduring initialization or between animations. Never make an allocation while an animation is\nrunning.\n\nIn addition to making `onDraw()` leaner, make sure it's called as infrequently as\npossible. Most calls to `onDraw()` are the result of a call to\n[invalidate()](/reference/android/view/View#invalidate()), so eliminate\nunnecessary calls to `invalidate()`.\n\nAnother very expensive operation is traversing layouts. When a view calls\n[requestLayout()](/reference/android/view/View#requestLayout()), the\nAndroid UI system traverses the entire view hierarchy to find how big each view needs to be. If it\nfinds conflicting measurements, it might traverse the hierarchy multiple times. UI designers\nsometimes create deep hierarchies of nested\n[ViewGroup](/reference/android/view/ViewGroup) objects. These deep view\nhierarchies cause performance problems, so make your view hierarchies as shallow as possible.\n\nIf you have a complex UI, consider writing a custom `ViewGroup` to perform its layout.\nUnlike the built-in views, your custom view can make application-specific assumptions about the size\nand shape of its children and therefore avoid traversing its children to calculate measurements.\n\nFor example, if you have a custom `ViwGroup` that doesn't adjust its own size to fit\nall its child views, you avoid the overhead of measuring all the child views. This optimization\nisn't possible if you use the built-in layouts that cater to a wide range of use-cases."]]