Difference between Android's Instant Run vs Flutter's Hot Reload and React Native's Hot Reload?

Question

Currently, I was working on React Native Project, and when I shake the Phone after Running Project it gives me live Updates. as I've also worked with Flutter it also provides me the Same kind of OutPut. but, In Android there is a Functionality called Instant Run.

I've googled Instant Run. and Some of the Results differs Instant Run is not Hot Reload for Android Studio.

so, I want to Know what is the Significant Difference in Working and Feature of Instant Run and Hot Reload?

Solution 1

I can't go into technical details, but here are a few practical differences:

• Flutter Hot Reload is a lot faster than Instant Run
• Instant Run sometimes fails and causes a full rebuild, which can take minutes.
• Flutter Hot Reload is scheduled automatically when you save a file, and there is no lag. Instant Run causes a lot of lag, which is distracting.
• No state is lost on Flutter Hot Reload, whereas when using Instant Run it often happens that the app is reset
• Flutter also allows you to restart the app (resetting state) in less than a second (can take minutes in Android)
• Flutter Hot Reload also works while the app is in background
• When making changes to the native Android and iOS shell of your Flutter app, Flutter Hot Reload does not help you. You have to do a full rebuild with Gradle/XCode (which will also reset state)

Solution 2

There is actually very little difference between how Flutter's Hot Reload and Android Studio's Instant Run work.

They both check for code changes, do a compilation step only on what has changed, and then send it to the phone to be run. Both the Android and Flutter apps run a VM (jvm, or dart vm) which is capable of changing classes on the fly.

---

When you do a Flutter Hot Reload it is doing a quick incremental compilation step and then sending your dart code to the phone where it is run pretty much instantaneously. This is so fast partly because Flutter uses a JIT model of compilation when running in debug mode, which means that less time is spent compiling but that the first run (or first few runs) of a method might not be optimized. State is persisted between changes in many cases because of the way flutter works, not through anything innate to the dart JIT processing. And for some things (static & initState functions come to mind), you actually have to do a Full Reload which re-initializes the app's state, but is still almost instant.

---

What Android Studio for Instant Run is pretty similar, but is always fully compiled. The VM has some instrumentation so that when a method is called, the VM checks if a new class has been injected. Instant Run will do it's best to replace as little as possible; if it can simply replace some of the classes it will, but it often needs to replace the entire activity and sometimes the entire app. Here's a good diagram from this blog (which is worth a read if you want a deeper understanding):

---

Functionally, Instant Run and Hot Reload should be pretty similar. However, in practice I've found that flutter's Hot Reload is quite a lot faster than Instant Run, especially for an app of any size.

Furthermore, I have found that the way flutter deals with States lends itself much better to recomputed classes than the way Android's activities work. In Flutter, you have many classes involved with the UI each with their own state, and changing just a couple of them is pretty quick. Alternatively, with Android you tend to have larger Views or Activity UI which takes more effort to replace and often result in reloading activities rather than simply a class here and there.

Comments

[pavi2410]

How Flutter is able to do JIT compilation when iOS disallows it?

[rmtmckenzie]

@Pavitra it only does JIT in debug mode; in release mode it is statically compiled. So you get the best of both worlds!

[pavi2410]

I'm not familiar of iOS dev, but is JIT restriction enforced by OS level or is it just an Apple App Store policy?

[rmtmckenzie]

@Pavitra it's just an App Store thing. Browsers rely heavily on JIT for javascript.

[pavi2410]

But again, I read that JS is an exception... which may be the reason Apple only allows WebKit engine to be used by browsers.