성능 테스트
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
앱 런타임 성능은 로컬 테스트와 현장 테스트로 나눌 수 있습니다.
이 두 영역은 모두 서로 다른 결과와 측정항목을 제공합니다. 결과 자체가 확실한 한 이러한 불일치는 허용됩니다.
현장 테스트
필드 테스트를 통해 실제 환경에서 실제 사용자를 대상으로 앱의 성능을 파악할 수 있습니다. 이는 중요한 영역이며 앱이 현장에서 어떻게 작동하는지 이해하는 데 도움이 됩니다. Google Play Vitals 및 Firebase Performance Monitoring과 같은 도구를 사용하여 사용자로부터 현장 측정항목을 가져올 수 있습니다.
AndroidX 추적 라이브러리를 사용하여 트레이스 포인트를 추가하여 필드 측정항목에 더 많은 컨텍스트와 통계를 제공할 수 있습니다.
ApplicationStartInfo 및 ApplicationExitInfo를 사용하여 사용자의 애플리케이션 시작 및 종료에 관한 자세한 정보를 얻을 수도 있습니다.
AndroidX JankStats 라이브러리를 사용하면 추가 분석을 위해 느린 프레임과 드롭된 프레임을 집계하고 보고할 수 있습니다.
로컬 테스트
앱의 런타임 성능을 로컬에서 테스트할 수 있도록 벤치마킹 라이브러리를 제공합니다. 전체 사용자 흐름의 성능을 테스트하는 데 사용할 수 있는 macrobenchmark 라이브러리와 애플리케이션 또는 라이브러리의 핫 루프 성능을 분석하는 데 사용되는 microbenchmark 라이브러리로 나뉩니다.
모든 성능 테스트는 실제 기기에서 실행해야 합니다. 이는 측정하는 성능이 기기에서 발생하는 실제 성능인지 확인하는 유일한 방법입니다. 런타임 성능 테스트는 실행되는 기기와 기기의 사용량에 따라 다른 결과를 생성합니다.
애플리케이션 성능이 저하될 수 있습니다. 회귀를 방지하려면 성능 테스트를 자주 실행해야 합니다. 이상적인 시나리오에서는 새 기능이 추가되거나 코드가 기본 브랜치에 병합될 때마다 앱이 벤치마킹됩니다. 성능 모니터링의 최소한의 요구사항은 출시 후보를 벤치마킹하고 주요 사용자 여정에서 시작 시간과 프레임 타이밍이 저하되지 않는지 확인하는 것입니다.
가능한 경우(예: 기능을 기본 브랜치에 병합하기 전이나 야간 빌드) 항상 벤치마크를 실행하는 것이 좋습니다.
결과 사용
성능 테스트는 지속적인 프로세스입니다. 성능 테스트 결과를 시간 경과에 따라 비교할 수 있는 방식으로 저장하는 것이 좋습니다.
성능 테스트 결과는 여러 가지 방법으로 사용할 수 있습니다.
- 실적 개선 - 측정 결과를 사용하여 실적 개선에 우선순위를 두기
- 회귀 방지 - 새 출시 버전에서 성능 저하가 없는지 확인
- 프로덕션 모니터링 - 개발 중에 발견하지 못하는 문제가 있는지 파악
Android 런타임 성능 테스트에 관한 자세한 내용은 앱 성능 가이드를 참고하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Performance tests\n\nApp runtime performance can be divided into local testing and field testing.\nKeep in mind that both of these areas provide different results and\nmetrics. As long as the results are in itself conclusive, that divergence is\nacceptable.\n\nField testing\n-------------\n\nField testing helps you to understand how an app performs with real users under\nreal world conditions. It is an important area and helps to understand how an\napp performs in the field. You can use tools such as [Google Play Vitals](/topic/performance/vitals) and\n[Firebase Performance Monitoring](https://firebase.google.com/docs/perf-mon) to get field metrics from\nusers.\n\nYou can use the [AndroidX Tracing](/jetpack/androidx/releases/tracing) library to add trace points which\nprovides more context and insights to field metrics.\n\nYou can also use [`ApplicationStartInfo`](/reference/android/app/ApplicationStartInfo) and [`ApplicationExitInfo`](/reference/android/app/ApplicationExitInfo) to\nget more detailed information on application start and exit from users.\n\nThe [AndroidX JankStats](/topic/performance/jankstats) library enables aggregating and reporting of slow\nand dropped frames for further analysis.\n\nLocal testing\n-------------\n\nTo locally test the runtime performance of an app we provide the benchmarking\nlibrary. It is divided into the [macrobenchmark](/topic/performance/benchmarking/macrobenchmark-overview) library, which can be used\nto test the performance of entire user flows and the [microbenchmark](/topic/performance/benchmarking/microbenchmark-overview)\nlibrary, which is used to analyze hot loop performance of an application or\nlibrary.\n\nAll performance tests should run on a physical device. This is the only way to\nensure that the performance you're measuring is the actual performance\noccurring on a device. Runtime performance tests will produce different results\ndepending on the device they run on and how busy the device is.\n\nApplication performance can regress. To avoid regressions it's important to run\nperformance tests frequently. In an ideal scenario an app is benchmarked every\ntime a new feature is added or code is merged into the main branch. The bare\nminimum of performance monitoring is to benchmark release candidates and verify\nthat startup time and frame timing does not regress for major user journeys.\nWe recommend you run benchmarks whenever possible, such as before merging a\nfeature to the main branch or for nightly builds.\n\nUse the results\n---------------\n\nPerformance testing is an ongoing process. We recommend that you store results\nof performance tests in a way that they can be compared over time.\n\nYou can use results of performance tests in several ways.\n\n- Performance improvement - Use measurement results to prioritize performance improvement\n- Regression avoidance - Ensure there are no performance regressions with new releases\n- Production monitoring - Understand whether there are issues you're not seeing during development\n\nTo learn more about Android runtime performance testing, see the\n[guide to app performance](/performance)."]]
