Description
On RN 0.77.3 with the 新建 Architecture, looping animations appear not to be
released when their component unmounts, even though every call site stops the
loop in its cleanup. The number of live loops grows for the life of the
process, so each frame drives more of them and the app gets progressively
slower.
This is a long-running Android app that stays open for days without the process
restarting. A repeated user flow — mounting a screen, doing some work, then
returning to the previous screen — takes ~16s on a freshly started process and
~28s by the 40th repetition, measured with an automated UI soak. Only a process
restart clears it.
Evidence
Bisected to the 0.75.3 -> 0.77.3 upgrade. Building an older source tree
with only the RN upgrade applied — no other application changes — reproduces
it; the same tree on 0.75.3 is flat.
| build |
run 1-10 |
run 31-40 |
slope |
| RN 0.75.3 |
18.0s |
17.9s |
-0.005 s/iteration |
| RN 0.77.3 (only change) |
20.8s |
26.5s |
+0.280 s/iteration |
CPU profiles (Hermes sampling profiler over the inspector, two equal 60s
windows, one early in the session and one after ~30 iterations):
[Host Function] startAnimatingNode 3.3% -> 14.6%
[Host Function] startOperationBatch 1.7% -> 7.6%
getSlope / getTForX / calcBezier 4.7% -> 19.9%
newtonRaphsonIterate 1.1% -> 4.7%
__getNativeAnimationConfig 0.3% -> 1.3%
Roughly a 4x increase in absolute Animated work over equal windows. The hot
frames are the ones that run when an animation starts
(__getNativeAnimationConfig samples the easing curve into a lookup table at
start time), so animations are being started ever more often rather than
running longer.
Isolated to Animated.loop. Neutralising Animated.loop alone — leaving
every timing, spring and sequence untouched — removes the entire
regression:
| build |
run 1-10 |
run 31-40 |
slope |
| unmodified 0.77.3 |
16.4s |
26.1s |
+0.338 s/iteration |
| all animations disabled |
18.0s |
17.9s |
+0.003 s/iteration |
only Animated.loop disabled |
17.8s |
18.0s |
~0.000 s/iteration |
What we ruled out by measurement
useNativeDriver — switching every call site to false changed nothing
(+0.335 vs +0.338), so this is not the native animation module specifically.- Component/view retention — live
Views and AppContexts (dumpsys meminfo)
are flat across the run; threads and file descriptors fall slightly.
- Leaked listeners, unbounded JS containers, navigation stacking (we use
replace/popToTop), our list renderer, NativeWind's babel transform, and
third-party SDK versions.
- Hermes heap growth is real (40 -> 80 MB across 40 iterations) but is not
the cause: it still doubles with loops disabled while timings stay flat.
Every loop on the affected path already calls .stop() in its effect cleanup.
Steps to reproduce
We do not yet have a minimal reproduction — the evidence above comes from a
large application. The pattern that triggers it here is a screen that mounts
several components each running an infinite Animated.loop, where that screen
is mounted and unmounted repeatedly, with the 新建 Architecture enabled on
Android.
Happy to build a minimal repro if that would help; filing now in case the
profile signature is already recognisable to someone.
React Native Version
0.77.3
Affected Platforms
Runtime - Android
Areas
Fabric - The 新建 Renderer
Environment
- Android 7.1.2, armeabi-v7a, low-end ARM SoC (2 GB RAM)
- Hermes enabled, 新建 Architecture enabled
- Release build (minified,
--dev=false)
Description
On RN 0.77.3 with the 新建 Architecture, looping animations appear not to be
released when their component unmounts, even though every call site stops the
loop in its cleanup. The number of live loops grows for the life of the
process, so each frame drives more of them and the app gets progressively
slower.
This is a long-running Android app that stays open for days without the process
restarting. A repeated user flow — mounting a screen, doing some work, then
returning to the previous screen — takes ~16s on a freshly started process and
~28s by the 40th repetition, measured with an automated UI soak. Only a process
restart clears it.
Evidence
Bisected to the 0.75.3 -> 0.77.3 upgrade. Building an older source tree
with only the RN upgrade applied — no other application changes — reproduces
it; the same tree on 0.75.3 is flat.
CPU profiles (Hermes sampling profiler over the inspector, two equal 60s
windows, one early in the session and one after ~30 iterations):
Roughly a 4x increase in absolute Animated work over equal windows. The hot
frames are the ones that run when an animation starts
(
__getNativeAnimationConfigsamples the easing curve into a lookup table atstart time), so animations are being started ever more often rather than
running longer.
Isolated to
Animated.loop. NeutralisingAnimated.loopalone — leavingevery
timing,springandsequenceuntouched — removes the entireregression:
Animated.loopdisabledWhat we ruled out by measurement
useNativeDriver— switching every call site tofalsechanged nothing(+0.335 vs +0.338), so this is not the native animation module specifically.
ViewsandAppContexts(dumpsys meminfo)are flat across the run; threads and file descriptors fall slightly.
replace/popToTop), our list renderer, NativeWind's babel transform, andthird-party SDK versions.
the cause: it still doubles with loops disabled while timings stay flat.
Every loop on the affected path already calls
.stop()in its effect cleanup.Steps to reproduce
We do not yet have a minimal reproduction — the evidence above comes from a
large application. The pattern that triggers it here is a screen that mounts
several components each running an infinite
Animated.loop, where that screenis mounted and unmounted repeatedly, with the 新建 Architecture enabled on
Android.
Happy to build a minimal repro if that would help; filing now in case the
profile signature is already recognisable to someone.
React Native Version
0.77.3
Affected Platforms
Runtime - Android
Areas
Fabric - The 新建 Renderer
Environment
--dev=false)