Android 애플리케이션의 '고착'을 수량화하는 방법

측정 지표를 결정하기 전에 먼저 Android의 UI 업데이트 메커니즘을 살펴보겠습니다.

1. 안드로이드에서 UI를 그리는 방법은 무엇인가요?

Android가 UI를 업데이트하는 방법에 대해서는 단계와 프로세스를 소개하는 기사가 많이 있었던 것 같습니다. 일반적으로 다음 그림을 사용하여 확인할 수 있습니다.

도로가 진행되는 동안 SurfaceFlinger는 항상 최종 업데이트를 제어합니다.

안드로이드 버전 업데이트 과정에서 구글은 안드로이드 평판에 심각한 영향을 미치는 문제 중 하나인 'UI 유창성 저하' 문제를 해결하기 위해 젤리빈에 프로젝트 버터를 추가한 것으로 드러났다. 프로젝트 버터는 주로 VSYNC(수직 동기화), 트리플 버퍼, 안무가라는 세 가지 핵심 요소를 소개합니다.

2. VSYNC로 시작하세요

VSync는 VerticalSynchronization의 약어로 오랫동안 PC에서 널리 사용되어온 기술이라고 생각하시면 됩니다. 시간 제한이 있는 인터럽트입니다. VSync 메커니즘은 Android 4.1(JB)에 도입되었습니다.

위 그림은 VSync 메커니즘 하에서 그리기 프로세스를 보여줍니다. 위 그림에서 볼 수 있듯이 CPU와 GPU 모두 처리 시간은 1 VSync 간격인 16.6ms보다 짧습니다. 모든 간격을 그리면 현재 FPS는 60프레임입니다.

CPU와 GPU의 처리 시간이 모두 느리거나 메인 스레드의 작업량이 너무 많은 등 다른 이유로 인해 다음 그림과 같은 상황이 발생합니다.

위 그림에서 볼 수 있듯이 여러 가지 이유로 CPU와 GPU의 처리 시간이 하나의 VSync 간격(16.6ms)보다 길어지므로 두 번째 VSync가 여전히 그림을 처리하고 있을 때 A영역에서는 이론적인 FPS60 달성이 불가능하며, 프레임 드랍(SF: Skipped Frame)도 발생합니다.

이해를 돕기 위해 위 그림에서는 듀얼 버퍼 메커니즘을 사용하고 있습니다. 실제로 안드로이드 4.1에서는 트리플 버퍼(Triple Buffer)를 도입했기 때문에 듀얼 버퍼가 부족할 경우 트리플 버퍼 프레임 손실 상황은 그림과 같습니다. 아래 그림.

오 마이 레이디가가!

이 모든 것이 Sajia를 어지럽게 만들었습니다! 좀 더 쉽게 비유를 들어보겠습니다!

VSync 메커니즘은 고정 속도(60rpm/s)를 가진 엔진과 같습니다. 각 턴마다 UI 관련 작업을 수행하라는 메시지가 표시되지만 모든 턴에서 수행할 작업이 있는 것은 아닙니다(때로는 중립에서, 때로는 D에서처럼). 때로는 다양한 저항으로 인해 특정 원의 작업 부하가 16.6ms보다 무거워서 이 순간에 엔진이 60회 회전하지 않게 됩니다. 물론 오일 공급 부족(작업 완료) 등 다른 요인의 영향을 받을 수도 있습니다. 메인 스레드에서). 너무 많으면 속도가 감소합니다. 우리는 이것을 속도 부드러움이라고 부릅니다.

3. FPSamp; 프레임 손실에서 부드러움까지(SM:SMoothness)

실제로 많은 Android 앱에는 연속 그리기가 필요한 장면이 거의 없으며 항상 많은 페이지가 있습니다. 공전. 즉, 1초에 VSync의 60개 루프가 모두 드로잉 작업을 하는 것은 아니며, FPS가 상대적으로 낮을지라도, 이것이 프로그램이 원활하지 않다는 의미는 아닙니다. (예를 들어 앱을 움직이지 않고 두면 측정된 FPS는 1입니다.) 따라서 FPS가 낮다고 해서 현재 앱의 UI가 매끄럽지 않다는 의미는 아니지만, 1초 내에 VSync Loop가 실행되는 횟수가 현재 앱의 매끄러움을 더 잘 보여줄 수 있습니다. 따라서 아래 두 가지 지표는 FPS보다 현재 앱이 원활한 상태인지 여부를 더 잘 나타낼 수 있습니다.

동일한 두 지표를 사용하면 앱 지연 정도를 더 잘 정량화할 수 있습니다.

a) Skipped Frame(SF: Skipped Frame): 위의 그림 2와 같이 작업이 16.6ms 내에 완료되어야 하지만 다음과 같은 이유로 실패했습니다. 여러 가지 이유로 완료되면 마지막 n 16.6ms를 차지하며 이는 n 프레임을 잃는 것과 같습니다.

b) 부드러움(SM: SMoothness): 프레임 손실과 달리 VSync 메커니즘에서는 1초 이내에 Loop가 실행되는 횟수가 줄어듭니다.

프레임 손실과 비교하면 특정 작업 시간이 16.6ms(프레임 손실)를 초과하므로 루프가 60회(이론적 최대) 실행될 수 없기 때문에 1초에 60개의 루프가 있습니다.

유창성이 떨어지면 현재 프로그램이 뒤쳐지고 있다는 뜻이다.

4. 계산: 부드러움을 얻는 방법(SM: SMoothness)

위의 결론에 따라 각 루프가 이러한 메커니즘에서 실행되기 전에 알림이 제공되면 숫자를 기록합니다. 괜찮은.

다행히도 새로운 Android 메커니즘에서 Choreographer라는 개체를 발견했습니다. Google의 공식 API 문서 설명에 따르면 애니메이션, 입력 및 그리기 타이밍을 조정하는 데 사용되며 각 루프는 Choreographer 개체를 사용합니다.

다음 그림은 안무가의 정의와 구조를 보여준다.

결론

위의 원리 분석을 통해 다음과 같은 결론을 내릴 수 있습니다.

1. Android 4.1에 VSync 메커니즘이 도입된 후 루프를 사용할 수 있습니다. 현재 앱의 최고의 그리기 능력을 이해합니다.

16.6ms마다 실행됩니다.(이 값은 정적 변수이며 시스템 버전에 따라 다른 값을 채택하게 됩니다. 현재 테스트 버전은 16.6ms이므로 최고 새로고침 프레임 속도는 16.6ms로 제어됩니다. 60FPS 이내);

위 이벤트가 없으면 이러한 루프도 실행됩니다.

이 루프가 1초 내에 실행된 횟수는 다음에 의해 그려지는 최고 값을 나타낼 수 있습니다. 현재 앱의 기능, 즉 Android 앱의 지연 정도;

또한 Loop 중 실행 시간이 16.6ms를 초과하는 경우 16.6ms를 초과하는 시간을 16.6으로 나눕니다. ms는 현재 앱 건너뛴 프레임(SF: Skipped Frame)입니다.

2. Choreographer의 콜백 FrameCallback에서는 현재 App의 부드러움을 초 단위로 계산하여 표현할 수 있는데, 즉 부드러움 SM(SMoothness)입니다.

이 방법을 사용하면 현재 앱의 유창성을 앱 내부에서 관찰할 수 있습니다.

편집자님의 말씀이 있습니다

전문적인 품질 추적 플랫폼인 Tencent Bugly는 모바일 단말기의 다양한 충돌 문제를 분석하는 것 외에도 Goose Factory의 모바일에 대한 정보를 계속 공유할 것입니다. 품질 방법을 통해 모바일 앱 품질을 보다 효율적으로 추적하세요!