Summary:
This is a re-land of D28810022 (https://github.com/facebook/react-native/commit/7e9c741146e1b3aa542ecfe138765e95ddddac3f), which was reverted due to T92179998. The fix is in D28938530. This issue could also be resolved by preventing more view preallocations (D28811419 (https://github.com/facebook/react-native/commit/8ca18f0b602a08cd9a5c9f6681bb5dc74e0d34f7)).
---
EventEmitter is not transmitted from C++ to Java until an UPDATE operation is enqueued.
Practically this usually happens "right away", but in the case of an Image component, especially, the EventEmitter could be missing while events are being fired from the native side (for example, loading events).
The fix is just to pass EventEmitter in sooner, in both Create and Preallocate. There should be no ill effect since EventEmitter is nullable anyway.
One potential side-effect: since Views can be PreAllocated and potentially never deallocated until StopSurface is called, this could result in more EventEmitter objects being leaked and retained from Java. I believe the fix is to remove PreAllocated Views more aggressively.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28938637
fbshipit-source-id: c9e290a24ed15c28881e3eead4a5f580f66b288f
Summary:
setJSResponder/clearJSResponder have been in use in prod for a while and are stable. Ship them in code.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28889894
fbshipit-source-id: 1c42526cd890d528062eeb50761fc49cc6109d76
Summary:
EventEmitter is not transmitted from C++ to Java until an UPDATE operation is enqueued. Practically this usually happens "right away", but in the case of an Image component, especially, the EventEmitter could be missing while events are being fired from the native side (for example, loading events).
The fix is just to pass EventEmitter in sooner, in both Create and Preallocate. There should be no ill effect since EventEmitter is nullable anyway.
One potential side-effect: since Views can be PreAllocated and potentially never deallocated until StopSurface is called, this could result in more EventEmitter objects being leaked and retained from Java. I believe the fix is to remove PreAllocated Views more aggressively.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28810022
fbshipit-source-id: ae4c8b4eefe619d9a99fa5f90f612d6dd4880da5
Summary:
TL;DR: simplify and delete a bunch of stuff that shouldn't be necessary in Fabric.
I discovered that this event dispatcher (and the older one this is based on) is triple-queueing: we queue events into "staging", and then post "dispatch events" to only run /on the JS thread/. Even in Fabric. Then, each of these events is emitted into C++ where they are queued /again/! This refactor eliminates one more level of queueing - instead of scheduling dispatch for the JS thread, we just emit them directly to C++ when they're received in Java.
Unfortunately, the EventDispatcher is also used to drive AsyncEventBeat in C++:
1. EventBeatManager.onBatchEventDispatched: https://fburl.com/diffusion/qf6dyhsw
In the C++ impl, it indirectly will drive the AsyncEventBeat/AsyncEventBeatV2.
2. onBatchEventDispatched is ONLY called from EventDispatcherImpl: https://fburl.com/codesearch/mxk8ifyj
3. Which is queued and only runs on the JS thread: https://fburl.com/codesearch/czvbst4u
This means the AsyncEventBeat is only ticked when the JS thread is free, and ticks will be skipped when the JS thread is occupied for long periods.
Now, in this refactor, when this class is used it will drive AsyncEventBeat on every UI tick. This is also potentially not correct. On iOS (Fabric), AsyncEventBeat is driven when the UI thread is "about to sleep".
For now I'm not going to worry about that detail - it is significant, but Fabric+Android is currently /not doing the right thing/ and it's not clear that we want to maintain iOS behavior. This is something we need to discuss further and figure out.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28654033
fbshipit-source-id: b3cb9b706343c8dd3c4cf84f24388908c57e2138
Summary:
EventDispatcherImpl uses synchronized blocks all over to make it thread-safe. I'm concerned about the perf implications of this and creating contention between JS and UI threads.
This is locked behind a feature flag.
Enabled only for Fabric in StaticViewConfig mode, and a feature flag, for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28591331
fbshipit-source-id: ea8f93a2e1343ce37fa78690dcb62fe03594120f
Summary:
Changelog: [Internal]
Links APIs in Fabric and Venice to create a surface without a view and mount it separately when surface is started the usual way.
Reviewed By: mdvacca
Differential Revision: D27339365
fbshipit-source-id: d1b674ce856957465eb6f3a5d7f26eb0ab625353
Summary:
Instead of annotating individual methods with DoNotStrip, we actually want to ensure that nothing in this class gets stripped out.
This also upgrades the yoga/proguard-annotations package for Gradle builds.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27335181
fbshipit-source-id: 5b696c26faf4d1b32a3fd885e42a996aff23f0be
Summary:
Changelog: [Internal]
FabricUIManager contains a lot of logic related to mounting items and manipulating dispatch queues, which can be safely extracted outside. Apart from decreased logical complexity, this change enables easier modification of the queuing behavior later in this stack.
Majority of the changes is caused by moving existing logic to a different class, no change in behavior expected.
Reviewed By: JoshuaGross
Differential Revision: D27271116
fbshipit-source-id: 86fe45b19bb839f96fde8ba607f72006f6401cc7
Summary:
This diff contains the code from the 35 diff stack - D27210587
This diff implement and integrates Mapbuffer into Fabric text measure system
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27241836
fbshipit-source-id: f40a780df0723f27da440f709a8676cfcca63953
Summary:
Create MC to gate execution of JS Responder in Fabric Android
MC.react_fabric.enable_js_responder_fabric_android is enabled by default in the server
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26905296
fbshipit-source-id: 82504174394d1e10fd017435cccd38952404fda0
Summary:
Changelog: [Internal]
Updates `ReactSurface` to use `SurfaceHandler` internally.
This removes most of the internal state in `ReactSurface` and propagates all the calls to the `SurfaceHandler`.
`FabricUIManager` now uses `SurfaceHandler` to start/stop the surface.
SurfaceId is still used for view operations. SurfaceId is also now mutable to play better with existing Android infra.
Reviewed By: shergin, mdvacca
Differential Revision: D26112992
fbshipit-source-id: 52e6860084d739381317035dc3011956d452063c
Summary:
Simplify addLifecycleEventListener for the flaky test because we just want to test that listener is working.
Changelog:
[Android][Changed] - Add a spare implementation of addLifecycleEventListener for test purpose.
Reviewed By: PeteTheHeat
Differential Revision: D26749256
fbshipit-source-id: 5af216e6bfa37a15eb189aa24a3df35a7a7112de
Summary:
This diff moves the method getViewportOffset out of ReactRootView. This is necessary to avoid Fabric to depend from paper.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26716901
fbshipit-source-id: cec67c24860a776fb361d7cda08d3142e1214c8c
Summary:
In Fabric we're seeing setJSResponderHandler called during teardown of a surface, which causes a crash because the SurfaceId is no longer available at that point.
Guard against setJSResponderHandler being called on a dead surface.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26734786
fbshipit-source-id: 838d682ee0dd1d4de49993fa479dc2097cf33521
Summary:
Change lifecycle of stopSurface in a subtle way: mark the surface as stopped in Java first, then in Cxx (currently it happens in Cxx, then Java).
This will cause us / allow us to ignore the final mounting instructions for the Surface, which are all irrelevant since they just have to do with View removal.
We can rely on GC and `unmountReactApplication` to do all of this for us, and save some CPU cycles on stopSurface.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D26469741
fbshipit-source-id: a7f81d44c3cb2138f0ab31feb38852910410c638
Summary:
This diff refactor the initialization and deallocation of EventDispatcher in FabricUIManager when StaticViewConfigs are enabled.
The goal of this diff is to make sure that the EventDispatcher is deallocated correctly when using StaticViewConfigs
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D26166413
fbshipit-source-id: e5bdad7ba923edc677c6b73f3a4d1271941f41cc
Summary:
There is a race between PreAllocateMountItems executing and killing off stale SurfaceMountingManagers.
For now I'm simplifying the "eviction" mechanism. We just keep up to 15 SurfaceMountingManagers around and start evicting them from the least-recently-referenced one.
Hopefully this logic can be simplified in the future.
I'm also sneaking in a small perf optimization for PreAllocateMountItem: don't queue them if the associated surface is already stopped, because chewing through a bunch of dead PreAllocateMountItems on the UI thread can be expensive.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26059378
fbshipit-source-id: 3b2503d7d8e5f045ae741d0d4a5880d1b37758d2
Summary:
In some cases, onMeasure/onLayout are called on the RootView before `startSurface` in Fabric has been able to set surfaceId on the RootView.
With the new SurfaceMountingManager, this causes a crash because we need a valid surfaceId to perform an operation. Before the SurfaceMountingManager refactor, a surfaceId of 0 would be passed to `mBinding.setConstraints` in the FabricUIManager, and setConstraints in C++ noops if there's an invalid surfaceId.
For now, FabricUIManager will also fail silently if the surfaceId is invalid when updateRootLayoutSpecs is called, just to be conservative and to be consistent with previous behavior. This will be upgraded to a hard-crash in the future.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26051266
fbshipit-source-id: ca2d80f899cdba9b3962af68546bd83b77be0680
Summary:
Create V2 EventEmitter that surfaceId can be passed into, with a backwards-compat layer, and some debug-only logging to help assist with migration.
Changelog: [Changed][Android] RCTEventEmitter has been deprecated in favor of RCTModernEventEmitter for optimal Fabric support; RCTEventEmitter will continue to work in Fabric, but there are minor perf implications.
Reviewed By: mdvacca
Differential Revision: D26027104
fbshipit-source-id: 784ca092bbc88d19c82f6c42537c34460d96de86
Summary:
There's a field called `surfaceID` in a couple of classes that isn't the same as the integer `surfaceId` in Fabric.
For consistency, I've deprecated a couple of them, or renamed when appropriate.
In addition, now we're passing the actual integer surfaceId into the ThemedReactContext. This means that every single View created in Fabric gets annotated with the surfaceId it's in. Currently this isn't used, but the idea is that now each View has a mapping back to its surface, which could be used to simplify / optimize operations with SurfaceMountingManager. In particular, we might be able to use this in the future to optimize animations and/or event emitters.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26021571
fbshipit-source-id: b7db7de123db07fa928a6f815be86bdbb030e62c
Summary:
This refactors MountingManager into a minimal API that shims into a more fully-featured SurfaceMountingManager. The SurfaceMountingManager keeps track of surface start/stop, surface ID, and surface Context.
This solves a number of issues around (1) race conditions around StopSurface/StartSurface, (2) memory management of Views, (3)
Concrete improvements:
1. Simpler to reason about race conditions around StopSurface/StartSurface.
2. 1:1 relationship between SurfaceId and all Views/tags.
3. When surface is stopped, all descendent Views can be GC'd immediately.
4. Fixed separation of concerns and leaky abstractions: surfaceId/rootTag and Surface Context are now stored and manipulated *only* in SurfaceMountingManager.
5. Simpler StopSurface flow: we simply remove references to all Views, and the Fragment (outside of the scope of this code) removes the RootView. This will trigger GC and we do ~0 work. Previously, we ran a REMOVE and DELETE instruction and kept track of each View in a HashMap. Now we can simply delete the map and move on.
The caveat: NativeAnimated (or other native modules that go through UIManager). APIs like `updateProps` currently uses only the ReactTag and does not store SurfaceId. This is a good argument for moving away from ReactTag, at least in its current incarnation, but: for now this requires that you do a lookup of a ReactTag across N surfaces (worst-case) to determine which Surface a ReactTag is in.
So, to summarize, the "con" of this approach is that now `getSurfaceManagerForViewEnforced` could be slower. It is used in:
* NativeAnimatedModule calls `updateProps` through UIManager
* FabricEventEmitter calls `receiveEvent` on FabricUIManager directly
* On audit, I could find zero native callsites to `sendAccessibilityEvent` through UIManager
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26000781
fbshipit-source-id: 386ae40c4333f8c584e05818c404868dbee6ce73
Summary:
This is the Android native implementation of sendAccessibilityEvent for Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25852418
fbshipit-source-id: cb51e667a7f673da6b9c9e539770225b02bdc902
Summary:
This experiment has been successfully running for several weeks and show small but statsig perf improvements. Delete the old code and ship this 100% in code to simplify Fabric code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25775668
fbshipit-source-id: d2b41dfe691775e52b1e89c2fb6790a6500e560e
Summary:
This diff fixes a race condition in the execution of FabricUIManager.StartSurface method.
The rootcause is that startSurface is executing getViewportOffset from a background thread.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D25617154
fbshipit-source-id: 9351201088164e74bb0b9454e30651e1de0da912
Summary:
There is an optimization in FabricUIManager.surfaceActiveForExecution that ensures it returns the same value (true or false)
for a given SurfaceId for a single frame (the value is cached until the next frame).
It seems like this can be causing a few different crashes, in a couple different ways:
1) If StopSurface is called off the UI thread, in the middle of a batch of operations (probably less likely to cause problems)
2) If StopSurface is called on the UI thread, in between different operations; the latter operations will still execute because the `true` value of `surfaceActiveForExecution` was cached.
I don't think that this optimization was providing much for us, and could be causing crashes. Remove it for now and we'll analyze impact on crashes and perf.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25379970
fbshipit-source-id: 2c15c971bd0c828e1d38a34662d93293271041b2
Summary:
This was added to prevent mutating the UI during draw or measure, and appears to have been effective. Keep the comments, ship the feature, remove flags.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25258409
fbshipit-source-id: 36ad8a03d1eb82bc9dcd769372c03f1ebe8b8da8
Summary:
Currently, queuing any sort of MountItem or getting the list of MountItems requires synchronization. Since these can be queued up at any point from the JS thread, there will, in theory, be constant contention between JS and UI thread.
To see if this is true, I'm creating an experiment instead of just switching over to concurrent structures. After seeing results, we can hopefully make a decision and delete the non-concurrent stuff or improve on it somehow.
The original was unlanded in D24973616 (https://github.com/facebook/react-native/commit/26787e2260412d9d2fe831e68a8616505d3cab36) due to a typo, which has been fixed now. The typo was that in Blocking Mode, we queued up all PreMountItems to the concurrent PreMountItems queue.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D24974851
fbshipit-source-id: d081c081bbd0de445bb92408f0ec822056b905a5
Summary:
Currently, queuing any sort of MountItem or getting the list of MountItems requires synchronization. Since these can be queued up at any point from the JS thread, there will, in theory, be constant contention between JS and UI thread.
To see if this is true, I'm creating an experiment instead of just switching over to concurrent structures. After seeing results, we can hopefully make a decision and delete the non-concurrent stuff or improve on it somehow.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24942110
fbshipit-source-id: fcbdeda51f91f4bd430a20d7484854fb1e94a832
Summary:
For over a month I've been searching for a crash that occurs during Android's native `dispatchDraw` method on View. The stack traces didn't show anything useful - everything in the stack trace was native Android code,
not React Native code.
This also seems to only repro on certain vendors, and only on a very few React Native screens - I'm still not sure why either of those are the case, but from my repro, a *very* specific set of interactions needs to happen
to trigger this crash. See comments inline and an example stack trace.
Luckily, the fix is trivial. Since this code is used for animations, accessibility, and a number of other important interactions, I'm gating this change for now.
In general we must be careful to only mutate the View hierarchy only when we /know/ for certain it is safe to do so. Indirectly mutating the View hierarchy during measure, onMeasure, layout, dispatchDraw, etc, can all be
very dangerous. This is one of the last "escape hatches" that can cause view hierarchy modifications unexpectedly, so I think it's a very good idea to "secure" this further, and only update props synchronously here - and
ensure that other MountItems like `Delete` are definitely /not/ executed here.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24639793
fbshipit-source-id: b6219ce882e8d2204b4d10bf99f6a1120a33cb5a
Summary:
I've had my eyes on this optimization for a while: during TTRC especially, but really during any heavy render path, Fabric will create hundreds to thousands of MountItem class instances in order to construct a BatchMountItem.
This results in: hundreds/thousands of round-trip JNI calls, hundreds/thousands of Object allocations, etc. This will also result in increased memory and GC pressure.
Theoretically, by reducing the number of JNI calls and reducing allocations, we may be able to get some small wins in memory and CPU usage during very hot paths.
I am motivated to do this, in part, to indirectly measure the cost of JNI calls as well as allocating many objects vs an int buffer. I am unaware of such a measurement that we can use to make architectural decisions for React Native Android overall.
The other reason this could be a positive change: if it's successful and we can delete the old path, we'll be able to delete a bunch of Java classes entirely which is great for APK size wins.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24631230
fbshipit-source-id: 86a46ffcaef4ecbec2e608ed226aed0b5c4b832e
Summary:
Simplifying the StopSurface flow. Before we would still attempt to execute MountItems, but only the "Delete" operations. This was... well, frankly, overcomplicated. Instead we can just ignore all future MountInstructions for that Surface and delete all views recursively from the root.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23338752
fbshipit-source-id: 6e7ab29ad85572782bfc6a39845a8a619f001559
Summary:
New mechanism to soft-crash, or crash, and collect diagnostics in the mounting layer.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22971260
fbshipit-source-id: 860cde3effa4a187f10f5dd1488dd41ace65e363
Summary:
After D22801173 (https://github.com/facebook/react-native/commit/9e6ba9ddb8608d4e3a4a80d0138600130b766d4c) has landed, the native mechanisms in NativeAnimated to delay queued items from immediate execution are no longer necessary.
Fabric and non-Fabric animations both look smooth after deleting this code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22807906
fbshipit-source-id: 9241fff84376f6aa9a35049cc40dfd6561effaa1
Summary:
This could help somewhat with solving crashes in production.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D22631593
fbshipit-source-id: 2caebf1d6611d98764bccf5a6608040e5c892614
Summary:
When stopSurface is called, Fabric might be processing a commit and performing measurements even as the context is being removed from the FabricUIManager map.
Just return a 0 from `measure` if we can't get a context. This prevents crashes during teardown for measured views that will never be visible anyway.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22604716
fbshipit-source-id: 67be8d272afd35fc4c2b51b371939c5623e97f73
Summary:
Expose `resolveCustomDirectEventName` from UIManager interface for Bridgeless Mode+NativeAnimatedModule.
We cannot remove the interface from the Non-Fabric UIManagerModule yet, as it would break downstream open-source dependencies, so I just marked it deprecated.
Note that this still doesn't totally fix issues with Bridgeless mode: generally I have to navigate to a Bridgeless surface, exit it, and then navigate back, and only on the 2nd navigation does everything seem to work properly...
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22483508
fbshipit-source-id: 685126e7e51aa5d0fd60ad5d4ecc44e8c6c3029d
Summary:
Commits can happen during navigation/teardown which creates mount items. If we throw an exception during
teardown because we expect the Context to still be around, we crash too often. Instead, I will rely on
logic in FabricUIManager to ignore queued MountItems if we try to execute them after the surface has been torn down;
and we move the IllegalStateException to actual execution of the mount item in case there's an edge-case we're missing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22470102
fbshipit-source-id: ad98c03994969a3c3f300d6551e90b6516ed2d8b
Joshua Gross
Andrei Shikov
David Vacca
Lulu Wu
Samuel Susla
Oleg Lokhvitsky