LGTM

Iirc, there are a set of compressed assets in APKs that should be uncompressed on disk for fast app starts. The bundle is one of them. Nice find.

Is there a middle ground though rather than making apks all bigger? I believe in the FB app we have the bundle compressed in the apk and then on first launch we uncompressed it on disk. That makes all subsequent launches fast.

Is that a reasonable approach here?

Is there a middle ground though rather than making apks all bigger? I believe in the FB app we have the bundle compressed in the apk and then on first launch we uncompressed it on disk. That makes all subsequent launches fast.

How would that be implemented? As in, added native code that manually uncompresses the bundle on first launch, writes the uncompressed data to disk (caches?) and then uses that for future launches? Or can you overwrite the existing compressed resource?

Yep, exactly like that. 🙂

I'm not sure how the ota clients like expo-updates work but you'd want to do that when the updates are downloaded too

I think such a change would require significantly more effort - and I'm honestly not sure if it's worth the effort.

Download size is roughly the same with my PR, because Google Play compresses the .apk again, so the .bundle is compressed on their servers.
Users download roughly the same amount of MB.
Once they install the app, it uncompresses and is a bit larger now than it was before.

With your change, the uncompression is just delayed after the first launch, instead of before. Not sure if that really makes sense for the added complexity? Especially if you consider that this will be native code and could throw/crash.

Btw for everyone else; you can pull in this change in your apps already by simply setting noCompress in your build.gradle. More info in this tweet

  android {
+   androidResources {
+     noCompress += ["bundle"]
+   }
  } 

I loved how you gave credit for all the team, keep the good work!

Can we make it at least configurable, please? Not all apps deploys by google play. There are other distribution channels. Also QA team frequently downloads just apk, not aab. The size of the app already hit us hard with the update to fresh agp, when .so files stopped compressing.

@elicwhite Is there a difference between this and decompressing on first launch? I would think this is more efficient, since we would have 2 copies of the bundle after.

Having the bundle uncompressed also doesn’t make much difference for apk / download size since it is already compressed, will only affect disk size once installed.

Maybe we could allow opting out via a plugin option if we are worried about install size?

I defer to the Android folks on the team who are better equipped to balance the tradeoffs with you. I just wanted to share early thoughts based on my understanding of what we do for the FB app.

I ran this for an arm64-v8a AAB that's 33.3 MB in download size, 75.9 MB in install size, and 11.3 MB in hbc bundle size. After turning off compression the install size grows by 6.1 MB (+8%) to 82 MB, download size is unchanged.

In case of this app, 10 MB is easily downloaded onto user data and cache at first usage, so I'd happily accept this change by default, although maybe not in core but in a default template. Would be great to add a comment on documenting the trade-offs, in case of someone can accept lack of mmapping to have a slightly smaller app size.

Used ruler for testing.

Some thoughts. First of all, this is a very promising improvement. But why we can't just put it into starting app template?

• It will be configurable
• It will be documented and easy discoverable
• Maintenance cost ~ 0 (current solution will require config option, tuning in case someone will use js bundles with different names, etc...)
• There may be more exotic consequences, for example, the application may use other resources with the suffix ".bundle"

I just checked how @mrousavy wrote, added the snippet to the file android/app/build.gradle and it actually works. Just this snippet do the work:

    androidResources {
        noCompress += ["bundle"]
    }

Plan to do some perf measures tomorrow.

Can we make it at least configurable, please?

Sure, I just pushed a commit that makes this configurable.
I added react.enableBundleCompression, which is by default false - so no compression (Faster by default).
If you want smaller APKs at the cost of slower app startup, simply set this to true.

But why we can't just put it into starting app template?

Not every app is built with the template, and I think this is a react-native-specific thing. The code for loading the .bundle is inside react-native, so it would be the right place to also specify that said bundle should not be compressed for it to work more efficiently. The template doesn't really have anything to do with that. Such configuration is now possible in the react { block of the template.

So with my latest commit you can now opt-out of this change:

react {
  enableBundleCompression = true

And with bba4d06 it now also works if you have a custom bundleAssetName - e.g. a different file extension than .bundle.

This is something we wouldn't easily be able to do if this code was in the template instead of core, because it'd be much harder to get the value of bundleAssetName. Or have two different ways of configuring - which I don't like. Single source of truth FTW

Thank you! Now patch looks very solid and complete! Hope it will be merged soon!

LGTM

LGTM

LGTM

@cortinico has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

The React Native Avengers did it again! Good catch!

That's great find @mrousavy!! We're discussing if we want to have compression enabled by default (current status) or not.

In the meantime, I've run some benchmarks on RNTester here:

• Setup a Macrobenchmark for RNTester #49482

The win in terms of app startup is around ~1%. That's most likely because the RNTester bundle is not huge (1.8Mb). More complex apps will benefit more depending on their bundle size. It would be great to do some benchmarks for some OSS apps rather than just mentioning '12% faster' for every app as this could be misleading.

In the Expensify app, this improved our Android TTI by 14-20%: Expensify/App#56930

Great find! We're seeing 3-5% improvement of the app start performance, no impact on download size, but increase of app install size (~15%).

@mrousavy I've pushed 26a6cc4 which uses finalizeDsl rather than afterEvaluate which is preferable.

@cortinico has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

thanks nicola!

@cortinico merged this pull request in 778382a.

This pull request was successfully merged by @mrousavy in 778382a

^{When will my fix make it into a release? | How to file a pick request?}

woohoo, thanks !! 🚀

@mrousavy, serious thanks to you for finding such a huge bug. The economic impact of this fix across the industry will be significant. Thank you for the care you've shown React Native and investigation you've done to find this.

Quintessential example of a one line fix.

🙏

it was a team effort (Szymon + Janic + Ruby from Discord) - but thanks Eli! ❤️

I've worked to improve the benchmark in RN tester: #49486.

Here's my findings when running the benchmark with a bundle size of 10.5mb on Samsung Galaxy A03s:

Compression ON

Peak allocated memory

60.9 mb

ReactInstance.loadJSBundle

148.64 ms

Benchmark

timeToFullDisplayMs min 1,825.0, median 1,911.1, max 1,994.8
timeToInitialDisplayMs min 834.9, median 860.9, max 903.9

APK

Size: 22.9 mb
Download size: 14.5 mb

Compression OFF

Peak allocated memory

51.5 mb

ReactInstance.loadJSBundle

946 us

Benchmark

timeToFullDisplayMs min 1,752.8, median 1,827.2, max 1,977.5
timeToInitialDisplayMs min 837.7, median 881.3, max 937.2

APK

Size: 28 mb
Download size: 14.5 mb

The bigger the bundle, the larger the improvement is.