Ottimizzare una visualizzazione personalizzata
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Se disponi di una vista ben progettata che risponde ai gesti e alle transizioni da uno stato all'altro, assicurati che venga eseguita velocemente. Per evitare che l'interfaccia utente risulti lenta o intermittente durante la riproduzione, assicurati che le animazioni siano costantemente eseguite a 60 frame al secondo.
Visualizzazione più rapida
Per velocizzare la visualizzazione, elimina il codice non necessario dalle routine che vengono richiamate di frequente. Inizia con onDraw(), che ti consente di ottenere il massimo recupero. In particolare, elimina le allocazioni in onDraw(),
poiché potrebbero portare a una garbage collection che causa interruzioni. Alloca oggetti durante l'inizializzazione o tra le animazioni. Non effettuare mai un'allocazione mentre è in esecuzione un'animazione.
Oltre a rendere onDraw() più snello, assicurati che venga chiamato il più raramente possibile. La maggior parte delle chiamate al numero onDraw() è il risultato di una chiamata al numero invalidate(), perciò elimina le chiamate non necessarie a invalidate().
Un'altra operazione molto costosa è l'attraversamento dei layout. Quando una vista chiama
requestLayout(), il sistema di UI di Android attraversa l'intera gerarchia delle viste per determinarne le dimensioni. Se trova misurazioni in conflitto, potrebbe attraversare la gerarchia più volte. I designer dell'interfaccia utente a volte creano gerarchie profonde di oggetti ViewGroup nidificati. Queste gerarchie di oggetti View profonde causano problemi di prestazioni, pertanto rendi le gerarchie delle viste il più basse possibile.
Se hai un'interfaccia utente complessa, valuta la possibilità di scrivere un ViewGroup personalizzato per eseguire il suo layout.
A differenza delle viste integrate, quella personalizzata può fare ipotesi specifiche per l'applicazione in merito alle dimensioni
e alla forma dei suoi elementi figlio ed evitare quindi di attraversare gli elementi secondari per calcolare le misurazioni.
Ad esempio, se hai un ViwGroup personalizzato che non regola le proprie dimensioni per adattarsi a tutte le relative viste secondarie, eviterai l'overhead associato alla misurazione di tutte le viste secondarie. Questa ottimizzazione
non è possibile se utilizzi layout integrati che si adattano a un'ampia gamma di casi d'uso.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
