Skip to content

optimize at build time#281

Open
wassupluke wants to merge 2 commits into
jrpie:masterfrom
wassupluke:build-optimization
Open

optimize at build time#281
wassupluke wants to merge 2 commits into
jrpie:masterfrom
wassupluke:build-optimization

Conversation

@wassupluke
Copy link
Copy Markdown
Contributor

This PR comes about after seeing optimizations turned off in the build settings.

From the Android build optimization documentation

To enable app optimization, set isMinifyEnabled = true (for code optimization)

Check. We've already done this.

and isShrinkResources = true (for resource optimization) in your release build's app-level build script as shown in the following code. We recommend that you always enable both settings. 1

Enabled in this commit.

This cuts the size of the debug build of the app in half (see below [debug] vs [Optimized]).

Screenshot_20260216-211103

Would love to see how this impacts the production size of the app but my little brain isn't figuring out how to get that build from Android Studio to my device right now, alls I can get over are the debug builds. Sucks being dumb. Stay in school, kids.

> To enable app optimization, set `isMinifyEnabled = true` (for code optimization)

Check. We've already done this.

> and `isShrinkResources = true` (for resource optimization) in your release build's app-level build script as shown in the following code. We recommend that you always enable both settings. [1](https://developer.android.com/topic/performance/app-optimization/enable-app-optimization)

Enabled in this commit.

This cut the size of the debug flavor of the app in half.
@jrpie
Copy link
Copy Markdown
Owner

jrpie commented Feb 17, 2026

Not using obfuscation is a deliberate choice, obfuscation does users a disservice imo. It's not like this is some proprietary app where some company is scared about the customers stealing the valuable source code 😂 Obfuscation can make the code a little smaller, but it makes crash reports unreadable (I could keep a mapping with the original symbol names to read crash reports, but users would not be able to understand what they are reporting, it is a massive hassle and does not serve any real purpose except saving a few kb).

Regarding optimization, I think there was some problem with reproducibility, but I don't really remember. If that makes the app much smaller (I'll test a production build later) it might be worthwhile investigating though.

@wassupluke
Copy link
Copy Markdown
Contributor Author

Okay yeah ditch the obfuscation stuff and keep it as is unless it becomes a security thing. I haven't seen anything on this and in a perfect world it stays that way.

For optimization, do you mean reproducibility of reported bugs? Because that would be annoying. But if it truly does what the Android dev docs say and shrinks the app and gets it to run faster, that would be nice. Probably even moreso on lower end devices that may already be trying the minimal launcher to squeeze the most performance out of the device.

As requested by project maintainer: don't obfuscate on build.

***What this flag does***
From the [docs](https://developer.android.com/topic/performance/app-optimization/global-options#global-options-2):
> `-dontobfuscate`: Prevents shortening the names of classes and methods. It can be especially helpful to turn off obfuscation during debugging so stack traces are easier to read. This option can be used during development but shouldn't be used in production builds.
@wassupluke
Copy link
Copy Markdown
Contributor Author

I misnamed that commit. Should have been "re-enable dontobfuscate".

Basically, I uncommented what I had previously commented out.

So now what this PR does is:

  • add shrinking resources
  • remove dontoptimize

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants