Android view preallocation drains only when a frame callback starts, so every new view is created inside a frame

Start with FabricMountingManager.cpp queueing and batch creation, FabricUIManager.java's frame callback drain, and MountItemDispatcher.kt's pre-mount budget. Trace how queue draining can run between frames when work is queued, then check how destroyed families are handled. Compare the 48-row reproducer's frame creation counts and timings; done means views are drained between frames and frame-time creation falls in the reported scenario.

Description

FabricMountingManager::maybePreallocateShadowNode queues each view JavaScript creates (FabricMountingManager.cpp), and the queue is drained only when FabricUIManager's frame callback starts (FabricUIManager.java). So every new view is created inside a Choreographer#doFrame:

• When a commit's executeMount runs before that frame, none of its views is registered yet, and its batch creates each one with a CREATE in the frame that mounts it (FabricMountingManager.cpp).
• The views the drain does register are created by the same frame's pre-mount budget, which runs until half of a 60 Hz frame after the vsync (MountItemDispatcher.kt), or all at once before the next batch (MountItemDispatcher.kt).

The UI thread is often idle between frames while JavaScript renders, and none of this work can use that time.

Release RNTester from main at 928fd149cb, with the reproducer's two View examples: a band of 12 or 48 rows, each a View, a circle and a Text, replaced every 250 ms beside a native-driven rotation. Three 24 s traces of each on a Galaxy S23, Android 14, 120 Hz:

	12 rows every 250 ms	48 rows every 250 ms
views created inside a frame	all 3348–3384	all 13392–13536
by the frame's pre-mount budget	2411–2548	10112–10373
by a batch, from the pre-mount queue	747–852	1219–1507
by a CREATE in the batch	16–125	1713–2061
frames past 8.33 ms, of 2741–2780	93–94	123–125

In the longest 48-row frame, 29.89 ms, the batch created 72 views in a 12.37 ms CREATE section and the pre-mount budget created 25 more.

In a 0.86.3 app with #59057, I also drained the queue in #59057's between-frames slices from the moment its first view was queued, and dropped a destroyed family's view from the queue. On a Galaxy S23, a list whose rows are keyed by item then created 0–3 of its views per run inside a frame, against 1515–1829 before, and no frame passed 8.33 ms where one did in every run (six runs each). Would a drain that starts when the queue goes non-empty and runs between frames fit the direction you want for preallocation?

Steps to reproduce

1. Apply the reproducer's two patches to main at 928fd149cb: the scenes in RNTester's View examples, and #59244's trace section around the drain call.
2. Build RNTester release for arm64-v8a and open View → "Pre-allocation band: 48 rows every 250 ms".
3. Record a Perfetto trace of 24 s with the app's view and gfx atrace categories.
4. Every SurfaceMountingManager::createViewUnsafe slice on the main thread lies inside a Choreographer#doFrame slice, under MountItemDispatcher::premountViews, MountItemDispatcher::mountViews preMountItems or an IntBufferBatchMountItem::mountInstructions::CREATE section, and every FabricUIManager::drainPreallocateViewsQueue slice lies inside a Choreographer#doFrame too.

Expected: views queued for pre-allocation are created between frames, so a new row's views are not created inside the frame that mounts it.
Actual: every view is created inside a frame (step 4), and the longest 48-row frame took 29.89 ms.

React Native Version

nightly (main at 928fd149cb)

Affected Platforms

Runtime - Android

Areas

Fabric - The New Renderer

Output of npx @react-native-community/cli info

System:
  OS: Windows 11 10.0.26200
  CPU: "(32) x64 AMD Ryzen 9 9950X3D 16-Core Processor          "
  Memory: 142.62 GB / 255.67 GB
Binaries:
  Node:
    version: 26.8.1
    path: C:\Program Files\nodejs\node.EXE
  Yarn:
    version: 1.22.22
    path: ~\AppData\Roaming\npm\yarn.CMD
  npm:
    version: 12.0.1
    path: C:\Program Files\nodejs\npm.CMD
  Watchman: Not Found
SDKs:
  Android SDK:
    API Levels:
      - "33"
      - "35"
      - "35"
      - "35"
      - "36"
      - "37"
    Build Tools:
      - 35.0.0
      - 36.0.0
      - 36.1.0
      - 37.0.0
    System Images:
      - android-26 | Google APIs Intel x86_64 Atom
      - android-28 | Google APIs Intel x86_64 Atom
      - android-29 | Google APIs Intel x86_64 Atom
      - android-30 | Google APIs Intel x86_64 Atom
      - android-31 | Google APIs Intel x86_64 Atom
      - android-32 | Google APIs Intel x86_64 Atom
      - android-33 | Google APIs Intel x86_64 Atom
      - android-34 | Google APIs Intel x86_64 Atom
      - android-35 | Google APIs Intel x86_64 Atom
      - android-36.1 | Google Play Intel x86_64 Atom
      - android-36.1 | Pre-Release 16 KB Page Size Google Play Intel x86_64 Atom
      - android-37.0 | Google APIs Intel x86_64 Atom
    Android NDK: Not Found
  Windows SDK: Not Found
IDEs:
  Android Studio: AI-252.27397.103.2522.14617522
  Visual Studio: Not Found
Languages:
  Java:
    version: 17.0.20.1
    path: /c/Program Files/Microsoft/jdk-17.0.20.101-hotspot/bin/javac
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 19.3.0
    wanted: 19.3.0
  react-native: Not Found
  react-native-windows: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

Run in the React Native checkout I built RNTester from, main at 928fd149cb.

Stacktrace or Logs

No crash. Galaxy S23, Android 14, 120 Hz; release RNTester from main at 928fd149cb,
View → "Pre-allocation band: 48 rows every 250 ms", the longest frame of one trace:

main      Choreographer#doFrame                                   29.89 ms
            MountItemDispatcher::premountViews                     2.75 ms, 25 views created
            IntBufferBatchMountItem::mountViews                   19.92 ms
              mountInstructions::CREATE numInstructions=72        12.37 ms, 72 views created
mqt_v_js  FabricMountingManager::executeMount, before that frame   0.60 ms

MANDATORY Reproducer

https://github.com/YevheniiKotyrlo/react-native-evidence/tree/main/preallocation-band

Screenshots and Videos

The scenes, the build, how they were traced and every reading are on this page.