[Android] Idle apps keep the Choreographer running at ~60 doFrames/s (zero work, zero frames rendered) — four frame callbacks re-arm unconditionally

Summary

Every React Native Android app keeps the main-thread Choreographer armed at ~60 doFrames/second while completely idle in the foreground — no timers pending, no animations running, no mount items, zero frames rendered — on every Android version we tested (API 28 → 36). It is pure CPU/battery waste present in stock template apps with zero app code or third-party dependencies involved.

Measured on a stock react-native@0.86.3 template app (npx @react-native-community/cli init --version 0.86.3), Release build, app foregrounded and settled, no interaction:

Device	API	doFrames / 10s idle	median / p90 / max doFrame	App process CPU	Frames rendered (gfxinfo)
OnePlus 3T (SD820)	28	597–598	1.95 / 2.81 / 15.86 ms	~22.5%	0
OnePlus 5T (SD835)	29	599–601	0.99–1.82 / 2.11 / 14.67 ms	~9.3%	0
OPPO Find X8 (Dimensity 9400)	36	587–601	0.67–0.86 / 0.94–1.21 / 2.83 ms	~3.5–6.8%	0

The loop stops when the app is backgrounded (host pause) and restarts on resume. iOS is unaffected (Choreographer is Android-only).

Root cause

Four Android frame callbacks re-post themselves unconditionally at the end of their own doFrame, and are initially armed at host resume, with no pending-work check:

#	Class	Re-arm site (0.86.3)
1	JavaTimerManager$TimerFrameCallback	JavaTimerManager.kt:317 — posts itself after every frame even with an empty timer queue
2	FabricEventDispatcher$ScheduleDispatchFrameCallback	FabricEventDispatcher.kt:153 — doFrame re-posts unless stopped; events are actually dispatched synchronously in dispatchEvent, this callback only notifies BatchEventDispatchedListeners
3	NativeAnimatedModule$animatedFrameCallback$1	NativeAnimatedModule.kt:353 — enqueueFrameCallback() outside the hasActiveAnimations() guard (the guard protects the work, not the re-arm)
4	FabricUIManager$DispatchUIFrameCallback	FabricUIManager.java:1666 — finally { schedule(); } re-schedules even when all queues drained

Runtime attribution: replacing ReactChoreographer with a logging build (log POST/RUN/REMOVE with callback class names) shows, in a 10s idle window on the stock template:

604 RUN  type=NATIVE_ANIMATED_MODULE cb=com.facebook.react.animated.NativeAnimatedModule$animatedFrameCallback$1
604 RUN  type=DISPATCH_UI            cb=com.facebook.react.fabric.FabricUIManager$DispatchUIFrameCallback
603 POST type=NATIVE_ANIMATED_MODULE cb=com.facebook.react.animated.NativeAnimatedModule$animatedFrameCallback$1
603 POST type=DISPATCH_UI            cb=com.facebook.react.fabric.FabricUIManager$DispatchUIFrameCallback

with the timers/dispatcher callbacks cycling the same way on stock builds (source-verified).

Reproduction

npx @react-native-community/cli@latest init repro --version 0.86.3 --skip-git-init
cd repro/android && ./gradlew assembleRelease
adb install -r app/build/outputs/apk/release/app-release.apk
adb shell am start -W -n com.repro/com.repro.MainActivity
# settle ≥40s, then:
adb shell atrace -t 10 -b 32768 view input -z -o /data/local/tmp/idle.atrace.gz
adb pull /data/local/tmp/idle.atrace.gz .
# → ≈600 "Choreographer#doFrame" sections for the app pid, each containing only
#   an empty "animation" stage; Android 16 also exposes DoFrameCB-IsEmptyDoFrame=1
adb shell dumpsys gfxinfo com.repro reset && sleep 10 \
  && adb shell dumpsys gfxinfo com.repro | grep "Total frames rendered"   # → 0

Control: a raw Java Activity with setContentView(new View(this)) and zero dependencies receives 0 doFrames at idle — the OS floor is clean; this is entirely framework-driven.

Validation of the fix direction

Patched-framework experiments on the stock template (Find X8):

• Demand-gating #1 and #2 (re-arm only when work exists): app fully functional, but the loop persists (pumps #3/#4 still active) — proving each pump independently keeps the Choreographer armed.
• Gating #3 and #4 as well: 0 doFrames at idle, ~0% CPU, app alive and foreground — the loop fully collapses (notably, exactly one dropped re-post per pump is enough to kill each permanently: each callback was keeping only itself alive).

Proposed fix

Make each pump re-arm only when it has work, re-arming lazily from its registration path (PR to follow):

1. TimerFrameCallback.doFrame: re-post only if (timers.isNotEmpty()); re-arm from createTimer.
2. ScheduleDispatchFrameCallback.doFrame: never re-post (one-shot per schedule request).
3. animatedFrameCallback.doFrameGuarded: enqueueFrameCallback() inside the hasActiveAnimations() branch; re-arm in didDispatchMountItems after operation batches execute (startAnimatingNode et al.).
4. DispatchUIFrameCallback.doFrameGuarded: re-schedule only while mount items remain pending.

The newer subsystems (AnimationBackend, EventBeat) already follow this demand-gated pattern — these four are the legacy stragglers.

Impact

Every RN Android app, on every Android version, burns main-thread CPU at vsync rate whenever its screen is merely visible — reading, idling, screen-on standby. Worst on low-end hardware (22.5% of one core measured on a 2016 SoC) where it also competes with real frame work (15.9ms worst-case idle doFrames measured). After the fix, idle RN apps are frame-silent like native apps, with no behavior change whenever work exists.

Commencez par les quatre points de réactivation nommés dans JavaTimerManager.kt, FabricEventDispatcher.kt, NativeAnimatedModule.kt et FabricUIManager.java, puis exécutez les commandes Android fournies pour la reproduction et le traçage en veille. Vérifiez que les applications inactives produisent zéro Choreographer doFrames, tandis que les timers, les événements, les animations et le travail de mount continuent de fonctionner lorsqu’ils sont présents.