Animated.loop instances accumulate under the New Architecture on 0.77.3, degrading performance over a long-running session

Description

On RN 0.77.3 with the New 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 New 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 New Renderer

Environment

• Android 7.1.2, armeabi-v7a, low-end ARM SoC (2 GB RAM)
• Hermes enabled, New Architecture enabled
• Release build (minified, --dev=false)

Beginne beim Einstiegspunkt Animated.loop und vergleiche sein Verhalten zwischen React Native 0.75.3 und 0.77.3 mit aktivierter New Architecture auf Android. Reproduziere das wiederholte Mounten und Unmounten des Bildschirms mit mehreren Endlosschleifen. Überprüfe anschließend, dass angehaltene Schleifen sich nicht weiter ansammeln und dass der langfristige Soak-Test stabil bleibt.