버벅거림은 시스템이 요청된 60hz 이상 주기로 화면에 그려지도록 제시간에 프레임을 빌드하고 제공할 수 없을 때 발생하는 시각적 문제를 설명하는 용어입니다. 버벅거림은 스크롤 시 부드럽게 이어지는 애니메이션된 흐름 대신 끊어지는 느낌이 있을 때 가장 두드러집니다. 앱이 시스템의 프레임 지속 시간보다 콘텐츠를 렌더링하는 데 더 오래 걸리기 때문에 하나 이상의 프레임에서 움직임이 일시중지되면 버벅거림이 나타납니다.
앱은 90Hz 새로고침 빈도를 타겟팅해야 합니다. 기존 렌더링 속도는 60Hz이지만, 대부분의 최신 기기는 스크롤과 같은 사용자 상호작용 중에 90Hz 모드로 작동합니다. 일부 기기는 최대 120Hz의 더 높은 속도를 지원합니다.
특정 시간에 기기에서 사용 중인 새로고침 빈도를 확인하려면 디버깅 섹션에서 개발자 옵션 > 새로고침 빈도 보기를 사용하여 오버레이를 사용 설정합니다.
전환이 원활하지 않음
이는 탭 간 전환이나 새 활동 로드와 같은 상호작용 중에 두드러집니다. 이러한 유형의 전환은 매끄러운 애니메이션이어야 하며 지연이나 시각적 깜박임이 없어야 합니다.
전력 비효율
작업을 하면 배터리 충전량이 줄고 불필요한 작업을 하면 배터리 수명이 줄어듭니다.
코드에서 새 객체를 생성할 때 발생하는 메모리 할당으로 인해 시스템에서 상당한 작업이 발생할 수 있습니다. 할당 자체에 Android 런타임(ART)의 작업이 필요할 뿐만 아니라 나중에 이러한 객체를 해제(가비지 컬렉션)하는 데도 시간과 노력이 필요하기 때문입니다. 할당과 수집은 특히 임시 객체의 경우 훨씬 빠르고 효율적입니다. 전에는 가능하면 객체를 할당하지 않는 것이 좋았지만, 이제는 앱과 아키텍처에 가장 적합한 방법을 사용하는 것이 좋습니다. ART의 기능을 고려할 때 유지보수할 수 없는 코드의 위험을 감수하며 할당을 줄이는 방법은 좋지 않습니다.
그러나 노력이 필요하므로 내부 루프에서 많은 객체를 할당할 경우 성능 문제가 발생할 수 있다는 점에 유의하세요.
Simpleperf: 사용하는 함수 호출의 flamegraph를 표시합니다.
CPU를 모두 소모할 수 있습니다. 무언가를 식별하면
Systrace에서 시간이 오래 걸리는데 왜 그런지 알 수 없습니다. Simpleperf
추가 정보를 제공할 수 있습니다
이러한 성능 문제를 이해하고 디버그하려면 개별 테스트 실행을 수동으로 디버그하는 것이 중요합니다. 집계된 데이터를 분석하여 이전 단계를 대체할 수는 없습니다. 하지만 사용자에게 실제로 표시되는 내용을 이해하고 회귀가 발생할 수 있는 시점을 식별하려면 자동 테스트 및 필드에서 측정항목 수집을 설정하는 것이 중요합니다.
Macrobenchmark에서는 단일 사용자 여정을 괄호로 묶는 dumpsys gfxinfo 명령어를 사용하여 프레임 시간을 수집합니다. 이는 특정 사용자 여정에서 발생하는 버벅거림의 편차를 이해하는 방법입니다. 회귀 또는 개선사항을 식별하기 위해서는 프레임을 그리는 데 걸리는 시간을 강조하는 RenderTime 측정항목이 버벅거리는 프레임 수보다 더 중요합니다.
앱 링크 인증 문제
앱 링크는 웹사이트 URL을 기반으로 하는 딥 링크로서
확인하세요. 다음은 앱 링크가 발생할 수 있는 이유입니다.
있습니다.
인텐트 필터 범위: autoVerify을 추가하는 URL의 인텐트 필터에만
응답할 수 있습니다.
확인되지 않은 프로토콜 전환: 확인되지 않은 서버 측 및 하위 도메인 리디렉션
보안 위험 및 확인에 실패하는 것으로 간주됩니다. 그들은
연결할 수 없는 링크 autoVerify개 예를 들어 HTTP에서 HTTPS로 링크를 리디렉션하면
www.example.com과 같은 URL을 HTTPS 링크를 확인하지 않고도
확인에 실패하게 됩니다. 인텐트를 추가하여 앱 링크를 확인해야 합니다.
필터를 적용합니다.
검증 불가능한 링크: 테스트 목적으로 검증 불가능한 링크를 추가하면
시스템에서 앱의 앱 링크를 확인하지 않습니다.
신뢰할 수 없는 서버: 서버가 클라이언트 앱에 연결될 수 있어야 합니다.
성능 분석을 위한 앱 설정
앱에서 정확하고 반복 가능하며 실행 가능한 벤치마크를 가져오려면 적절한 설정이 중요합니다. 노이즈 소스를 억제하면서 최대한 프로덕션에 가까운 시스템에서 테스트하세요. 다음 섹션에는 테스트 설정을 준비하기 위해 따를 수 있는 여러 가지 APK 및 시스템별 단계가 나오며, 이 중 일부는 사용 사례별로 설명됩니다.
트레이스를 캡처하는 동안 섹션마다 약간의 오버헤드(약 5μs)가 발생하므로 모든 메서드에 트레이스를 포함하지는 않아야 합니다. 0.1ms를 초과하는 큰 작업 청크를 추적하면 병목 현상에 관한 중요한 정보를 얻을 수 있습니다.
APK 고려사항
디버그 변형은 스택 샘플의 문제 해결 및 기호화에 유용할 수 있습니다.
성능에 심각한 영향을 미칩니다 Android 10 (API)을 실행하는 기기
레벨 29) 이상에서는profileable android:shell="true"
매니페스트를 사용하여 출시 빌드에서 프로파일링을 사용 설정하세요.
프로덕션 수준의 코드 축소 구성을 사용합니다. 사용 가능 여부에 따라
리소스를 모두 사용하면 성능에 상당한 영향을 미칠 수 있습니다. 다소 유용함
ProGuard 구성은 tracepoint를 삭제하므로
구성을 지정할 수 있습니다
컴파일
기기 내에서 앱을 알려진 상태(일반적으로 speed)로 컴파일합니다.
speed-profile입니다. 백그라운드 JIT (Just-In-Time) 활동은
자주 발생하며 APK를 재설치할 때 오버헤드가 자주 발생합니다.
테스트를 실행할 수 있습니다 이를 위한 명령어는 다음과 같습니다.
speed 컴파일 모드는 앱을 완전히 컴파일합니다. speed-profile 모드는 앱 사용 중에 수집되는 활용된 코드 경로의 프로필에 따라 앱을 컴파일합니다. 일관되고 올바른 프로필 수집은 어려울 수 있으므로 프로필을 사용하기로 한 경우 프로필이 제대로 수집되는지 확인합니다. 프로필은 다음 위치에 있습니다.
수준은 낮고 충실도는 높은 측정의 경우에는 기기를 보정하세요. 동일한 기기 및 동일한 OS 버전에서 A/B 비교를 실행합니다. 같은 기기 유형에서도 상당한 성능 편차가 있을 수 있습니다.
루팅된 기기에서는 lockClocks 스크립트를 사용해
Microbenchmark 특히 lockClocks 스크립트는 다음을 실행합니다.
CPU의 빈도를 고정합니다.
작은 코어를 사용 중지하고 GPU를 구성합니다.
열 제한을 사용 중지합니다.
앱 실행, DoU 테스트, 버벅거림 테스트와 같은 사용자 환경 중심 테스트에는 lockClocks 스크립트를 사용하지 않는 것이 좋습니다. 하지만 Microbenchmark 테스트에서 노이즈를 줄이는 데는 필수적일 수 있습니다.
가능하다면 Macrobenchmark 같은 테스트 프레임워크를 사용해 보세요.
이렇게 하면 측정 노이즈를 줄이고 부정확한 측정을 방지할 수 있습니다.
느린 앱 시작: 불필요한 트램펄린 활동
트램펄린 활동은 앱 시작 시간을 불필요하게 연장할 수 있으므로 앱이 트램펄린 중인지 인식하는 것이 중요합니다. 다음 트레이스 예에서와 같이 첫 번째 활동에서 프레임을 그리지 않고 한 activityStart 다음에 다른 activityStart가 바로 나옵니다.
그림 1. 트램펄린 활동을 보여주는 트레이스
이는 알림 진입점과 일반 앱 시작 진입점에서 모두 발생할 수 있으며 보통 리팩터링을 통해 해결할 수 있습니다. 예를 들어 다른 활동을 실행하기 전에 이 활동을 사용해 설정을 실행하는 경우 activityStart 코드를 재사용 가능한 구성요소 또는 라이브러리에 팩터링합니다.
GC를 자주 트리거하는 불필요한 할당
Systrace에서 예상보다 더 자주 가비지 컬렉션(GC)이 발생할 수도 있습니다.
다음 예에서 장기 실행 작업 중 10초는 앱이 불필요하지만 시간이 지남에 따라 일관되게 할당할 수 있음을 나타냅니다.
그림 2. GC 이벤트 사이의 공간을 보여주는 트레이스
메모리 프로파일러를 사용하면 특정 호출 스택이 대부분의 할당을 실행하는 것을 확인할 수 있습니다. 코드를 유지 관리하기가 더 어려워질 수 있으므로 모든 할당을 적극적으로 삭제할 필요는 없습니다. 대신 할당의 핫스팟에서 작업을 시작하세요.
버벅거리는 프레임
그래픽 파이프라인은 비교적 복잡하며 사용자에게 최종적으로 누락된 프레임이 표시될지 판단하는 데는 약간의 미묘한 차이가 있을 수 있습니다. 경우에 따라 플랫폼은 버퍼링을 사용하여 프레임을 '구조'할 수 있습니다. 하지만 앱의 관점에서 볼 때 문제가 있는 프레임을 식별하기 위해 이러한 미묘한 차이는 대부분 무시해도 됩니다.
앱에서 필요한 작업을 거의 진행하지 않고 프레임을 그릴 경우 Choreographer.doFrame() tracepoint가 60FPS 기기에서 16.7ms 케이던스로 발생합니다.
그림 3. 빠르고 빈번한 프레임을 보여주는 트레이스
트레이스를 축소하고 탐색하면 프레임이 완료되는 데 좀 더 오래 걸릴 수 있습니다. 하지만 할당된 16.7ms를 초과하지 않으므로 괜찮습니다.
그림 4. 주기적인 작업 버스트가 발생하며 빠르고 빈번한 프레임을 보여주는 트레이스
이 정기적인 케이던스에 중단이 있으면 이는 그림 5와 같이 버벅거리는 프레임인 것입니다.
그림 5. 버벅거리는 프레임을 보여주는 트레이스
이를 식별하는 연습을 할 수 있습니다.
그림 6. 많이 버벅거리는 프레임을 보여주는 트레이스
경우에 따라 확장되는 뷰 또는 RecyclerView의 기능에 관한 자세한 정보를 확인하기 위해 tracepoint를 확대해야 할 수 있습니다. 다른 경우에는 추가 검사가 필요하기도 합니다.
버벅거리는 프레임을 식별하고 원인을 디버깅하는 방법에 관한 자세한 내용은 느린 렌더링을 참고하세요.
흔히 발생하는 RecyclerView 실수
RecyclerView의 전체 지원 데이터를 무효화하면 불필요하게
긴 프레임 렌더링 시간과 버벅거림이 발생할 수 있습니다. 그 대신
변경하면 변경되는 데이터만 무효화할 수 있습니다.
비용이 많이 드는 notifyDatasetChanged()을 피하는 방법은 동적 데이터 표시를 참고하세요.
호출을 제거하므로 콘텐츠가 완전히 대체되지 않고 업데이트됩니다.
모든 중첩된 RecyclerView를 제대로 지원하지 않으면 내부 RecyclerView가 매번 완전히 다시 만들어질 수 있습니다. 모든 중첩되고
내부 RecyclerView에 RecycledViewPool가 설정되어 있어야
뷰는 모든 내부 RecyclerView 간에 재활용할 수 있습니다.
데이터를 충분히 미리 가져오지 않거나 적시에 미리 가져오지 않으면 사용자가 서버에서 더 많은 데이터를 기다려야 할 때 스크롤 목록 하단에 도달하기가 불편할 수 있습니다. 이는 프레임 기한이 누락되지는 않으므로 엄밀히 말하면 버벅거림은 아니지만 사용자가 데이터를 기다릴 필요가 없도록 미리 가져오기의 시기와 양을 수정하여 UX를 크게 개선할 수 있습니다.
앱 디버그
다음은 앱 성능을 디버깅하는 다양한 방법입니다. 자세한 내용은
시스템 추적 및 Android 사용의 개요를 보여주는 다음 동영상은
Studio 프로파일러
Systrace로 앱 시작 디버그
앱 시작 프로세스의 개요는 앱 시작 시간을 참고하고
시스템 추적 개요를 보려면 다음 동영상을 시청하세요.
동기 바인더 트랜잭션:
중요 경로를 파악하는 데
도움이 될 수 있습니다 필요한 트랜잭션이 비싸다면
관련 플랫폼팀과 협력하여
개선할 수 있습니다
동시 GC: 일반적이고 상대적으로 영향이 적지만
문제가 자주 발생하는 경우 Android 스튜디오 메모리로 문제를 살펴보는 것이 좋습니다.
할 수 있습니다
I/O: 시작 중에 I/O가 수행되었는지 확인하고 오래 멈춰 있는지 확인합니다.
다른 스레드의 중요한 활동: UI 스레드를 방해할 수 있음
따라서 시작 중에는 백그라운드 작업을 주의해야 합니다.
다음에서 시작이 완료되면 reportFullyDrawn를 호출하는 것이 좋습니다.
앱 시작 측정항목 보고를 개선하기 위한 앱의 관점입니다. 시간
전체 표시 섹션을 참조하세요.reportFullyDrawn
Perfetto 트레이스 프로세서를 통해 RFD에서 정의한 시작 시간을 추출할 수 있습니다.
사용자에게 표시되는 트레이스 이벤트가 내보내집니다.
기기에서 시스템 추적 사용
System Tracing이라는 시스템 수준 앱을 사용하여 시스템을 캡처합니다.
트레이스를 참고하세요. 이 앱을 사용하면
전원에 연결하거나 adb에 연결해야 하기 때문이죠.
Android 스튜디오 메모리 프로파일러 사용
Android 스튜디오 메모리 프로파일러를 사용하여 메모리 압력을 검사할 수 있습니다.
메모리 누수나 잘못된 사용 패턴으로 인해
발생할 수 있습니다 또한 실시간
살펴보겠습니다.
앱의 메모리 문제를 해결하려면
GC가 발생하는 이유와 빈도를 추적하는 메모리 프로파일러
앱 메모리를 프로파일링하려면 다음 단계를 따르세요.
메모리 문제를 감지합니다.
중점을 두려는 사용자 여정의 메모리 프로파일링 세션을 기록합니다.
그림 7에서와 같이 결국에는 객체 수가 증가하는 것을 찾습니다.
GC로 이어질 수 있습니다.
그림 7. 증가하는 객체 수
그림 8. 가비지 컬렉션
메모리 압력을 가중시키는 사용자 여정을 파악한 후에는
메모리 압력의 근본 원인을 알아내세요.
메모리 압력 핫스팟을 진단합니다.
타임라인에서 범위를 선택하여 Allocations와
Shallow Size(그림 9 참조)
그림 9.Allocations 및 Shallow 값
크기를 선택합니다.
이 데이터를 정렬하는 방법에는 여러 가지가 있습니다. 다음은 배포와 관련된
문제를 분석하는 데 도움이 되는 방법을 배우게 됩니다.
Arrange by class: 클래스별로 정렬되지 않는 클래스를 찾을 때 유용합니다.
다른 방식으로는 메모리 풀에서 캐시되거나 재사용되는 객체를 생성할 수 없습니다.
예를 들어 앱에서
'Vertex' 매초 Allocations 수를 2,000씩 늘립니다.
클래스별로 정렬할 때 표시됩니다. 포드를 다시 사용하려면
메모리 풀을 구현해야 합니다.
Arrange by callstack: 호출 스택에서
메모리 할당 경로(예: 루프 내부 또는
할당 작업을 많이 하는 특정 함수가 있을 수 있습니다.
Shallow Size: 객체 자체의 메모리만 추적합니다. 유용함
주로 원시 값으로만 구성된 간단한 클래스를 추적하기 위한 용도입니다.
Retained Size: 객체 및 참조로 인한 총 메모리 표시
참조될 수 있습니다 한 번에 여러 작업을 수행하여
압력을 받을 수 있기 때문입니다. 이 값을 가져오려면 전체 메모리를 사용하세요.
덤프가 있고 Retained Size가 열로 추가됩니다.
API를 사용할 수 있습니다.
그림 10. 전체 메모리 덤프.
그림 11. Retained Size 열을 확인합니다.를 통해 개인정보처리방침을 정의할 수 있습니다.
최적화의 영향을 측정할 수 있습니다.
GC가 더 분명하고 메모리의 영향을 더 쉽게 측정할 수 있음
최적화할 수 있습니다 최적화로 메모리 압력이 줄어들면
줄일 수 있습니다.
최적화의 영향을 측정하려면 프로파일러 타임라인에서
시간을 단축할 수 있습니다. 그러면 GC 간에 시간이 더 오래 걸리는 것을 확인할 수 있습니다.
메모리 개선의 궁극적인 영향은 다음과 같습니다.
앱이 지속적으로
메모리 압력에 도달합니다
GC가 적을수록 특히 P99에서 버벅거림 측정항목이 개선됩니다. GC가 CPU 경합을 유발하여 GC가 실행되는 동안 렌더링 작업이 지연될 수 있기 때문입니다.
그림 1. 트램펄린 활동을 보여주는 트레이스
그림 2. GC 이벤트 사이의 공간을 보여주는 트레이스
그림 3. 빠르고 빈번한 프레임을 보여주는 트레이스
그림 4. 주기적인 작업 버스트가 발생하며 빠르고 빈번한 프레임을 보여주는 트레이스
그림 5. 버벅거리는 프레임을 보여주는 트레이스
그림 6. 많이 버벅거리는 프레임을 보여주는 트레이스
그림 7. 증가하는 객체 수
그림 8. 가비지 컬렉션
그림 9. Allocations 및 Shallow 값
크기를 선택합니다.
그림 10. 전체 메모리 덤프.