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

Offen
  • Stimmt etwas nicht?
#59,248 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 2 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
android, c, cpp, java, kotlin, react-native
Bereich
mobile, performance

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
C++
Sterne
127k
Forks
25.4k
Ø Merge
3 T. 1 Std.
Gemergte PRs (30 T.)
108

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus react/react-native

Alle Issues in react/react-native

Ähnliche Issues

Weitere Issues zu C++

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.