앱 최적화를 사용 설정한 후 앱이 의도한 대로 작동하고 R8 구성이 예상대로 작동하는지 확인합니다. 일반적인 단계는 다음과 같습니다.
앱의 중요한 사용자 여정 (CUJ) 테스트: 예를 들어 사용자가 로그인하고 다른 중요한 작업을 할 수 있는지 확인합니다.
벤치마크를 사용하여 성능 향상 측정: 앱 최적화를 사용 설정하기 전후에 앱을 벤치마킹합니다.
문제가 발견되면 R8에서 문제 해결에 도움이 되는 도구를 제공합니다. R8 관련 문제를 해결할 수 없는 경우 버그를 신고하세요.
일반적인 도움말
R8 관련 문제는 앱마다 고유한 경우가 많지만 다음은 디버깅을 더 쉽게 하는 데 도움이 되는 몇 가지 일반적인 도움말입니다.
난독화를 일시적으로 사용 중지: R8은 최적화 프로세스의 일환으로 코드를 난독화합니다. 난독화는 일반적으로 오류의 원인이 아니지만 난독화로 인해 오류를 디버그하기가 더 어려워집니다. 문제가 있는 코드를 정확하게 파악할 수 있도록 keep 규칙 파일에 ‑dontobfuscate 및 ‑dontoptimize 플래그를 추가합니다.
반사 확인: 다음과 같은 no such element 예외가 발생하면
Caused by: java.util.NoSuchElementException: Collection contains no element
matching the predicate in the stack trace ,
이 예외는 일반적으로 해당 필드가 리플렉션을 통해 사용되고 있으므로 유지 규칙을 추가해야 함을 의미합니다.
바이트 코드 검사: 대부분의 R8 문제에는 바이트 코드 검사가 필요하며 이는 APK Analyzer와 같은 도구로 할 수 있습니다.
적용된 규칙 확인하기
프로젝트를 빌드할 때 R8이 적용하는 모든 규칙의 전체 보고서를 출력하려면 앱의 모듈 proguard‑rules.pro 파일에 다음을 포함하세요.
경로와 파일 이름을 지정할 수 있습니다. 경로 또는 파일 이름을 지정하지 않으면 R8은 <module-name>/build/outputs/mapping/<build-type>/configuration.txt에 규칙 보고서를 출력합니다.
코드가 유지된 이유 이해
삭제될 것으로 예상했던 코드가 유지된 경우 구성 옵션 ‑whyareyoukeeping를 사용하여 코드가 유지된 이유를 파악하세요. R8은 보관된 코드에서 앱의 진입점 중 하나로의 경로를 출력합니다. 자세한 내용은 Proguard 매뉴얼의 ‑whyareyoukeeping 문서를 참고하세요.
원래 스택 트레이스 복구
R8에서 처리된 코드는 스택 트레이스가 더 이상 원본 코드를 참조하지 않도록 여러 방식으로 변경됩니다. 예를 들어 줄 번호와 클래스 및 메서드의 이름이 변경될 수 있습니다. 원래 스택 트레이스를 복구하기 위해 R8은 명령줄 도구 패키지와 함께 번들로 제공되는 retrace 명령줄 도구를 제공합니다.
retrace를 사용하려면 매핑 파일과 스택 트레이스 파일을 제공합니다. mapping.txt라는 매핑 파일은 Android App Bundle (AAB)과 자동으로 번들로 묶입니다. 자세한 내용은 재추적 문서와 비정상 종료 스택 트레이스를 가독화하는 방법에 관한 Play Console 고객센터 도움말을 참고하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# Test and troubleshoot the optimization\n\nAfter you enable app optimization, check that your app is working as intended\nand that the R8 configuration is doing what you expect. The general steps are as\nfollows:\n\n1. **Test your app's critical user journeys (CUJs):** For example, make sure that users can sign in and do other important tasks.\n2. **Measure performance gains using benchmarks:** [Benchmark your app](/topic/performance/benchmarking/benchmarking-overview) before and after enabling app optimization.\n\nIf you find issues, R8 provides tools to help you troubleshoot. If you're unable\nto solve an issue with R8, [file a bug](https://b.corp.google.com/issues/new?component=326788&template=1025938&pli=1).\n\nGeneral tips\n------------\n\nIssues with R8 are often unique to your app, but here are some general tips to\nmake debugging easier:\n\n- **Temporarily turn off obfuscation:** R8 obfuscates code as part of its optimization process. Obfuscation usually isn't the cause of errors, but obfuscation makes errors more difficult to debug. Add the `‑dontobfuscate` and `‑dontoptimize` flags to the keep rules file to help you pinpoint problematic code.\n- **Check for reflection:** If you run into a *no such element* exception such\n as\n\n `Caused by: java.util.NoSuchElementException: Collection contains no element\n matching the predicate in the stack trace` ,\n\n the exception usually means the field in question is being used through\n reflection and you have to add a keep rule.\n- **Inspect bytecode:** Most R8 issues require bytecode inspection, which you\n can do with tools such as the [APK Analyzer](/studio/debug/apk-analyzer).\n\nCheck which rules are applied\n-----------------------------\n\nTo output a full report of all the rules that R8 applies when building your\nproject, include the following in your app's module\n`proguard‑rules.pro` file: \n\n -printconfiguration \u003coutput-dir\u003e/\u003creport-name\u003e.txt\n\nYou can specify any path and filename. If you don't specify a path or filename,\nR8 outputs the rules report at `\u003cmodule-name\u003e/build/outputs/mapping/\u003cbuild-type\u003e/configuration.txt`.\n\nUnderstand why code was kept\n----------------------------\n\nIf you see kept code that you expected to be removed, use the configuration\noption `‑whyareyoukeeping` to help understand why the code was\nkept. R8 outputs a path from the kept code to one of your app's [entry\npoints](/topic/performance/app-optimization/add-keep-rules#how-write). For more information, see the\n[`‑whyareyoukeeping`](https://www.guardsquare.com/manual/configuration/usage)\ndocumentation in the Proguard manual.\n\nRecover the original stack trace\n--------------------------------\n\nCode processed by R8 is changed in various ways so that the stack trace no\nlonger refers to the original code. For example, line numbers and the names of\nclasses and methods can change. To recover the original stack trace, R8 provides\nthe retrace command-line tool, which is bundled with the command-line tools\npackage.\n\nTo use retrace, give it a *mapping file* and a stack trace file. The mapping\nfile, called `mapping.txt`, is automatically bundled with your Android App\nBundle (AAB). For more details, see the [retrace](/studio/command-line/retrace) documentation and the Play\nConsole Help Center article about how to [de‑obfuscate crash stack\ntraces](https://support.google.com/googleplay/android-developer/answer/9848633).\n| **Warning:** If you're shipping APKs, the `mapping.txt` file isn't automatically bundled with your APK. Android Studio saves the mapping file in the `/build/outputs/mapping/` directory. The mapping file is overwritten every time you build your project, so you must save a copy each time you publish a new release."]]
