Если у вас есть хорошо спроектированное представление, реагирующее на жесты и переходы между состояниями, убедитесь, что представление работает быстро. Чтобы пользовательский интерфейс не работал медленно или заикался во время воспроизведения, убедитесь, что анимация постоянно выполняется со скоростью 60 кадров в секунду.
Ускорьте просмотр
Чтобы ускорить просмотр, удалите ненужный код из часто вызываемых процедур. Начните с onDraw() , который даст вам наибольшую отдачу. В частности, исключите выделение ресурсов в onDraw() , поскольку выделение может привести к сборке мусора, вызывающей заикание. Выделяйте объекты во время инициализации или между анимациями. Никогда не делайте выделение во время работы анимации.
Помимо упрощения использования onDraw() , убедитесь, что он вызывается как можно реже. Большинство вызовов onDraw() являются результатом вызова invalidate() , поэтому исключите ненужные вызовы invalidate() .
Еще одна очень затратная операция — обход макетов. Когда представление вызывает requestLayout() , система пользовательского интерфейса Android просматривает всю иерархию представлений, чтобы определить, насколько большим должно быть каждое представление. Если он обнаружит противоречивые измерения, он может пересечь иерархию несколько раз. Дизайнеры пользовательского интерфейса иногда создают глубокие иерархии вложенных объектов ViewGroup . Эти глубокие иерархии представлений вызывают проблемы с производительностью, поэтому делайте иерархии представлений как можно более мелкими.
Если у вас сложный пользовательский интерфейс, рассмотрите возможность написания собственной ViewGroup для выполнения его макета. В отличие от встроенных представлений, ваше пользовательское представление может делать специфичные для приложения предположения о размере и форме своих дочерних элементов и, следовательно, избегать пересечения своих дочерних элементов для расчета измерений.
Например, если у вас есть пользовательская группа ViwGroup , которая не регулирует свой размер так, чтобы она соответствовала всем дочерним представлениям, вы избегаете накладных расходов на измерение всех дочерних представлений. Такая оптимизация невозможна, если вы используете встроенные макеты, подходящие для широкого спектра вариантов использования.
Если у вас есть хорошо спроектированное представление, реагирующее на жесты и переходы между состояниями, убедитесь, что представление работает быстро. Чтобы пользовательский интерфейс не работал медленно или заикался во время воспроизведения, убедитесь, что анимация постоянно выполняется со скоростью 60 кадров в секунду.
Ускорьте просмотр
Чтобы ускорить просмотр, удалите ненужный код из часто вызываемых процедур. Начните с onDraw() , который даст вам наибольшую отдачу. В частности, исключите выделение ресурсов в onDraw() , поскольку выделение может привести к сборке мусора, вызывающей заикание. Выделяйте объекты во время инициализации или между анимациями. Никогда не делайте выделение во время работы анимации.
Помимо упрощения использования onDraw() , убедитесь, что он вызывается как можно реже. Большинство вызовов onDraw() являются результатом вызова invalidate() , поэтому исключите ненужные вызовы invalidate() .
Еще одна очень затратная операция — обход макетов. Когда представление вызывает requestLayout() , система пользовательского интерфейса Android просматривает всю иерархию представлений, чтобы определить, насколько большим должно быть каждое представление. Если он обнаружит противоречивые измерения, он может пересечь иерархию несколько раз. Дизайнеры пользовательского интерфейса иногда создают глубокие иерархии вложенных объектов ViewGroup . Эти глубокие иерархии представлений вызывают проблемы с производительностью, поэтому делайте иерархии представлений как можно более мелкими.
Если у вас сложный пользовательский интерфейс, рассмотрите возможность написания собственной ViewGroup для выполнения его макета. В отличие от встроенных представлений, ваше пользовательское представление может делать специфичные для приложения предположения о размере и форме своих дочерних элементов и, следовательно, избегать пересечения своих дочерних элементов для расчета измерений.
Например, если у вас есть пользовательская группа ViwGroup , которая не регулирует свой размер так, чтобы она соответствовала всем дочерним представлениям, вы избегаете накладных расходов на измерение всех дочерних представлений. Такая оптимизация невозможна, если вы используете встроенные макеты, подходящие для широкого спектра вариантов использования.