React Native Under the Hood - Rotem Mizrachi Meidan

[Music] you [Music] hi my name is autumn I'm a mobile infrastructure engineer at weeks and I'm here to talk about stuff in react native so let's just dive in being a good citizen is a term often used by the android framework team as a developer at being dismissive of the the amount of resources that we that are being used in the application is something that is probably not that a good idea so let's let's try to make a comparison between what a good citizen means in the real world and what it means in mobile and so in the real world we as a good citizen as good citizens we want to obey laws in the mobile and we want to make sure we're not being malicious and that we're respecting the user's privacy in the real world we want to respect the natural resources we're not going to leave the tap open right when we leave the sink we don't want to leave their car engine starting and running and we don't want to do any kind of something that is then is not respectful for the resources themselves in mobile and we don't we don't want to abuse CPU we don't want to consume to consume lots of RAM and we want to minimize bandwidth usage well it all comes down to battery life right and the most the most important thing about that is that users notice users know when when your application abuse their abuses their phone there and with users there are no second chances they want the app fast useful and without consuming lots of resources so I just collected a few a few reviews from users on pretty big applications on Facebook and facebook Messenger Google Plus Google Chrome and Apple music and as you can see everybody makes mistakes even the big ones make mistakes the last one is my favorite bye for Mark Zuckerberg don't download that it will ruin your phone so we're talking about applications that are often often laggy and and and users are used to high performance today on native applications and and one of the most notable thing the most notable performance issue is sub 60fps animations so let's take a step back and understand the illusion of motion the human eye it doesn't act like a camera there is no snapshot there's no sorry there are no snapshots sent from the eye to the brain instead the brain is constantly processing visual of simulations that are coming from the eye frames are effectively a hack it's it's a hack on our on our eyes on our brain by displaying images fast enough we can trick the human in the human eye and the brain to perceiving motion where there's actually isn't any so how fast we display those images well this display it has a large effect on how fluid emotion actually looks to us so if we take a look at this video we can see oh that's nice on the right screen ah yeah it's great so the minimum the minimum you need in order to start perceiving motion is from 10 to 12 frames per second before the human eye actually starts understanding that this we're we're talking about animations it's like the Flipboard we saw on the previous video however it doesn't look that smooth if we're going but if we're going up to 24 or 30 frames per second that that's that the frame rates we usually get on TV on on on cinema films it looks a bit better but these actually look look good only because there is a motion blur but I don't want to get into it 60 frames per second is is the sweet spot well most humans won't be able to to perceive the benefits of going over 100 going over a 60 frames per second so I'm just want to one just want you to look at that video and see if if there is any benefit of going 120 frames per second is that anyone can see any difference between the 60 and 120 frames per second yeah you can which ones that the 60 into 100 120 all of them precisely the same okay how about now ah okay how about now what they're not no they're not actually they are actually no they are they are actually if you'll stop them at a 15 and on one on one ah it's yeah it's on one over 15th of a second then everything will be synched so if you did see a difference well your brain is lying to you because this video is 60 frames per second and there's no way there's a difference so what am i mumbling why am i mumbling about this any any of you who developed purely native applications understand that there is a clear set of rules to making your application running smoothly at 60 frames per second well the major one is offloading work from the UI thread and when we talk about react native the deck of cards is is being flipped being shuffled I'm sorry as this framework this framework works very differently that well guy give gave you a pretty good explanation about that of the work differently of native apps well react native abstracts the native environment and to a certain extent of course and and but but is that is that good for the developer so that's by no means a complete pros and cons list but just to just for my purposes so what are the pros the pros are everybody talks about that that's a true cross-platform solution and the shared business logic and and learn once right everywhere you can use your JavaScript skills on both Android and iOS and you can truly be more productive but but but the cons are that the system itself your application is is much more complex than than a true native application it means that there are more moving parts it's a big framework with a JavaScript virtual machine and a complex translation mechanism that's what guy talked about and and when things break it's much harder to understand um ok so in order to understand the system we need to have a knowledge of its core and this is courtesy of Talca hall he used that diagram on on a talk he had in to mid day in the first meetup so at the high level I'll be repeating a bit of guys of guys talk at the high level is that there is a translation being handled by the bridge the message queue and most of the operations most of the operations we do are being passed over the bridge network requests Network responses layout measurements render requests I user interactions IO operations to almost everything that that includes non arithmetic calculations or well you're laughing there I see you and making sure that the message queue isn't congested is critical in order to ensure the smooth operation of the app so rack native made a pretty good logger for the message queue the message queue has a spy feature and enabling it will emit logs and and lots of all the messages that are being passed from the JavaScript to the native and back and and we will and will it will help us to understand what actually is being happy what actually happens in our application so let's take an example of a simple layout we're defining a layout using JSX nothing too fancy that's actually the default welcome a hello world application of react native asou the business logic in react native is being written nsj and the views are native so we need to do this this translation to native so when we start looking at the logs this is actually the log that is being output from the message queue when the system generates the native views so we can see that there is a native module being called UI manager and there is a function that is called create view and it tells it in our city view with all kinds of parameters and well and it's it's created it's it's telling it to to create a view with specific layout parameters and some text nothing too fancy and here that's a different output of a single touch event and I'm just going to go over it a bit the first message is from the native to the JavaScript I'm not sure you can see it is that okay can can everyone read okay so the native tells the JavaScript that the touch event has started and it's sending the information to of this touch event and and it also starts the timer to - to calculate the length of the touch event when we use applications that have touch touch input and in mobile applications we usually have a touch start and a touch end it's when we press and when we leave so the first one is touch start the second event is the JavaScript telling the native well okay I understood that view is at the touch event when when it is being calculated by JavaScript on the on the shadow Dom but this is the actually the view the higher the whole hierarchy being being calculated also on the JavaScript side just in order to understand the business logic and understand which view needs to be to be handled now the JavaScript says tells the native okay I see that native view with ID 23 needs to handle this touch event and then the native said okay touch event is ended I I put my finger I left the finger of the of the screen and the handler is being reset so how these things work have actually a big impact on how the UH performs under a stress the communication is been in JavaScript and and native is assassin Cronus and the cue handles the messages as they arrive and assuming that the bridge is now the JavaScript thread is is now busy messages that are being sent will be handled with large delays so frozen UI anyone who used the phone ever have have encountered frozen UI on certain applications not nothing you don't need to be a developer to experience this this happens on iOS and Android applications when when there are long-running operations on the on the UI thread but in react native it's it's a bit different because react native direct native does a pretty good job of offloading everything from the main thread giving the main thread the freedom to only render views and and all the business logic is executed in the JavaScript thread we'll call it MQ tjs from now on okay and and we may encounter now now that this works as it does we may encounter different kind of sluggishness in the application and then what we use we've used to in native applications and instead of being non-responsive and on Android it may cause this screen that that's is called an a in our application not responding the app will feed back to touches you will see that everything that the native view itself is responsive if there is a scroll view that is being scrolled natively it will work as expected but nothing else nothing that it that that actually being written in JavaScript handlers I mean um callback handlers will not will not work and and we're going to see a little demo of that so for the purpose of this demonstration I extracted example movies it's an example from react native it's it's inside the main repo and I made a few changes just just to it be would be just we would be able to get a better understanding of how it works so let's take a point of reference this screen recording is showing is running on Android emulator on my computer and a message queue spy logs being emitted and I'm watching them via ADB on Android so you can see me clicking on jack reacher great great rating so what happens here is that we can see well we can't actually see that but it will stop the video we can see that there are touch events being sent to native and back and layout operations to the UI manager and and also at the animation the animation here is also JavaScript animation so the alpha the Alpha values for each frame are will be also being sent from the JavaScript to the native side but take this as a point of reference this is how the app should work when it's written like this so what happens when the JavaScript thread is under heavy load when I'm going to press the spam mq TGS button that's the button that is most close to the to the search bar the function that is called the function the function act busy is going to be called this function just calculates x from start to now and it just goes like this for 8 seconds this renders the the the JavaScript thread completely useless nothing can work nothing can be handled by the JavaScript thread the only thing it does is just acting busy so this is how the app works when it's busy I'm spamming the queue I'm spamming the I'm sorry the demco t.j.s and you can see I can scroll the native view but when I press nothing happens and then after eight seconds it works now you can see now that mom that the message queue is stuck nothing is being handled by the message queue no logs are remitted on the message queue it's just frozen the application itself the actual the actual JavaScript is frozen but a native works okay where are we now and did any of the actions we invoke you're cute yeah if you can see back going back so if you can see here I'm spamming the cube then I'm trying to press it you can you see that well well I stopped now I'm just waiting for it and then it works I mean everything there message are being the messages are being cute but nothing is being handled actually nothing it can't call the the JavaScript callback it doesn't handle it it just okay so it did it did it just ad handle the jack reacher tap it didn't it just it just the native just created a message that is now being sent over the queue but it stops because JavaScript can handle that now Oh actually we had we had this kind of of shenanigans in a rap before and it was handled multiple times by the JavaScript so so yeah it could be yeah it could crash the app or open multiple screens yeah it does it it it's a Twilight Zone there yeah it's funky anyone here okay great so let's go to the second so what happens when there is heavy load on the message queue itself the heavy load on the message queue also can cause delays on callbacks and and choppy JavaScript animations and it actually are I can just show you spamming the bridge here actually now just creating I'm creating I'm going back again I'm setting a timeout and calling this a timeout thousands of times in a second set timeout and react native is being translated to timing create timer in native and create timer a native actually returns a callback to JavaScript when it when that time when time passes and and and the timer is done so what happens here is thousands of messages going from JavaScript to native and coming back and spamming the queue and running the app now actually seems like it's working pretty okay but we really can't can actually see the the important messages we want to see the the press they own presses and the handling of their creation of the of the views we can just see all the crap from from create a timer and the app itself look at the animations there are not as smooth as they were before and just a reminder this is working on an emulator powered by a core i7 on my computer it won't work like this on a device um okay so going forward let's see how these situations affect the CPU so first let's talk a bit about basic CPU usage terms on Linux because Android you time is CPU time spent on user code its measured in clock ticks of the CPU and s time is CPU time spent on kernel code which which also is measured in clock ticks in Android studio we can open an Android device monitor which is this lovely screen here and we have a few a few of very great tools that that can help us understand what's going inside inside any application so we want to click the button in the red rectangle here this is update threads this is just Android I'm sorry guys bye okay so we can see MQ tjs here that that thread has spent 22 CPU ticks on going from on going from on the on the first demo I showed you on the point of reference so 22 ticks right the next one are we in the next one we are okay the next one has spent almost 1,600 on s time and 25 on on you time that this means that we can see that mq TGS now works very hard on doing stuff and and the JavaScript ready was actually being spammed and and and worked very hard and when we take a look on the third one which is um that the message queue is being spammed we see something different the MQ TGS is also being spammed right we have here 700 and never mind you know it's above 2500 CPU ticks on MQ TGS and the number of thread is joining the pipe party here that is mqt native modules on android there is a thread that handles all the logic that is being executed on native modules and and this spread is also being bombarded here and let's try to understand why well first the JavaScript the JavaScript thread is very busy on creating messages and passing them over the bridge just to create timers and then the native module in turn is creating those timers and waiting for them to end and sending back callbacks it also creates messages and sent sending them over the bridge so both threads are very very busy so the main the main take out here is that excessive traffic over the bridge puts both the JavaScript and native threads in overdrive so problems problems problems yeah the Android UI thread is not busy that's right the native handling the UI the UI thread is not busy and yes it is not busy and the native handling on the UI thread is working as expected so if it would make a sample application that has native on click Handler on one on one button and the other button is is handled in JavaScript the native button will work perfectly and the JavaScript button will just have to wait for the message to processed so going back as we said before we have to respect the message queue we have to to know what's going on on the message queue and when we have bugs we have to understand that that's the first thing that we need to to to log in order to to understand how the application works and actually that that's a pretty good point of reference to anything that are the react that the pure react native application does because well I don't know any any kind of tool that can show me all the events that are being handled on the native application from and for free right calling Network requests and IO operations and and native a handling of of touch events everything is being streamlined in the log of the message queue there is nothing that I know of that works like this for free out of the box on the native platforms themselves so it's it's pretty pretty amazing tool so problems problems how do we solve them well there isn't any definitive answer for that and you have to know what your code does so debug your code use the message queue spot logs monitor the CPU you can also use remote debugging and use a chrome profiler to see what what is being actually being invoked in the JavaScript thread and and find the smelly parts and fix them item Shalaby TM so you can try it for yourself if you want it's in my private gita it's a private key it's it's a public key tab repo in my account and there is also a medium post I wrote about this you can go inside and find more details about what we just spoke about and I think I'm done if you have any questions so that's a hard question yeah I'm going to repeat it the gist of it so smart guy here asked if Android and also iOS the rule is flatten your views make them as as as performant as you can less views you have in the hierarchy the the less time it will take the the UI UI manager to traverse over the tree and create the views for you and and update them so react native well the the UI manager it's a that's the class that actually creates the views gets them the events from JavaScript from from the translation of the JSX back to native it's well I'm not sure it's it's it's on par with native applications I know that there there there is some bloat over there and I'm sure that is something that the Facebook are looking into very hard but I don't have an answer for that I hope it's okay I don't know if there is nothing else then thank you very much guys [Music] you

Channel: Wix Engineering Tech Talks

Views: 5,304

Keywords: Wix.com, Wix Tech Talks, Tech Talks, Wix Engineering, Wix Eng

Id: NkbO-Vhqbl0

Length: 30min 20sec (1820 seconds)

Published: Sun May 28 2017