앱 벤치마크
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
벤치마킹은 앱 성능을 검사하고 모니터링하는 방법입니다. 정기적으로 벤치마크를 실행하여 성능 문제를 분석 및 디버그하고 최근 변경사항에서 회귀가 발생하지 않는지 확인할 수 있습니다.
Android에서는 앱에서 여러 가지 상황을 분석하고 테스트하는 데 유용한 두 가지 벤치마킹 라이브러리와 접근 방식인 Macrobenchmark와 Microbenchmark를 제공합니다.
Macrobenchmark
Macrobenchmark 라이브러리는 시작, UI 상호작용, 애니메이션 같은 좀 더 큰 최종 사용자 상호작용을 측정합니다. 이 라이브러리는 테스트 중인 성능 환경을 직접 제어할 수 있도록 합니다. 이를 통해 컴파일을 제어할 수 있으며 앱을 시작하고 중지하여 실제 앱 시작 또는 스크롤을 직접 측정할 수 있습니다.
Macrobenchmark 라이브러리는 테스트로 빌드된 테스트 앱의 외부에서 이벤트를 삽입하고 결과를 모니터링합니다. 따라서 벤치마크를 작성할 때 앱 코드를 직접 호출하지 않고 대신 사용자로 앱 내에서 탐색합니다.
Microbenchmark
Microbenchmark 라이브러리를 사용하여 루프에서 직접 앱 코드를 벤치마킹할 수 있습니다.
내부 루프나 특정 핫 함수를 사용할 때처럼, CPU 작업(예: JIT 준비, 디스크 액세스 캐시)을 측정해 최상의 성능을 평가하도록 설계되었습니다. 이 라이브러리는 격리된 상태로 직접 호출할 수 있는 코드만 측정할 수 있습니다.
복잡한 데이터 구조를 처리해야 하거나 앱 실행 중 여러 번 호출되는 특정한 컴퓨팅 집약 알고리즘이 있는 앱의 경우 벤치마킹의 좋은 예가 될 수 있습니다. UI의 일부를 측정할 수도 있습니다. 예를 들어 RecyclerView 항목 결합의 비용, 레이아웃을 확장하는 데 걸리는 시간, 성능 측면에서 볼 때 View 클래스의 레이아웃-측정 패스 난이도를 측정할 수 있습니다.
하지만 벤치마킹된 사례가 전반적인 사용자 환경에 미치는 영향을 측정할 수는 없습니다. 일부 시나리오에서는 벤치마킹이 버벅거림이나 앱 시작 시간과 같은 병목 현상이 개선되는지 알려주지 않습니다. 따라서 Android 프로파일러를 사용하여 이러한 병목 현상을 먼저 식별하는 것이 중요합니다.
조사하고 최적화할 코드를 찾으면 벤치마킹된 루프를 빠르고 쉽게 반복적으로 실행하여 노이즈가 적은 결과를 생성할 수 있으므로 개선 영역 하나에 집중할 수 있습니다.
Microbenchmark 라이브러리는 시스템 전반의 정보가 아닌 앱 정보만 보고합니다. 따라서 전반적인 시스템 문제와 관련된 상황이 아닌 앱과 관련 상황의 성능을 분석하는 데 가장 좋습니다.
벤치마크 라이브러리 비교
|
Macrobenchmark |
Microbenchmark |
| API 버전 |
23 이상 |
14 이상 |
| 기능
|
활동 시작 또는 목록 스크롤과 같은 상위 수준 진입점 또는 상호작용 측정 |
개별 기능 측정
|
| 범위
|
별도 프로세스에서 전체 앱 테스트 |
프로세스 내에서 CPU 작업 테스트
|
| 속도
|
중간 반복 속도(1분 초과 가능) |
빠른 반복 속도(일반적으로 10초 미만) |
| Tracing
|
결과에 프로파일링 트레이스 포함 |
선택적 메서드 샘플링 및 추적 |
추천 서비스
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-08-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-08-27(UTC)"],[],[],null,["Benchmarking is a way to inspect and monitor the performance of your app. You\ncan regularly run benchmarks to analyze and debug performance problems and help\nensure that you don't introduce regressions in recent changes.\n\nAndroid offers two benchmarking libraries and approaches for analyzing and\ntesting different kinds of situations in your app: Macrobenchmark and\nMicrobenchmark.\n\nMacrobenchmark\n\nThe [Macrobenchmark](/studio/profile/macrobenchmark) library measures larger end-user interactions, such as\nstartup, interacting with the UI, and animations. The library provides direct\ncontrol over the performance environment you're testing. It lets you control\ncompiling and lets you start and stop your app to directly measure actual app\nstartup or scrolling.\n\nThe Macrobenchmark library injects events and monitors results externally from a\ntest app that is built with your tests. Therefore, when writing the benchmarks,\nyou don't call your app code directly and instead navigate within your app as a\nuser.\n\nMicrobenchmark\n\nThe [Microbenchmark](/studio/profile/benchmark) library lets you benchmark app code directly in a loop.\nThis is designed for measuring CPU work that assesses best-case performance---such\nas warmed up Just in Time (JIT) and disk accesses cached---that you might see with\nan inner-loop or a specific hot function. The library can only measure the\ncode that you can call directly in isolation.\n\nIf your app needs to process a complex data structure, or have some specific\ncomputation-heavy algorithm that is called multiple times during the app run,\nthese might be good cases for benchmarking. You can also measure parts of your\nUI. For example, you can measure the cost of the `RecyclerView` item binding,\nhow long it takes to inflate a layout, or how demanding the layout-and-measure\npass of your `View` class is from a performance perspective.\n\nHowever, you aren't able to measure how the benchmarked cases contribute to the\noverall user experience. In some scenarios, benchmarking doesn't tell you if\nyou're improving a bottleneck like jank or app startup time. For this reason,\nit's crucial to identify those bottlenecks first with the [Android Profiler](/studio/profile).\nAfter you find the code you want to investigate and optimize, the benchmarked\nloop can run repeatedly in a quick and easier fashion to create less noisy\nresults, which lets you focus on one area of improvement.\n\nThe Microbenchmark library only reports information about your app, not about\nthe system overall. Therefore, it's best at analyzing performance of situations\nspecific to the app, not ones that might relate to overall system issues.\n\nBenchmark library comparison\n\n| | Macrobenchmark | Microbenchmark |\n|-------------|-----------------------------------------------------------------------------------------------|---------------------------------------------------|\n| API version | 23 and later | 14 and later |\n| Function | Measure high-level entry points or interactions, such as activity launch or scrolling a list. | Measure individual functions. |\n| Scope | Out-of-process test of full app. | In-process test of CPU work. |\n| Speed | Medium iteration speed. It can exceed a minute. | Fast iteration speed. Often less than 10 seconds. |\n| Tracing | Results come with profiling traces. | Optional method sampling and tracing. |\n\nRecommended for you\n\n- Note: link text is displayed when JavaScript is off\n- [Create Baseline Profiles {:#creating-profile-rules}](/topic/performance/baselineprofiles/create-baselineprofile)\n- [JankStats Library](/topic/performance/jankstats)\n- [Overview of measuring app performance](/topic/performance/measuring-performance)"]]
