Menu Close

ProGuard manual | Optimizations

ProGuard manual

Optimizations

The optimization step of ProGuard can be switched off with the-dontoptimize option. For more fine-grained control over individual optimizations, experts can use the-optimizations option, with a filter based on the optimization names listed below. The filter works like any filter in ProGuard.

The following wildcards are supported:

?matches any single character in an optimization name.
*matches any part of an optimization name.

An optimization that is preceded by an exclamation mark '!' isexcluded from further attempts to match with subsequent optimization names in the filter. Make sure to specify filters correctly, since they are not checked for potential typos.

For example, "code/simplification/variable,code/simplification/arithmetic" only performs the two specified peephole optimizations.

For example, "!method/propagation/*" performs all optimizations, except the ones that propagate values between methods.

For example, "!code/simplification/advanced,code/simplification/*" only performs all peephole optimizations.

Some optimizations necessarily imply other optimizations. These are then indicated. Note that the list is likely to change for newer versions, as optimizations are added and reorganized.

library/gson
Optimizes usages of the Gson library, whenever possible. See Gson optimization for more details.
class/marking/final
Marks classes as final, whenever possible.
class/unboxing/enum
Simplifies enum types to integer constants, whenever possible.
class/merging/vertical
Merges classes vertically in the class hierarchy, whenever possible.
class/merging/horizontal
Merges classes horizontally in the class hierarchy, whenever possible.
class/merging/wrapper
Merges wrapper classes with their wrapped classes, whenever possible.
field/removal/writeonly (⇒ code/removal/advanced)
Removes write-only fields.
field/marking/private
Marks fields as private, whenever possible.
field/propagation/value (⇒ code/simplification/advanced)
Propagates the values of fields across methods.
method/marking/private
Marks methods as private, whenever possible (devirtualization).
method/marking/static (⇒ code/removal/advanced)
Marks methods as static, whenever possible (devirtualization).
method/marking/final
Marks methods as final, whenever possible.
method/marking/synchronized
Unmarks methods as synchronized, whenever possible.
method/removal/parameter (⇒ code/removal/advanced)
Removes unused method parameters.
method/propagation/parameter (⇒ code/simplification/advanced)
Propagates the values of method parameters from method invocations to the invoked methods.
method/propagation/returnvalue (⇒ code/simplification/advanced)
Propagates the values of method return values from methods to their invocations.
method/inlining/short
Inlines short methods.
method/inlining/unique
Inlines methods that are only called once.
method/inlining/tailrecursion
Simplifies tail recursion calls, whenever possible.
code/merging
Merges identical blocks of code by modifying branch targets.
code/simplification/variable
Performs peephole optimizations for variable loading and storing.
code/simplification/arithmetic
Performs peephole optimizations for arithmetic instructions.
code/simplification/cast
Performs peephole optimizations for casting operations.
code/simplification/field
Performs peephole optimizations for field loading and storing.
code/simplification/branch (⇒ code/removal/simple)
Performs peephole optimizations for branch instructions.
code/simplification/object
Performs peephole optimizations for object instantiation.
code/simplification/string
Performs peephole optimizations for constant strings.
code/simplification/math
Performs peephole optimizations for Math method calls.
code/simplification/advanced (best used with code/removal/advanced)
Simplifies code based on control flow analysis and data flow analysis.
code/removal/advanced (⇒ code/removal/exception)
Removes dead code based on control flow analysis and data flow analysis.
code/removal/simple (⇒ code/removal/exception)
Removes dead code based on a simple control flow analysis.
code/removal/variable
Removes unused variables from the local variable frame.
code/removal/exception
Removes exceptions with empty try blocks.
code/allocation/variable
Optimizes variable allocation on the local variable frame.

ProGuard also provides some unofficial settings to control optimizations, that may disappear in future versions. These are Java system properties, which can be set as JVM arguments (with -D...):

maximum.inlined.code.length (default = 8 bytes)
Specifies the maximum code length (expressed in bytes) of short methods that are eligible to be inlined. Inlining methods that are too long may unnecessarily inflate the code size.
maximum.resulting.code.length (default = 8000 bytes for JSE, 2000 bytes for JME)
Specifies the maximum resulting code length (expressed in bytes) allowed when inlining methods. Many Java virtual machines do not apply just-in-time compilation to methods that are too long, so it's important not to let them grow too large.
optimize.conservatively (default = unset)
Allows input code with ordinary instructions intentionally throwingNullPointerException, ArrayIndexOutOfBoundsException, orClassCastException, without any other useful purposes. By default, ProGuard may just discard such seemingly useless instructions, resulting in better optimization of most common code.

Gson optimization

ProGuard optimizes Gson code by detecting which domain classes are serialized using the Gson library. It replaces the reflection-based implementation of GSON for reading and writing fields with injected and optimized code that accesses the fields of the domain classes directly when reading and writing JSON. The benefits of this optimization are the following:

Configuration

The Gson optimization is enabled by default and doesn't require any additional configuration, as long as the application code doesn't use unsupported Gson features (see Known limitations).

Known limitations

ProGuard can not optimize the following use cases of Gson:

When one of the above Gson features is used, ProGuard automatically preserves the original Gson implementation for all affected domain classes.

This means that the serialized fields of these domain classes need to be explicitely kept again in the DexGuard configuration so that they can be safely accessed through reflection.