[[["わかりやすい","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,["# Adopt optimizations incrementally\n\nBy default, R8 makes a lot of optimizations to improve performance and size, but\nthe optimizations might not work for your app immediately. If you're turning on\nR8 (or enabling [full mode](#use-compat)) in a big app for the first time, try\nto adopt optimizations incrementally: temporarily turn off obfuscation and\nenable R8 for portions of code at a time, rather than for all the code in your\napp. We recommend taking this incremental approach during local development, but\nyou can also use it during internal QA testing or even in production as a\ngradual rollout. The exact steps you take depend on your desired timeline and\nconfidence in your pre-release testing coverage.\n\nLimit the optimizations\n-----------------------\n\nR8 does many types of optimizations including removing code, rewriting code, and\nremoving resources. Here are some high-level descriptions of the optimization\ntypes:\n\n- Code shrinking (or tree shaking): removes unreferenced code\n- Obfuscation (or identifier minification): shortens the names of classes and methods\n- Optimization: rewrites code, for example inlining\n\nTo reduce the chance of errors, you can start by enabling only some of these\noptimizations.\n\n### Enable tree shaking only\n\nCode shrinking, also known as tree shaking, removes code that appears to be\nunreferenced. We recommend starting with just tree shaking, since it's the most\nstraightforward.\n\nTo enable tree shaking only, add the following to your\n`proguard-rules.pro` file to turn off the other types of optimizations. Turning\noff obfuscation is key because it makes stack traces much easier to read. \n\n -dontobfuscate // Use temporarily to turn off identifier minification\n -dontoptimize // Use temporarily to turn off optimization\n\nIn the end, you wouldn't want to ship this configuration, since it drastically\nlimits the ability for R8 to optimize code, but it's a great starting point when\nadopting R8 for the first time in a large codebase with problems to fix.\n\n### Use compat mode\n\nBy default, R8 runs in [*full mode*](https://r8.googlesource.com/r8/+/refs/heads/master/compatibility-faq.md#r8-full-mode). Full mode imparts significantly\nimproved performance and size savings, but you can temporarily disable it and\nuse *compat mode* instead when enabling minification for the first time.\n| **Note:** R8 runs in compat mode by default for Android Gradle plugin versions 7.0 and lower.\n\nTo use compat mode, use the following setting in your `gradle.properties` file: \n\n android.enableR8.fullMode = false // Use temporarily to disable full mode\n\n### Enable the rest of the optimizations\n\nWhen you've confirmed that tree shaking works for your app, you can remove the\npreceding settings to re-enable obfuscation, optimization, and R8 full mode.\nNote that obfuscation can make debugging more difficult, which is why we\nrecommend addressing tree shaking issues first.\n\nFor more information about deobfuscating stack traces, see\n[Recover the original stack trace](/topic/performance/app-optimization/test-and-troubleshoot-the-optimization#recover-original-stack-trace).\n\nLimit the optimization scope\n----------------------------\n\nA fully optimized build optimizes all code across every library and package, so\nit's common to encounter issues with R8 when you first turn it on. If you find a\nproblem with optimization in one part of the app, don't turn off R8 completely\nor you'll lose out on benefits everywhere else. Instead, temporarily disable R8\nonly in the parts of your app that are causing problems.\n\n### Use package-wide keep rules\n\nWe recommend using package-wide keep rules as a way to temporarily disable R8 in\nparts of your app. You should always come back to fix these optimization issues\nlater; this is generally a stop-gap solution to work around problem areas.\n\nFor example, if part of your app uses Gson heavily and is causing problems with\noptimization, the ideal fix is to add more\n[targeted keep rules](/topic/performance/app-optimization/add-keep-rules) or move to a codegen solution. But\nto unblock optimizing the rest of the app, you can place the code defining your\nGson types in a dedicated subpackage, and add a rule like this to your\n`proguard-rules.pro` file: \n\n -keep class com.myapp.json.** { *; }\n\nIf some library you're using has [reflection](https://en.wikipedia.org/wiki/Reflective_programming) into internal\ncomponents, you can similarly add a keep rule for the entire library. You'll\nneed to inspect the library's code or JAR/AAR to find the appropriate package to\nkeep. Again, this isn't recommended to maintain long term, but can unblock the\noptimization of the rest of the app: \n\n -keep class com.somelibrary.** { *; }\n\n| **Note:** Never write a keep rule that keeps all of your app, for example -`keep **` or -`keep com.myapp.**`. These rules prevent optimization across such a wide portion of the app that you'll pay the build cost of R8 with effectively none of the benefit. Instead, always start with library- or package- based keep rules, and try to remove them gradually over time.\n\n### Remove package-wide keep rules\n\nOnce your app functions correctly with package-wide keep rules, you should go\nback and either add [targeted keep rules](/topic/performance/app-optimization/add-keep-rules), or remove the\nreflection usage or library which necessitates the keep rule in the first place.\n\nFor example, keeping all rules which extend a certain class is extremely common\nin AndroidX to keep only relevant classes. Generally, reflection should only\ntarget classes or methods which either extend certain abstract classes,\nimplement certain interfaces, or into classes with a specific runtime\nannotation. Each of these are supported ways to define keep rules so that you\ndon't need package-wide keep rules in your final, fully optimized app."]]
