mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
5a9b6fc49b
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
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.