Google은 흑인 공동체를 위한 인종 간 평등을 진전시키기 위해 노력하고 있습니다. Google에서 어떤 노력을 하고 있는지 확인하세요.

뷰 최적화

동작과 상태 간 전환에 응답하는 잘 설계된 뷰를 갖추었으므로 이제는 이 뷰가 빠르게 실행되게 해야 합니다. UI가 재생 중 느려지거나 버벅거리는 일을 방지하려면 애니메이션을 초당 60프레임으로 일관되게 실행해야 합니다.

간소화 및 빈도 낮추기

뷰 속도를 높이려면 자주 호출되는 루틴에서 불필요한 코드를 제거합니다. onDraw()에서 작업을 시작하면 가장 큰 효과를 얻을 수 있습니다. 특히, 할당은 버벅거림의 원인이 되는 가비지 컬렉션을 초래할 수 있으므로 onDraw()에서 할당을 제거해야 합니다. 객체는 초기화 중 또는 애니메이션 사이에 할당합니다. 애니메이션이 실행되고 있는 동안에는 절대 할당하지 마세요.

onDraw()를 간소화하는 것 외에도 최대한 자주 호출되지 않도록 합니다. onDraw()의 호출 대부분은 invalidate() 호출의 결과이므로 invalidate()의 불필요한 호출을 제거합니다.

큰 비용이 드는 또 하나의 작업은 레이아웃 순회입니다. 뷰에서 requestLayout()을 호출할 때마다 Android UI 시스템은 각 뷰의 크기가 얼마나 되어야 하는지 알아내기 위해 전체 뷰 계층 구조를 순회해야 합니다. 측정치 간 충돌이 발견되면 시스템은 계층 구조를 여러 번 순회해야 합니다. UI 디자이너는 UI가 제대로 작동하도록 중첩된 ViewGroup 객체의 계층 구조를 깊게 만들기도 합니다. 이러한 심층적인 뷰 계층 구조로 인해 성능 관련 문제가 발생합니다. 그러므로 뷰 계층 구조를 가능한 한 얕게 만드세요.

복잡한 UI가 있다면 레이아웃을 실행할 맞춤 ViewGroup 작성을 고려해보세요. 기본 제공 뷰와 달리 맞춤 뷰에서는 애플리케이션별로 하위 요소의 크기 및 모양을 추정할 수 있으므로 측정치 계산을 위해 하위 요소를 순회하지 않아도 됩니다. PieChart 예는 맞춤 뷰의 일부로 ViewGroup 확장 방법을 보여줍니다. PieChart에는 하위 요소 뷰가 있지만 측정하지는 않습니다. 대신, 자체 맞춤 레이아웃 알고리즘에 따라 크기를 직접 설정합니다.