Great question! I’ve seen a lot of developers mix up D8 and R8 because they both handle converting Java bytecode to Dex, but their internal mechanics and roles are actually pretty distinct. Let’s break it down clearly:

1. Primary Purpose & Scope #

• D8 is only a dedicated dexer—its sole job is to take Java bytecode (from .class files or JARs) and convert it directly to Dalvik Executable (.dex) format. It does basic efficiency-focused optimizations, but those are secondary to its core conversion role.
• R8, by contrast, is a full end-to-end pipeline tool that merges ProGuard’s shrinking/obfuscation/optimization capabilities with dex conversion. It doesn’t just convert code—it rewrites and optimizes your entire codebase first before turning it into Dex.

2. Internal Workflow Breakdown #

D8’s Straightforward Pipeline #

1. Input Processing: Reads .class files/JARs, parses bytecode into an intermediate representation (IR).
2. Lightweight Optimizations: Runs simple, fast optimizations like constant folding, obvious dead code elimination, and inlining for tiny methods.
3. Dex Generation: Converts the optimized IR directly into Dex format, handling register allocation, method merging, and adherence to Dex constraints (like the 64k method limit).
4. Output: Spits out .dex files—no shrinking, no obfuscation, just converted and lightly optimized code.

R8’s Comprehensive, Integrated Pipeline #

R8’s workflow starts with parsing but adds heavy, whole-program steps before dex conversion:

1. Input Parsing: Reads .class files, JARs, and your ProGuard rules (if configured).
2. Shrinking: Removes unused code, resources, and dependencies (the "tree shaking" ProGuard is known for). It analyzes app entry points (like Application class, activities) to identify code that’s actually needed.
3. Obfuscation: Renames classes, methods, and fields to short, meaningless names (e.g., a, b, c) to reduce APK size and hinder reverse engineering.
4. Aggressive Optimization: Runs advanced optimizations far beyond D8’s scope:
   • Cross-class method inlining (even for larger methods where it improves performance)
   • Control flow flattening
   • Removal of unused parameters
   • Merging similar classes where possible
   • Constant propagation across the entire codebase
5. Dex Conversion: Once code is shrunk, obfuscated, and heavily optimized, R8 uses its internal dexer (sharing some code with D8 but fully integrated into the pipeline) to convert the optimized IR to Dex.
6. Output: Produces fully optimized, shrunk, obfuscated .dex files ready for APK/AAB packaging.

3. Optimization Depth & Code Analysis #

• D8’s optimizations are class-isolated—it doesn’t analyze cross-class or cross-module dependencies. This makes it fast, but limits the optimization scope.
• R8’s optimizations are whole-program focused. It scans your entire codebase (including third-party dependencies) to make smarter decisions—for example, inlining a dependency method if it’s only used once in your app, or removing an entire unused dependency.

4. Typical Use Cases #

• Use D8 for debug builds or fast development cycles—its speed makes it ideal when you don’t need shrinking/obfuscation. It’s the default dexer in Android Studio for debug builds.
• Use R8 for release builds—it’s designed to produce the smallest possible APK with the best runtime performance, thanks to its end-to-end optimization pipeline.

内容的提问来源于stack exchange，提问作者0xAliHn