Files
react-native/ReactAndroid
Joshua Gross 5a9b6fc49b Simplify LockFreeEventDispatcherImpl further
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
2021-05-24 20:14:46 -07:00
..
2020-12-08 15:56:51 -08:00

Building React Native for Android

See the docs on the website.

Running tests

When you submit a pull request CircleCI will automatically run all tests. To run tests locally, see Testing.