Minimize the bundle size using Proguard #16
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Minimize the bundle size by using Proguard
Before: 12.5 MB
With Proguard: 4.83 MB (reduced by 59.30%)
With Proguard (obfuscation enabled): 2.86 MB (reduced by 75.91%)
The
proguard
task is configured to use the rules that are included in the JAR file inMETA-INF/proguard
which will exist even if not using Proguard, as the required rules won't be included by default as there might be some downsides, one of them if a library update the rules we will have to update the library to get the updated rules, another way to address this is by fetching the rules from the repository and include it in a task, this also have downsides, some new rules for the updated library might not work with the current versionWe also could manually update the rules and this will require checking if the rules have been updated when updating the libraries that have Proguard support, this solution is commonly used by most projects
I have not encountered any issues with the current solution and it's similar to R8
I have updated OkHttp from
4.10.0
to4.12.0
to fix some warnings as the latest stable has default rules (inMETA-INF/proguard/okhttp3.pro
) that will fix the encountered warnings, this change could be reverted and fixed either by including the latest rules manually (could be outdated after a while) or only the changes, or ignore the warnings.The
proguard
task will read the rules fromMETA-INF/proguard
The libraries in the project that support Proguard are:
There might be other dependencies that support Proguard such as Google Guava (https://github.com/google/guava/wiki/UsingProGuardWithGuava) though the rules are in a custom location (https://github.com/google/guava/tree/master/proguard) instead of
resources/META-INF/proguard
as a result the task won't be able to include it and will have to include it manuallyIt's not recommended to use
-ignorewarnings
, see this comment for more detailsIf the warning has an import that's from the JDK, try to include the required modules from the JDK, I included only the required modules so in the future if you use a new module, you will have to include it manually and will get warning that cause build failure, we could also include all modules
Proguard will be able to detect the most common usages of reflections and will cause a build failure with warnings that need to be solved (https://www.guardsquare.com/manual/home) to avoid runtime exceptions, however, some warnings should be suppressed as it will not cause any issues
I disabled obfuscation to make debugging easier, although if you want to save more, we might want to consider enabling it.
I haven't fully tested the CLI yet.
The GitHub workflow could upload the minimized JAR file in Github releases (with a note indicating it's not stable yet), or release this change as experimental to avoid disrupting the developers
This change might introduce additional maintenance needs, we could also drop the change.