Skip to content

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

Open

Description

@YevheniiKotyrlo

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 928fd14, 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 928fd14: the scenes in RNTester's View examples, and drainPreallocateViewsQueue blocks the Android UI thread on the JS thread's executeMount since #58890 #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.

React Native Version

nightly (main at 928fd14)

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 928fd14.

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions