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

Abierto
  • ¿Algo no está bien?
#59,248 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
android, c, cpp, java, kotlin, react-native
Área
mobile, performance

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C++
Estrellas
127k
Forks
25.4k
Merge medio
2 d 9 h
PR fusionados (30 d)
91

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de react/react-native

Todos los issues de react/react-native

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.