Repository navigation
Android view preallocation drains only when a frame callback starts, so every new view is created inside a frame #59248
Description
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
executeMountruns before that frame, none of its views is registered yet, and its batch creates each one with aCREATEin 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
- Apply the reproducer's two patches to
mainat 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. - Build RNTester release for
arm64-v8aand open View → "Pre-allocation band: 48 rows every 250 ms". - Record a Perfetto trace of 24 s with the app's
viewandgfxatrace categories. - Every
SurfaceMountingManager::createViewUnsafeslice on the main thread lies inside aChoreographer#doFrameslice, underMountItemDispatcher::premountViews,MountItemDispatcher::mountViews preMountItemsor anIntBufferBatchMountItem::mountInstructions::CREATEsection, and everyFabricUIManager::drainPreallocateViewsQueueslice lies inside aChoreographer#doFrametoo.
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