성능 여정을 위한 레벨링 가이드

성능 스포트라이트 주간의 4일차에 오신 것을 환영합니다. 최근에 도입된 R8 최적화 도구, 기준 프로필 및 시작 프로필을 사용한 프로필 기반 최적화와 같은 유용한 도구와 권장사항에 관해 알아보았으므로 성능 개선 여정을 어디에서 시작해야 할지 궁금할 수 있습니다. 

Google은 성능을 시작하려는 단일 개발자가 있는 앱이든 Android 성능 개선에 전념하는 전체 팀이든 모바일 개발팀의 현재 수준에 맞는 단계별 성능 레벨링 가이드를 마련했습니다. 

성능 레벨링 가이드는 5단계로 구성되어 있습니다. 최소한의 도입 노력 성능 도구를 소개하는 1단계부터 맞춤형 성능 프레임워크를 유지할 리소스가 있는 앱에 적합한 5단계까지 진행합니다.

가장 공감되는 수준으로 자유롭게 이동하세요.

• 1단계: Play Console에서 제공하는 필드 모니터링 사용
• 2단계: 앱 성능 점수 작업 항목 따르기
• 3단계: 로컬 성능 테스트 프레임워크 활용
• 4단계: Perfetto와 같은 트레이스 분석 도구 사용
• 5단계: 자체 성능 추적 프레임워크 빌드

1단계:  Play Console에서 제공하는 필드 모니터링 사용

먼저 Play Console 내에서 Android vitals를 활용하여 자동으로 수집된 필드 모니터링 데이터를 보는 것이 좋습니다. 이렇게 하면 최소한의 노력으로 애플리케이션에 관한 통계를 얻을 수 있습니다.

Android vitals는 Google에서 이 필드 데이터를 자동으로 수집하고 표시하기 위해 마련한 이니셔티브입니다.

이 데이터를 제공하는 방법은 다음과 같습니다.

1. 데이터 수집: 사용자가 선택하면 Android 기기에서 내 앱을 비롯한 모든 앱의 주요 성능 및 안정성 이벤트를 자동으로 로깅합니다.
2. 데이터 집계: Google Play에서 앱 사용자의 데이터를 수집하고 익명 처리합니다.
3. 통계 표시: 데이터는 Google Play Console 내의 Android vitals 대시보드에 표시됩니다.

Android vitals 대시보드는 여러 측정항목을 추적하지만 일부는 핵심 vitals 로 지정됩니다. 이러한 측정항목은 Google Play 스토어에서 앱의 조회 가능성과 순위에 영향을 미칠 수 있으므로 가장 중요합니다.

핵심 vitals

핵심 vitals에는 사용자 인식 비정상 종료 발생률, ANR 발생률, 과도한 배터리 사용, 새로 도입된 불필요한 부분적인 wake lock 측정항목이 포함됩니다.

사용자 인식 ANR 발생률

Android vitals ANR 대시보드를 사용하여 필드에서 발생하는 문제의 스택 트레이스를 확인하고 문제를 해결하는 방법에 관한 통계와 권장사항을 얻을 수 있습니다. 

발생한 특정 ANR을 드릴다운하여 스택 트레이스와 문제의 원인이 될 수 있는 통계를 확인할 수 있습니다.

또한 ANR이 발생할 수 있는 일반적인 시나리오를 진단하고 해결하는 데 도움이 되는 ANR 가이드를 확인하세요. 

사용자 인식 비정상 종료 발생률

Android vitals 비정상 종료 대시보드를 사용하여 비정상 종료를 추가로 디버그하고 앱 내에서 발생하는 스택 트레이스 샘플을 확인하세요. 

문서에는 특정 비정상 종료 문제 해결에 관한 가이드도 있습니다. 예를 들어 포그라운드 서비스 문제 해결 가이드에서는 비정상 종료가 발생하는 일반적인 시나리오를 식별하고 해결하는 방법을 설명합니다.

과도한 배터리 사용

Wear OS에서 과도한 배터리 사용이 있는 시계 화면 세션을 줄이려면 배터리를 개선하고 절약하는 방법에 관한 Wear 가이드를 확인하세요. 

[신규] 불필요한 부분적인 wake lock

최근에 불필요한 부분적인 wake lock 기준을 초과하는 앱에 2026년 3월 1일 부터 추가 처리가 적용될 수 있다고 발표했습니다. 

휴대기기의 경우 Android vitals 측정항목은 화면이 꺼져 있고 앱이 백그라운드에 있거나 포그라운드 서비스를 실행하는 동안 획득한 면제되지 않은 wake lock에 적용됩니다. Android vitals는 24시간 이내에 wake lock이 2시간 이상 유지되고 28일 동안 평균적으로 앱 세션의 5% 넘게 영향을 미치는 경우 부분적인 wake lock 사용이 과도하다고 간주합니다.

과도한 wake lock 문제를 디버그하고 해결하려면 기술 블로그 게시물을 확인하세요.

Android vitals 문서를 참고하고 Android vitals를 더 효과적으로 활용하기 위한 여정을 계속하세요.

2단계: 앱 성능 점수 작업 항목 따르기

다음으로 앱 성능 점수를 사용하여 앱 성능을 개선할 수 있는 영향력이 큰 작업 항목을 찾습니다.

Android 앱 성능 점수는 앱의 기술적 성능을 측정하는 표준화된 프레임워크입니다. 0에서 100 사이의 점수를 제공하며 숫자가 낮을수록 개선의 여지가 많습니다.

간단한 개선을 위해서는 먼저 정적 성능 점수 부터 시작해야 합니다. 이러한 점수는 상당한 성능 향상을 제공하는 구성 변경 또는 도구 업데이트인 경우가 많습니다.

1단계: 정적 평가 실행

정적 평가는 프로젝트의 구성 및 도구 도입을 평가합니다. 이러한 평가는 성능을 개선하는 가장 빠른 방법인 경우가 많습니다.

스코어보드 페이지의 정적 점수 섹션으로 이동하여 다음을 실행합니다.

1. Android Gradle 플러그인 (AGP) 버전을 평가합니다.
2. R8 축소를 점진적으로 도입하거나 전체 모드에서 R8을 사용하여 앱 코드를 축소하고 최적화하는 것이 좋습니다.
3. 첫 번째 실행부터 코드 실행 속도를 개선하여 모든 새 앱 설치 및 모든 앱 업데이트에 성능 향상을 제공하는 기준 프로필을 도입합니다.
4. 시작 프로필을 도입하여 Dex 레이아웃을 개선합니다. 시작 프로필은 빌드 시스템에서 APK의 DEX 파일에 있는 코드의 레이아웃을 개선하여 포함된 클래스와 메서드를 추가로 최적화하는 데 사용됩니다.
5. 최신 버전의 Jetpack Compose로 업그레이드합니다.

2단계: 동적 평가 실행

정적 간단한 개선을 적용한 후에는 동적 평가를 사용하여 실제 기기에서 개선사항을 검증합니다. 먼저 실제 기기와 스톱워치를 사용하여 수동으로 이 작업을 실행할 수 있습니다.

스코어보드 페이지의 동적 점수 섹션으로 이동하여 다음을 실행합니다.

1. 실제 기기로 테스트 환경을 설정합니다. 성능 문제를 과장하여 쉽게 발견할 수 있도록 하위 기기를 사용하는 것이 좋습니다.
2. 런처에서 시작 시간을 측정합니다. 런처 아이콘에서 앱을 콜드 스타트하고 상호작용할 수 있을 때까지의 시간을 측정합니다.
3. 알림 시작 시간을 2초 미만으로 줄이는 것을 목표로 알림에서 앱 시작 시간을 측정합니다.
4. 핵심 화면과 애니메이션을 스크롤하여 렌더링 성능을 측정합니다.

이 단계를 완료하면 정적 점수와 동적 점수에 대해 1~100점의 점수를 받게 되므로 앱의 성능과 집중해야 할 부분을 파악할 수 있습니다.

3단계: 로컬 성능 테스트 프레임워크 활용

동적 성능 평가를 시작하면 성능을 수동으로 측정하는 것이 너무 지루할 수 있습니다. Macrobenchmark 및 UiAutomator와 같은 성능 테스트 프레임워크를 사용하여 성능 테스트를 자동화하는 것이 좋습니다.

Macrobenchmark 💚 UiAutomator

Macrobenchmark와 UiAutomator는 함께 작동하는 두 가지 도구라고 생각하면 됩니다. Macrobenchmark는 측정 도구입니다. 앱 외부에서 실행되는 스톱워치 및 프레임 속도 카운터와 같습니다. 앱을 시작하고, 측정항목 (예: 시작 시간 또는 프레임 삭제)을 기록하고, 앱을 중지하는 역할을 합니다. UiAutomator는 로봇 사용자입니다. 이 라이브러리를 사용하면 기기의 화면과 상호작용하는 코드를 작성할 수 있습니다. 아이콘을 찾고, 버튼을 탭하고,  목록을 스크롤하는 등의 작업을 할 수 있습니다.

테스트 작성 방법

테스트를 작성할 때는 UiAutomator 코드를 Macrobenchmark 블록 내에 래핑합니다.

1. 테스트 정의: @MacrobenchmarkRule 사용
2. 측정 시작: benchmarkRule.measureRepeated 호출
3. UI 구동: 이 블록 내에서 UiAutomator 코드를 사용하여 앱을 실행하고, UI 요소를 찾고, UI 요소와 상호작용합니다.

다음은 스크롤 버벅거림을 위해 Compose 목록을 테스트하는 방법을 보여주는 코드 스니펫입니다.

  benchmarkRule.measureRepeated(

    // ...

    metrics = listOf(

        FrameTimingMetric(),

    ),

    startupMode = StartupMode.COLD,

    iterations = 10,

) {

    // 1. Launch the app's main activity

    startApp()

    // 2. Find the list using its resource ID and scroll down

    onElement { viewIdResourceName == "$packageName.my_list" }

        .fling(Direction.DOWN)

}

4. 결과 검토: 각 테스트 실행은 앱 성능에 관한 최상의 데이터를 제공하기 위해 정확하게 측정된 정보를 제공합니다.

  timeToInitialDisplayMs  min  1894.4,   median 2847.4,   max  3355.6


frameOverrunMs          P50 -3.2,  P90  6.2, P95  10.4, P99  119.5

일반적인 사용 사례

Macrobenchmark는 여러 핵심 측정항목을 바로 제공합니다. StartupTimingMetric을 사용하면 앱 시작을 정확하게 측정할 수 있습니다. FrameTimingMetric을 사용하면 테스트 중에 앱의 렌더링 성능을 파악할 수 있습니다.

Macrobenchmark 및 UiAutomator를 코드 샘플과 함께 사용하는 방법에 관한 자세하고 완전한 가이드가 제공되므로 계속 학습할 수 있습니다.

4단계: Perfetto와 같은 트레이스 분석 도구 사용 

Perfetto와 같은 트레이스 분석 도구는 자체 애플리케이션 코드 이상을 확인해야 할 때 사용됩니다. 프로세스만 확인하는 표준 디버거 또는 프로파일러와 달리 Perfetto는 전체 기기 상태(커널 예약, CPU 주파수, 기타 프로세스, 시스템 서비스)를 캡처하여 성능 문제에 관한 전체 컨텍스트를 제공합니다.

시스템 트레이스, Android 스튜디오 프로파일러, Perfetto를 사용하여 성능 디버깅에 관한 동영상 안내는 성능 디버깅 YouTube 재생목록을 확인하세요.

Perfetto를 사용하여 성능을 디버그하는 방법

트레이스 분석 도구를 사용하여 성능을 디버그하는 일반적인 워크플로는 트레이스를 기록, 로드, 분석하는 것입니다. 

1단계: 트레이스 기록

여러 가지 방법을 사용하여 시스템 트레이스를 기록할 수 있습니다.

• 개발자 옵션에서 직접 기기에 트레이스를 수동으로 기록합니다. 개발자 옵션에서 직접.
• Android 스튜디오 CPU 프로파일러 사용
• Perfetto UI 사용

2단계: 트레이스 로드

트레이스 파일이 있으면 분석 도구에 로드해야 합니다.

1. Chrome을 열고 ui.perfetto.dev로 이동합니다.
2. .perfetto-trace 또는 .pftrace 파일을 브라우저 창으로 직접 드래그 앤 드롭합니다.
3. UI에서 파일을 처리하고 타임라인을 표시합니다.

3단계: 트레이스 분석

Perfetto UI 또는 Android 스튜디오 프로파일러를 사용하여 성능 문제를 조사할 수 있습니다. 성능 엔지니어 Carmen Jackson이 Perfetto traceviewer를 설명하는 성능에 관한 MAD Skills 시리즈의 이 에피소드를 확인하세요.

Perfetto를 사용하여 시스템 트레이스를 검사하는 시나리오

Perfetto는 전문가 도구이며 트레이스가 캡처되는 동안 Android 기기에서 발생한 모든 사항에 관한 정보를 제공할 수 있습니다. 이는 표준 로그 또는 기본 프로파일러를 사용하여 속도 저하의 근본 원인을 식별할 수 없는 경우에 특히 유용합니다.

버벅거림 (프레임 삭제) 디버깅

스크롤하는 동안 앱이 버벅거리는 경우 Perfetto는 특정 프레임이 기한을 놓친 이유를 정확하게 보여줄 수 있습니다.

앱으로 인한 경우 기본 스레드가 긴 시간 동안 실행되어 파싱을 많이 실행하는 것을 볼 수 있습니다. 이는 작업을 비동기 처리로 이동해야 하는 시나리오를 나타냅니다.

시스템으로 인한 경우 기본 스레드가 실행될 준비가 되었지만 CPU 커널 스케줄러가 다른 시스템 서비스에 우선순위를 부여하여 앱이 대기 상태로 남는 것을 볼 수 있습니다 (CPU 경합). 이는 플랫폼 API의 사용을 최적화해야 할 수 있는 시나리오를 나타냅니다.

느린 앱 시작 분석

시작은 시스템 초기화, 프로세스 포크, 리소스 로드와 관련된 복잡한 작업입니다. Perfetto는 이 타임라인을 정확하게 시각화합니다.

바인더 호출 (프로세스 간 통신)을 기다리고 있는지 확인할 수 있습니다. onCreate가 시스템 PackageManager의 응답을 오랫동안 기다리는 경우 Perfetto는 차단된 상태를 명확하게 보여줍니다. 

앱 시작 중에 앱이 필요한 것보다 더 많은 작업을 실행하는지 확인할 수도 있습니다. 예를 들어 앱에 표시해야 하는 것보다 더 많은 뷰를 만들고 배치하는 경우 트레이스에서 이러한 작업을 확인할 수 있습니다.

배터리 소모 및 CPU 사용량 조사

Perfetto는 전체 시스템을 볼 수 있으므로 보이지 않는 전력 소모를 찾는 데 적합합니다.

'기기 상태' 트랙에서 기기가 절전 모드로 전환되는 것을 방지하는 wake lock을 보유한 프로세스를 식별할 수 있습니다. wake lock 블로그 게시물에서 자세히 알아보세요. 또한 Perfetto를 사용하여 백그라운드 작업이 너무 자주 실행되거나 CPU를 불필요하게 절전 모드에서 해제하는지 확인할 수 있습니다.

5단계: 자체 성능 추적 프레임워크 빌드

마지막 단계는 성능 추적 프레임워크를 유지할 리소스가 있는 팀이 있는 앱을 위한 것입니다. 

Android에서 맞춤 성능 추적 프레임워크를 빌드하려면 시작부터 종료까지, 그리고 특정 고부하 시나리오에서 애플리케이션 수명 주기 전반에 걸쳐 데이터를 캡처하기 위해 여러 시스템 API를 활용해야 합니다.

ApplicationStartInfo, ProfilingManager, ApplicationExitInfo를 사용하면 앱이 시작된 방법, 실행 중에 수행한 작업에 관한 세부정보, 종료된 이유를 보고하는 강력한 원격 분석 시스템을 만들 수 있습니다.

ApplicationStartInfo: 앱이 시작된 방법 추적

Android 15 (API 35)부터 사용할 수 있는 ApplicationStartInfo는 필드에서 앱 시작에 관한 자세한 측정항목을 제공합니다. 데이터에는 콜드, 웜, 핫 스타트 여부와 다양한 시작 단계의 기간이 포함됩니다. 

이를 통해 프로덕션 데이터를 사용하여 로컬에서 재현하기 어려울 수 있는 기준 시작 측정항목을 개발하여 추가로 최적화할 수 있습니다. 이러한 측정항목을 사용하여 시작 흐름을 최적화하는 A/B 테스트를 실행할 수 있습니다.

목표는 모든 초기화 단계를 수동으로 계측하지 않고 시작 측정항목을 정확하게 기록하는 것입니다.

애플리케이션이 실행된 후 얼마 지나지 않아 이 데이터를 지연 로드할 수 있습니다.

ProfilingManager: 느린 이유 캡처

ProfilingManager (API 35)를 사용하면 앱에서 사용자 기기의 시스템 트레이스를 프로그래매틱 방식으로 트리거할 수 있습니다. 이는 로컬에서 재현할 수 없는 일시적인 성능 문제를 포착하는 데 유용합니다.

목표는 특정 매우 중요한 사용자 여정이 느리게 실행되거나 성능 문제가 발생하는 것으로 감지되면 트레이스를 자동으로 기록하는 것입니다.

특정 조건이 충족될 때 트리거되는 리스너를 등록하거나 버벅거림, 과도한 메모리, 배터리 소모와 같은 성능 문제가 감지되면 수동으로 트리거할 수 있습니다.

프로필을 캡처하고, 프로파일링 데이터를 가져오고 분석하고, 디버그 명령어를 사용하는 방법에 관한 문서를 확인하세요.

ApplicationExitInfo: 앱이 종료된 이유 추적

ApplicationExitInfo (API 30)는 이전 프로세스가 종료된 이유를 알려줍니다. 이는 과도한 메모리 사용 (OOM)으로 인한 네이티브 비정상 종료, ANR 또는 시스템 종료를 찾는 데 중요합니다. API getTraceInputStream을 사용하여 자세한 툼스톤 트레이스를 가져올 수도 있습니다.

API의 목표는 메모리 부족 종료와 같은 표준 Java 비정상 종료 보고자를 트리거하지 않는 안정성 문제를 파악하는 것입니다.

다음 앱 실행 시 이 API를 트리거해야 합니다. 

다음 단계

Android 성능 개선은 단계별 여정입니다. 이러한 도구를 사용하여 성능을 개선하는 방법을 확인해 보세요.

내일 Ask Android를 시청하세요

R8로 앱을 축소하고 프로필 기반 최적화로 런타임을 최적화했습니다. 앱의 성능을 측정하세요.

내일 라이브 Ask Android 세션에 참여하세요. #AskAndroid를 사용하여 지금 질문하고 전문가의 답변을 받으세요.