Ship a Baseline Profile with react-android

[shubh73]

Summary:

react-android doesn't ship a Baseline Profile, so after every install or update, the Java/Kotlin that React Native runs to show the first screen (host setup, Fabric mounting, view managers and their prop setters, Yoga) is interpreted and JIT-compiled on every cold start until background dexopt catches up. AndroidX ships a baseline-prof.txt in most of its AARs for this reason.

This adds ReactAndroid/src/main/baseline-prof.txt. AGP packages it into the AAR and merges it into every app's profile, so apps don't need to change anything. Play compiles it at install; other installs pick it up through ProfileInstaller, which apps already get from AndroidX.

It has 724 classes and 2,544 methods, collected from a cold start of RNTester and scrolling its component list, filtered to ReactAndroid's classes. Every method is marked HSP, like AndroidX does, because Android 14 and older (and low-RAM devices) only compile methods marked hot at install. About 230 rules are for lambdas D8 generates from ReactAndroid's classes. R8 recreates those for minified apps, but D8 doesn't for non-minified ones (the template's default), so they stay.

What it improves is time to full display, i.e. when React Native's first content is on screen. Time to initial display doesn't move, since what runs before the first frame is mostly native and framework code. The gain grows with how much UI the first screen mounts: about 2% on the template's hello world (within noise), 7–9% on RNTester and 12–13% on a feed-like first screen.

On Play, cloud profiles eventually cover the same code, but only after early users of each release have run it, only for Play installs on Android 9+, and Google notes they "only scale well for apps that have a sufficiently large user base". This covers Play installs and updates from the first launch, and other installs once background dexopt has run.

To keep the profile maintainable:

• BaselineProfileGenerator (next to RNTesterStartupBenchmark) collects it, and fails rather than collecting a partial journey.
• scripts/update-android-baseline-profile.js keeps ReactAndroid's rules, marks them HSP and sorts them so updates diff cleanly. --check fails if a rule names a class or method that no longer exists, without needing a device. I'm happy to wire it into CI in a follow-up.
• -Preact.internal.disableMinifyInReleaseBuilds=true turns off R8 for RNTester so the collected names match ReactAndroid. The default is unchanged.
• Macrobenchmark goes from 1.3.3 to 1.5.0, since 1.3.3 can't parse pm dump-profiles on Android 16. Only the benchmark module uses it.

Rules that stop matching are ignored, so a stale profile only loses coverage. I didn't use the Baseline Profile Gradle plugin because it keeps the flags ART recorded, and in the collected profile only 235 of about 10,000 methods are marked hot, so most of it wouldn't be compiled on Android 14 and older. It would also add a plugin to ReactAndroid's build.

I also tried a wider journey that typed into a TextInput, pressed Pressables and opened the Image and ActivityIndicator examples. It added 866 methods and made startup about 1.6% slower than this profile, even on a screen that uses those components, so I kept the journey to startup.

Changelog:

[ANDROID] [ADDED] - Ship a Baseline Profile with react-android so that React Native's startup code is compiled ahead of time

Test Plan:

OnePlus CPH2667, Android 16, release builds installed the way Play installs them (adb install-multiple app.apk app.dm, with the .dm from profgen extractProfile), checked with pm art dump (speed-profile, install-dm). "Without" still has AndroidX's profiles. Each comparison rotates the builds across package IDs in a Latin square and launches them interleaved in random order; confidence intervals are 95% bootstrap intervals. Time to full display is reportFullyDrawn() on React Native's first content, time to initial display is am start -W.

First screen	Cold starts each	Without	With	Change	95% CI
Template hello world	320	386.5 ms	377 ms	−2.0%	−4.5% to +0.6%
RNTester (R8 on)	320	535 ms	488 ms	−8.7%	−10.3% to −7.1%
Template, ~750 views (150 feed rows)	180	1,030 ms	901.5 ms	−12.5%	−13.3% to −11.6%
Same, plus a TextInput, an ActivityIndicator and an Image per row	180	1,188 ms	1,028.5 ms	−13.2%	−14.0% to −12.4%

Values are median time to full display. Hello world is pooled from two runs on different days and is within noise.

Time to initial display doesn't change: −1.5% (−3.9% to +0.8%) on RNTester and −0.1% (−2.5% to +2.4%) on the 750-view template. A repeat of the RNTester run on a warmer phone gave −6.9% (−9.0% to −4.8%).

RNTesterStartupBenchmark, 3 × 10 iterations each way (with startActivityAndWait() swapped for am start -W locally, as it can't confirm launches on ColorOS):

# BEFORE

timeToFullDisplayMs      min  864.1,   median  928.5,   max 1055.2
timeToInitialDisplayMs   min  489.0,   median  533.5,   max  641.2

# AFTER

timeToFullDisplayMs      min  753.5,   median  907.4,   max 1145.6
timeToInitialDisplayMs   min  465.5,   median  538.6,   max  707.0

Time to initial display is within noise here, consistent with the interleaved runs above. Macrobenchmark traces every iteration and runs the builds back to back, so I'd trust the interleaved numbers more.

Cost:

• react-android release AAR: 48,486,181 → 48,517,339 bytes. The text file is 336 KB in the npm package (30 KB gzipped).
• RNTester assets/dexopt/baseline.prof: 1.8 KB → 4.7 KB.
• On the template app with images and a TextInput:
  • compile at install (cmd package compile -m speed-profile -f): about 1.03 s → 1.13 s
  • memory 5 s after launch (dumpsys meminfo, median of 5): total PSS unchanged within noise (~101 MB), .art mmap 1.7 → 2.4 MB
• On-device compiled code for the 750-view template (Android 14 emulator): base.odex 617 KB → 1.75 MB, base.art 100 KB → 316 KB. The APK size doesn't change.

To check HSP on older Android, I installed the 750-view template the same way on an Android 14 emulator (API 34, arm64) and counted compiled methods with oatdump: 384 React Native methods are compiled at install without the profile, and 2,692 with it. With the same rules marked SP instead of HSP, it stays at 384, which is why every rule is HSP.

Regenerating with the steps in BaselineProfileGenerator's KDoc reproduces the committed file exactly. node scripts/update-android-baseline-profile.js --check passes (3,037 rules checked; D8-generated names are skipped), and fails as expected with a bogus class and method appended. node scripts/format-kotlin.js --check, prettier and eslint pass.

I could only measure startup on one phone, so I haven't been able to time this on Android 14 or older, on a low-RAM device or on other OEMs, and I haven't run CI's build_android. If you'd like startup numbers from one of those before merging, I'd love for someone with such a device to give it a quick try.

🤖 Generated with Claude Code