mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
Emily Janzer
f054928124
Summary: This diff splits up the current `createTimer` method (which is used for setTimeout, setInterval, etc.) into two methods, `createTimer` and `createAndMaybeCallTimer`. The latter is what's used by the existing Timing native module, and it preserves the existing behavior of this function. What's the difference? The current implementation of createTimer makes some assumptions about how it's called - namely, that it's called from JS asynchronously (using the bridge). Right now when you create a timer from JS, the JSTimers module passes in the timestamp for when the timer was created; in the native `createTimer`, we compare this timestamp to the current time, and if we find the timer has already expired, we immediately invoke the callback. Presumably this is done because we don't know how much time has elapsed since when the timer was scheduled in JS, and we want to make sure that it's called as soon as possible. Of course, this also means that `setTimeout(0)` will be immediately invoked, too, without waiting for the next frame. This all sounds fine, until we take a look at immediates. Immediates are currently implemented entirely in JS, and are called by the JS bridge; before returning control to native, we flush the immediates queue. This means that the current behavior is: 1) `setImmediate()` is always invoked before `setTimeout(0)`; 2) `setTimeout(0)` is invoked as soon as possible, before the next frame. However, this changes with bridgeless RN. With bridgeless RN, the native module methods are being replaced by C++ host functions, which are called synchronously. So if we keep the current logic in JavaTimerManager (where it checks if the timer has already expired), then `setTimeout(0)` will be invoked **before** immediates are called. So the change that I'm making for bridgeless RN is to always wait until the next frame before calling timers. This preserves the order of immediates/timers, although it does mean that `setTimeout(0)` will no longer be called as soon as possible. Of the two options, this seems preferable. Reviewed By: PeteTheHeat Differential Revision: D17403144 fbshipit-source-id: 8230f6ebe56aa20bfcf2325177c7812bc8e9c2ec
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.