-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Attaching (for example creating Animated.Value or using cond, eq, set, etc) and detaching nodes blocks JS thread #194
Comments
@terrysahaidak does this still an issue? |
Hi @sintylapse, yes, it is. And it will be an issue untill reanimated migrate to jsi and react native use fabric. But with 1.3 and proc nodes it might make it less obvious for the user to catch, so performance should be better, haven't tried it yet though. |
I'm running into this too (esp on Android) when adding semi-complex animated values and clock/springs to FlatList items. I've been experimenting with I am still seeing some JS blocking, but definitely an improvement. |
@computerjazz make sure you have ran the animation or just imported that file which has a proc defined before rendering a bunch of items in the flat list. also, make sure you've been defining procs outside the render, they should be static, only then they can be reused and won't block a js thread. |
Hi @terrysahaidak, thanks for reporting the issue, could you provide minimal code example that reproduces the problem? |
Hi @michalsek, did you check out my original comment here? The problem not with my library I've used as an example here. The problem is that reanimated does too many calls to the bridge. You can easily count them using this snippet with any example:
For simply animation it generates thousands of calls where React Native Animated produces 100-200. This is a huge difference. You may not notice it on iOS, but on android, even on fast phone like my pixel 3 it is noticable. We've tried already to fix it using JSI, but it didn't really help. @chrfalch made a fork for iOS where it was 2-3 faster. But there is almost no problem with it on iOS. My fork with JSI on android was 30% faster. This is just nothing. Also to fix it @chrfalch created proc node. It does reduce amount of nodes created. But still, unfortunately, on low-end android it's unusable for most of the cases. |
I'm wondering what the status of this problem is. I know |
Everything I can say so far there is work in progress to fix this! And it's really exciting! I hope it will be released soon! |
Nice! Is there a place I can follow that work? |
@terrysahaidak Could you say, how long will it take to be done(more or less than month :) )? |
For the ones interested: https://twitter.com/kzzzf/status/1263157145572442112 Also, I've had similar problems on complex animation graphs. |
Most issues are connected with initialization/deinitialization and we can't really avoid this because Reanimated 1 is based on animations composed on nodes, so we have to push every node through the bridge. I suggest following the development of Reanimated 2 (it's pretty stable at this moment) and maybe giving it a try - it's way easier to write animations in v2 than in v1. I'm going to close this issue as there's no practical solution to it. |
As someone who's been using Reanimated 2 from times way before the actual release I can confirm it fixes all the issues. |
Updated issue:
Reanimated uses a bridge to interact with the native side. Hight usage of bridge (lots of calls with lots of data to be passed) blocks the thread. Reanimated doing lots of calls. Even simple animation may produce 500-1500 calls. This is huge amount of calls. The main problem that it totally blocks the UI, the app might be showing just a blank screen or freeze until all the nodes are created and connected to each other.
You can verify it by using this simple snippet in your
App.js
(works only with React Native CLI project):Most of the calls are
connectNodes
.There is a thing which may reduce some amount of the calls – proc node. But it does not fix it for low-end devices;
You can verify the delay of rendering everything using this example:
https://snack.expo.io/@terrysahaidak/reanimated-header
Original issue
I'm building a library which helps define an animation without any knowledge of reanimated. It's inspired a lot by Animatable and called react-native-reanimatable.
It relies on
Animated.Code
a lot since mostly I'm triggering animation by some props (changing value which runs/stops clocks).But I'm noticed if I'm using several
Animated.Code
, it creates animated nodes and blocks JS Thread. It's noticeable on both Android and iOS.You can check it out here (on my Xiaomi Mi5 and iPhone 7) with the Expo SDK 32:
https://drive.google.com/open?id=1RUaVYcP6-VG332rGS7lA5RsyRXJh7VTP
https://drive.google.com/open?id=15LDQphmnYyZtajFCERuugPgpUmeOIdG3
You can reproduce it using my lib example app:
https://github.com/terrysahaidak/react-native-reanimatable/tree/master/Example
Navigate to Base transition. It renders 10 components with
Animated.Code
under the hood. You can change count here:https://github.com/terrysahaidak/react-native-reanimatable/blob/master/Example/screens/TransitionBase/TransitionBase.js#L103
Also here is some underlying logic:
Creating animation: https://github.com/terrysahaidak/react-native-reanimatable/blob/master/lib/core/createTransitionAnimation.js
Using of
Animated.Code
: https://github.com/terrysahaidak/react-native-reanimatable/blob/master/lib/components/TransitionAnimation.jsThank you for such a great library!
UPDATE:
I've figured out that
Animation.Code
itself doesn't block the thread, but creating animation values and nodes do.The text was updated successfully, but these errors were encountered: