[tomekzaw]

Summary:

A view that isn't preallocated gets a Create and an Insert in the same mount transaction, for example a layout-only View that gains a backgroundColor and stops being flattened. The Create item already passes the view's state and event emitter to Java: SurfaceMountingManager.createViewUnsafe stores both in the ViewState, and ViewManager.createView applies the state. The Insert then always adds UpdateState and UpdateEventEmitter items for the same objects. So C++ builds a second StateWrapperImpl and EventEmitterWrapper, and Java calls ViewManager.updateState again and destroys the first wrappers.

executeMount now remembers the state and event emitter of each view created in the transaction. Insert skips its UpdateState and UpdateEventEmitter items when they would pass the same objects. Preallocated views, which get no Create item, and views whose state changed between Create and Insert still get them.

Changelog:

[ANDROID] [CHANGED] - Stop sending the state and event emitter twice for views created and inserted in the same mount transaction

Test Plan:

A Playground screen with 300 layout-only views that gain a backgroundColor every 500 ms, so each such transaction creates and inserts 300 views. Time per transaction:

	Galaxy A16	Pixel 9a	OPPO CPH2269	moto g57 power
executeMount (C++)	2.01 ms → 1.67 ms (−17%)	2.20 ms → 1.97 ms (−11%)	7.44 ms → 6.16 ms (−17%)	1.80 ms → 1.57 ms (−13%)
Executing the mount items (Java)	33.32 ms → 33.18 ms (no change)	12.96 ms → 13.25 ms (no change)	51.92 ms → 51.02 ms (no change)	38.79 ms → 37.66 ms (no change)

These views have no state, so the C++ side builds 300 fewer EventEmitterWrappers per transaction. The Java side is dominated by creating the 300 Android views, so the skipped updateEventEmitter calls don't show there. On the Pixel 9a the C++ interval is wide, −23% to −4%.

Setup:

• Release RNTester (./gradlew :packages:rn-tester:android:app:assembleRelease -PreactNativeArchitectures=arm64-v8a, R8 on) with default feature flags, compiled with cmd package compile -m speed.
• Temporary timing probes, not part of this PR, and a Playground scenario opened by deep link.
• Each run is a fresh process: a 12 s window after the scenario starts, reported as the median of its samples. Per phone, one discarded run of each build, then 8 A/B/B/A cycles of main and this PR (16 processes per build).
• Each figure is the median of the 16 processes. A change is shown when its 95% bootstrap confidence interval excludes zero, and "no change" otherwise.
• The Galaxy A16, Pixel 9a and moto g57 power run Android 16. The OPPO CPH2269 runs Android 11.

Also checked on the Galaxy A16: a box that gains a background and an onTouchEnd handler (so it gets a Create item) renders and counts taps.

🤖 Generated with Claude Code