最佳化自訂檢視畫面
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
當您設計完善的檢視畫面可以回應手勢和狀態之間的轉換時,請確保檢視畫面執行快速。為了避免使用者介面在播放過程中感覺緩慢或斷斷續續,請確認動畫一律以每秒 60 個影格為單位執行。
加速查看
為了加快檢視畫面,針對經常呼叫的日常安排,移除不必要的程式碼。您從 onDraw()
著手,帶來最高的報酬率。請特別注意,不要在 onDraw()
中進行配置,因為配置作業可能導致垃圾收集導致延遲。在初始化期間或動畫之間分配物件。請勿在執行動畫時進行配置。
除了盡可能精簡 onDraw()
,也請務必盡量降低呼叫頻率。大多數對 onDraw()
的呼叫都是呼叫 invalidate()
的結果,因此移除不必要的 invalidate()
呼叫。
另一個非常昂貴的作業就是周遊版面配置。當檢視區塊呼叫 requestLayout()
時,Android UI 系統會掃遍整個檢視區塊階層,找出每個檢視區塊的大小。如果我們發現相互衝突的測量結果,就可能會多次週遊階層。UI 設計人員有時會建立巢狀 ViewGroup
物件的深度階層。這些深層檢視區塊階層會造成效能問題,因此請盡量讓檢視區塊階層越精簡。
如果您有複雜的 UI,請考慮編寫自訂 ViewGroup
來執行版面配置。與內建檢視畫面不同的是,自訂檢視區塊可對應用程式子項的大小和形狀做出特定假設,因此避免週遊子項來計算測量結果。
例如,如果您的自訂 ViwGroup
無法自行調整其大小以配合所有子項檢視畫面,即可避免測量所有子項檢視畫面的額外負荷。如果您使用的內建版面配置涵蓋多種用途,就無法進行這項最佳化作業。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","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 (世界標準時間)。"],[],[],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."]]