성능 테스트를 위한 환경 설정
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
단기간의 기기 활동을 기록하고 앱 시작 기간의 트레이스를 수집하여 잠재적 병목 현상을 식별하고 전반적인 앱 성능을 개선할 수 있습니다. 이 페이지에서는 성능 테스트를 위한 환경을 설정하는 방법을 보여줍니다.
Macrobenchmark 라이브러리 사용
Macrobenchmark 라이브러리는 시작, UI 상호작용, 애니메이션 같은 좀 더 큰 최종 사용자 상호작용을 측정합니다. 이 라이브러리는 테스트 중인 성능 환경을 직접 제어할 수 있도록 합니다. 이를 통해 앱의 컴파일, 시작, 중지를 제어하여 정확한 앱 시작 시간을 직접 측정할 수 있습니다. 또한 테스트 실행 간의 노이즈와 차이를 최소화합니다.
중급 기기를 사용하여 잠재적 성능 문제 식별
관심 있는 각 기기 유형에서 성능을 테스트하세요. 빠른 구성요소가 있는 고급형 기기는 구형이거나 느리거나 RAM이 부족한 기기의 성능 문제를 숨길 수 있습니다.
저사양 기기에서는 데이터를 로드하거나 코드를 실행하는 데 더 오래 걸릴 수 있어 병목 현상을 더 쉽게 파악할 수 있습니다. 저사양 기기의 성능 최적화는 일반적으로 고급형 기기 최적화에도 도움이 됩니다.
노이즈 줄이기
- 네트워크: 강력하고 안정적인 인터넷 Wi-Fi 속도로 앱 또는 프로세스를 테스트합니다. 앱 시작 시간에 네트워크 요청이 포함되면 이를 변동이 발생할 수 있는 곳으로 참고하세요.
- RAM 사용량: 앱 시작 성능을 테스트하는 동안 기기의 백그라운드에서 다른 앱이 실행되지 않아야 합니다.
- 배터리: 하드웨어 관련 저전력 성능 제한을 방지하려면 기기를 충전해야 합니다.
출시 빌드에서 테스트
출시 빌드를 사용하여 성능을 테스트하세요. 디버그 빌드는 컴파일 최적화를 제공하지 않고 성능에 상당한 영향을 미치므로 성능 디버깅에 적합하지 않습니다.
그러나 난독화되지 않은 출시 빌드를 사용하여 클래스 및 작업 이름을 식별하는 것은 괜찮습니다. 특히 proguard 파일에서 -dontobfuscate
를 사용하여 축소(R8)를 사용 설정하고 난독화를 사용 중지하는 것이 좋습니다.
빌드가 난독화되지 않으면 레이아웃과 애셋, 리소스를 더 쉽게 식별할 수 있습니다.
디버그할 수 없는 빌드에 맞춤 이벤트가 표시되도록 매니페스트에 profileable 플래그를 포함해야 합니다. 이 플래그는 Android 10(API 수준 29) 이상에서 사용할 수 있습니다.
앱 작업에 맞춤 트레이스 추가
앱에 맞춤 트레이스를 추가하면 다른 라이브러리에 비해 앱에서 실행하는 작업을 더 쉽게 식별할 수 있습니다. 이렇게 하면 앱이 항상 실행하는 작업에 관한 더 많은 컨텍스트를 파악할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# Set up your environment for performance testing\n\nYou can identify potential bottlenecks and improve overall app performance by\nrecording device activity over a short period of time and [collecting traces of\nyour app's startup period](/topic/performance/tracing). This page shows how to\nset up your environment for performance testing.\n\nUse the Macrobenchmark library\n------------------------------\n\nThe [Macrobenchmark\nlibrary](/topic/performance/benchmarking/macrobenchmark-overview) measures\nlarger end-user interactions, such as startup, interacting with the UI, and\nanimations. The library provides direct control over the performance environment\nyou're testing. It lets you control compiling, starting, and stopping your app\nto directly measure precise app startup time. It also works to minimize the\nnoise and differences between test runs.\n\nUse mid-range devices to identify potential performance issues\n--------------------------------------------------------------\n\nTest performance on each device type you care about. High-end devices with fast\ncomponents can hide performance problems on earlier, slower, or low RAM devices.\nLower-end devices can take longer to load data or run code, making it easier to\nidentify bottlenecks. Optimizing performance for low-end devices usually also\nbenefits optimization for high-end devices.\n\nReduce noise\n------------\n\n- Network: test your apps or processes with strong and stable internet Wi-Fi speeds. If the app startup time includes a network request, note this as a place where variability might occur.\n- RAM usage: don't have any other apps running in the background of your device while testing app startup performance.\n- Battery: ensure your device is charged to avoid any hardware-specific low power performance throttling.\n\nTest on release builds\n----------------------\n\nUse release builds to test performance. Debug builds are [unsuitable for\nperformance\ndebugging](/studio/profile/measuring-performance#apk-considerations), as they\ndon't provide compilation optimization and significantly impact performance.\n\nHowever, it's okay to use an unobfuscated release build to identify classes and\noperation names. Specifically, we recommend enabling [minify\n(R8)](/studio/build/shrink-code) and disabling obfuscation, with\n[`-dontobfuscate`](/studio/build/shrink-code#obfuscate) in the proguard file.\nIt's easier to identify layouts, assets, and resources if the build is\nunobfuscated.\n\nMake sure you include the\n[profileable](/guide/topics/manifest/profileable-element) flag in the manifest\nso that your custom events are visible in non-debuggable builds. This flag is\navailable on Android 10 (API level 29) and later.\n\nAdd custom traces to your app operations\n----------------------------------------\n\nAdd [custom traces](/topic/performance/tracing/custom-events) within your app to\nmake it easier to identify what operations are performed by your app compared to\nother libraries. This helps give you more context about what the app is doing at\nall times."]]