Why re-constructing view hierarchy is affordable in declarative UI frameworks like Flutter?

user_4112049 0
Viewed 143

I am reading Flutter's official documentation on state management and in this page it says:

For example, in Flutter it’s okay to rebuild parts of your UI from scratch instead of modifying it. Flutter is fast enough to do that, even on every frame if needed.

As an Android developer, it is true in most cases that constructing a View is expensive and should be avoided. So I am wondering why re-constructing view hierarchy is affordable in Flutter.

Comparing the class declarations of Android's View and Flutter's Widget, the Android View has much more fields and do a lot of works in the constructor, so I guess one reason is that creating a new class instance in Flutter is cheaper than that in Android. But why Android (as an imperative framework) needs such a complex View class to drive the UI than Flutter (as a declarative framework)? What's the common difference between the UI rendering mechanisms of imperative UI and declarative UI?

declarative-programming flutter imperative-programming android
1 Answers

It's not a difference between declarative and imperative models, per se. It's that Android Views are expensive to create. You're right on the mark when you say "the Android View has much more fields and do a lot of works in the constructor" - this is exactly the problem. Flutter's Widgets are very lightweight, containing just enough information to allow the system to figure out what the Element tree should look like. The Elements are the heavier-weight objects with state that's potentially expensive to recreate (including RenderObjects), and those are created only once (for each Widget location in the Widget tree). After that, they're just updated with new information when there's a change in the Widget tree rather than being recreated from scratch.

Here are a couple articles with some more information that you might find helpful:

user_2082730
Related