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 '!' is excluded 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.
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
maximum.inlined.code.length(default = 8 bytes)
maximum.resulting.code.length(default = 8000 bytes for JSE, 2000 bytes for JME)
ProGuard provides the
-optimizeaggressively option. If set, this enables more aggressive assumptions during optimization. This might lead to improved performance and/or reduced code size, but might result in different behavior in rare cases. For example, reading from an array might cause an
ArrayIndexOutOfBoundsException to be thrown. Strictly speaking, this means that such an instruction can have a side effect. If this instruction is removed during optimization, the code will thus behave differently under specific circumstances. By default, such instructions are always preserved. Setting this option will lead to these instructions being candidates for removal during optimization. Additionally, class merging is only enabled when this option is set.
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:
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).
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 explicitly kept again in the ProGuard configuration so that they can be safely accessed through reflection.