You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit cc514f2
Browse filesBrowse the repository at this point in the historyBrowse files
Pull each surface's pending transaction at the start of the mount phase in the Android pull model
With enableMountingCoordinatorPullModelAndroid, every commit notification
queued a PullTransactionMountItem in MountItemDispatcher's mount item queue.
Its queue position has no semantic meaning:
- MountingCoordinator::pullTransaction mounts the latest revision, so the
first pending item of a surface mounts every commit made before it runs,
and the surface's later items pull nothing.
- The position only orders the pull after items queued before the
notification. That is enqueue timing, not intent: under push the batch is
queued at the end of the JS task, so an accessibility event sent in the same
task for a view the commit creates is queued before the batch and can miss
its target.
- While the root view is detached the item went to the attach queue, where it
pulled revisions whose preallocations were queued behind it. #58152
re-queued that batch on the dispatcher, behind a later pull of the same
surface, which then mounted the newer revision first.
Now MountItemDispatcher keeps a concurrent set of surface ids with an
available transaction. onTransactionAvailable adds the surface (and, on the
UI thread, dispatches as before). A dispatch runs view commands, pre-mount
items, then pulls every pending surface whose root view is attached through
ItemDispatchListener.pullTransaction (FabricUIManagerBinding
.pullAndExecuteTransaction directly), then the queued mount items. Pulls run
inside the "mount" trace and BatchedExecutionTime, with the same ignorable
exception handling as mount items (shared logOrRethrowMountingException), and
their surfaces are reported to reportMount like before. hasPendingItems
counts pending surfaces whose root view is attached, so with
disableIdleMountItemFrameCallbackRearmAndroid a pending pull keeps the frame
callback armed; a surface waiting for its root view does not.
A surface waiting for its root view stays pending. The attach already calls
the MountItemExecutor to run its attach queue; that callback now also
schedules the frame callback, and the next frame pulls the surface after the
preallocations ran. A pulled batch therefore never runs with a detached root.
The #58152 re-queue in scheduleMountItem is removed, and with it that
reorder.
A stopped surface's pending id is pulled once (C++ finds no surface) and
dropped; a restarted surface is added again by its next commit.
The one ordering change: an item queued before a commit's notification, for
a surface with no pull pending, in the same frame, now runs after that commit
mounts. It serves events for views the commit creates; an item for a view the
same commit deletes now misses a view that disappears in this frame anyway.
With disableEarlyViewCommandExecution (default false), view commands are such
items: a command dispatched before a commit runs after it mounts. Commands
dispatched after a commit still run after it, as the flag intends.
PullTransactionMountItem is deleted. Empty pulls still run the mount hooks,
but one pull per pending surface per dispatch makes them rare.
Tests (FabricUIManagerPullModelTest):
- pullDeferredByRootAttach_isAppliedBeforeLaterPulls passes.
- onTransactionAvailable_enqueuesOnePullPerNotification becomes
onTransactionAvailable_pullsEachPendingSurfaceOnce: repeated notifications
of a pending surface add no pull ([1, 2, 3] in any order instead of
[1, 2, 1, 3]; the dropped pull was empty).
- synchronousBatch_waitingForRootAttach_isDeferred is removed: it scheduled a
synchronous batch while the root was detached, which can no longer happen.
pullWaitingForRootAttach_isMountedByTheFrameAfterTheAttach covers the
#58152 property through onTransactionAvailable.
- New: mountItemQueuedBeforeCommit_runsAfterThePull and
viewCommandsInMountItemOrder_runAfterThePull document the order (fail on
main), and pendingPullOfStoppedSurface_runsOnceAndIsDropped.
- New, with disableIdleMountItemFrameCallbackRearmAndroid:
pendingPull_keepsTheIdleFrameCallbackArmed (a commit notified from the
commit thread during a frame's pull keeps the callback armed; fails without
the hasPendingItems change) and
commitFromUiThreadDuringPull_isMountedByTheNextFrame (the nested dispatch
returns early; the next frame mounts the commit).
Copy file name to clipboardExpand all lines: packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountItemDispatcher.kt
Copy file name to clipboardExpand all lines: packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/mountitems/PullTransactionMountItem.kt
Copy file name to clipboardExpand all lines: packages/react-native/ReactAndroid/src/main/java/com/facebook/react/internal/featureflags/ReactNativeFeatureFlags.kt
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@
4
4
* This source code is licensed under the MIT license found in the
5
5
* LICENSE file in the root directory of this source tree.
* When enabled, Android mounts transactions with the pull model (like iOS): the commit thread no longer pulls and builds the mount batch in schedulerShouldRenderTransactions. Instead the UI thread pulls the transaction itself via a PullTransactionMountItem enqueued in the MountItemDispatcher, builds the IntBufferBatchMountItem, and applies it synchronously. Requires `enableAccumulatedUpdatesInRawPropsAndroid` to be enabled as well, since a single pull may collapse several commits into one diff and therefore needs complete accumulated rawProps; when used together with Props 2.0, also enable `enableExclusivePropsUpdateAndroid` and `enablePropsUpdateReconciliationAndroid`.
292
+
* When enabled, Android mounts transactions with the pull model (like iOS): the commit thread no longer pulls and builds the mount batch in schedulerShouldRenderTransactions. Instead the UI thread pulls the transaction itself at its next mount dispatch, builds the IntBufferBatchMountItem, and applies it synchronously. Requires `enableAccumulatedUpdatesInRawPropsAndroid` to be enabled as well, since a single pull may collapse several commits into one diff and therefore needs complete accumulated rawProps; when used together with Props 2.0, also enable `enableExclusivePropsUpdateAndroid` and `enablePropsUpdateReconciliationAndroid`.
0 commit comments