Summary: There is no point in dispatching to main thread if there is nothing to do there.
This place gets called basically any time a repeating js timer fires, which doesn't imply UI changes (although usually that's why people setup timers).
Combined with previous diffs that makes us not generate empty blocks (nil instead), this could be minor perf win in some rare cases.
This also changes semantic of `reactBridgeDidFinishTransaction` call a bit. Previously it was done no matter if UI has changed or not.
I think it should be safe, since seems like callees really care only about views being laid out.
Depends on D2571166. (not strictly speaking)
public
Reviewed By: jspahrsummers, nicklockwood
Differential Revision: D2571188
fb-gh-sync-id: 02d52e4615475072c3c27226e67c431a667ec990
Summary: Same as in previous diffs. Gets us into a better place to know if we really have UI updates and it's marginally more efficient.
Depends on D2571143. (not really)
public
Reviewed By: nicklockwood
Differential Revision: D2571166
fb-gh-sync-id: e8f34521ec2e12156a49f1cd655e92df1db34fca
Summary: Previously `_bridgeTransactionListeners` were informed about `reactBridgeDidFinishTransaction` inside of one of the UI blocks.
That seems pretty arbitrary, doesn't really mean a "transaction" is really over (assuming transaction means all UI updates) and even when that block does nothing we still need to call these listeners, since there could be other UI blocks generated somewhere else!
So I've moved this call to a place that seemed better (=after all UI blocks are done), since all listeners are interested in knowing when layout has happened.
public
Reviewed By: nicklockwood
Differential Revision: D2571122
fb-gh-sync-id: 62be03ebc4353d6f6318c9765079b87b07483be2
Summary: public
Kill `RCTPerfStats` and introduce the new `RCTPerfMonitor`, including memory
usage, JSC heap size, number of RN views in screen, FPS (both on UI and JS threads)
and more to come.
It removes all the previous traces that were previous spread across the bridge
and the dev menu and moves everything to be more contained, so the whole thing
can be safely striped in production.
Reviewed By: nicklockwood
Differential Revision: D2575158
fb-gh-sync-id: 6a6d0c4422adbddeeefddd32ec3409a7095ff2a9
Summary: While we shouldn't invoke `bridge.devMenu` in production, doing it will result into a crash.
1. `devMenu` internally calls `RCTBridgeModuleNameForClass([RCTDevMenu class])`
2. `RCTBridgeModuleNameForClass()` calls `moduleName`
3. In the release code `RCTDevMenu` doesn't export the `moduleName` class method.
Closes https://github.com/facebook/react-native/pull/2910
Reviewed By: svcscm
Differential Revision: D2550797
Pulled By: tadeuzagallo
fb-gh-sync-id: 5dfbf905e5a02d9fd3b52f8b3d6eefc4e3ff30b2
Summary: public
Benchmarking our startup path has shown we spend a lot of time decoding strings (iPhone 4S / iPhone 5):
* reading a 2MB JS bundle: 35ms / 15ms
* decoding is to an `NSString`: 186ms / 78ms
* transforming that to a `JSString`: 29ms / 10ms
Instead of going through an `NSString` transformation, we generate a null-terminated bundle (0.1ms / 0.05ms to copy the data) and use `JSStringCreateWithUTF8CString` (121ms / 53ms) to generate the string. That makes decoding 70% faster.
Reviewed By: javache
Differential Revision: D2541140
fb-gh-sync-id: 09a016b8edfd46a9b62682c76705564d2024e75e
Summary: @public
This diff implements inline image support for <Text> nodes. Images are specified using <Image> tags, however all properties of the image are currently ignored apart from the source (including width/height styles).
Images are loaded asyncronously, and will trigger a text re-layout when they have loaded.
Reviewed By: @javache
Differential Revision: D2507725
fb-gh-sync-id: 59d0696d00a1bc531915cc35242a16b2dec96e85
Summary: When you reload and create a new bridge, one of the things that happens during setup is that the RCTAccessibilityManager fires a notification. The old bridge would receive this notification from the new bridge's RCTAccessibilityManager, which we don't want, especially because the two are running on different shadow queues.
I believe this led to a gnarly crash in NSConcreteTextStorage because RCTMeasure in RCTShadowText.m was getting called for the old RCTText (getting destroyed) from a notification fired from the new shadow queue. The fix is for the UIManager to handle notifications only from its bridge's RCTAccessibilityManager. See #2001 for the kinds of crashes we were seeing.
Closes https://github.com/facebook/react-native/pull/3279
Reviewed By: @svcscm
Differential Revision: D2521652
Pulled By: @nicklockwood
fb-gh-sync-id: a4ffe3ef8304667727e573e2a2e8b716e1d2f3e1
Summary: This adds workarounds for the code that was preventing React from compiling when linked against an iOS App Extension target.
Some iOS APIs are unavailable to App Extensions, and Xcode's static analysis will catch attempts to use methods that have been flagged as unavailable.
React currently uses two APIs that are off limits to extensions: `[UIApplication sharedApplication]` and `[UIAlertView initWith ...]`.
This commit adds a helper function to `RCTUtils.[hm]` called `RCTRunningInAppExtension()`, which returns `YES` if, at runtime, it can be determined that we're running in an app extension (by checking whether the path to `[NSBundle mainBundle]` has the `"appex"` path extension).
It also adds a `RCTSharedApplication()` function, which will return `nil` if running in an App Extension. If running in an App, `RCTSharedApplication()` calls `sharedApplication` by calling `performSelector:` on the `UIApplication` class. This passes the static analysis check, and, in my opinion, obeys the "spirit of th
Closes https://github.com/facebook/react-native/pull/1895
Reviewed By: @svcscm
Differential Revision: D2224128
Pulled By: @nicklockwood
Summary: - Includes the error cookie with soft exceptions as well since they too can be updated (requires tiny Android change too)
- Passes the error cookie through instead of leaving it unused
Closes https://github.com/facebook/react-native/pull/2198
Reviewed By: @svcscm
Differential Revision: D2455391
Pulled By: @sahrens
Summary:
I'd like this ability as this has a tendency to get in the way of some of the more complex UI pieces I have. Disabling RCT_DEV entirely is too much for me.
Closes https://github.com/facebook/react-native/pull/2451
Github Author: Tj <tfallon@mail.depaul.edu>
Summary:
We currently wait until after views have been updated on the main thread before sending layout events. This means that any code that relies on those events to update the UI will lag the atual layout by at least one frame.
This changes the RCTUIManager to send the event immediately after layout has occured on the shadow thread. This noticably improves the respinsiveness of the layout example in UIExplorer, which now updates the dimension labels immediately instead of waiting until after the layout animation has completed.
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
Summary:
Add JSC profiler to the dev menu and rename the pre-existent one to systrace.
For now it just outputs to the console, but a better workflow is on the way.
Summary:
Our events all follow a common pattern, so there's no good reason why the configuration should be so verbose. This diff eliminates that redundancy, and gives us the freedom to simplify the underlying mechanism in future without further churning the call sites.
Nick Lockwood
Pawel Sienkowski
Martin Kralik
Tadeu Zagallo
Patrik Tomas Chamelo
Ryan Olson
Frédéric Sagnes
James Ide
Chace Liang
Pieter De Baets
Alexey Lang
Jiajie Zhu
Yusef Napora
Dave Miller
Martin Konicek
Tj
Alex Kotliarskyi
Matt Mahoney
Alexsander Akers