Skip to content

110 Under the Hood

Fasust edited this page Oct 8, 2019 · 18 revisions

Page Table of Contents

Introduction

Flutter (Flutter Dev Team 2018h) is a framework for cross-platform native development. But what exactly does that mean? It means that it promises Native App performance while still compiling apps for multiple platforms from a single codebase. The best way to understand how Flutter achieves this is to compare it to other mobile development approaches.

Full Native Approach

Native app rendering

Figure 1: Native app rendering (Leler 2017)

The classic way to build a mobile app would be to write native code for each platform you want to support. I.E. One for IOS (Apple 2010), one for Android (Google LLC 2008) and so on. In this approach, your app will be written in a platform-specific language and render through platform-specific Widgets and a platform-specific engine. During the development, you have direct access to platform-specific services and sensors (Google LLC 2019a; Stoll 2018; Leler 2017). But you will have to build the same app multiple times, which effectively doubles your workload.

Embedded WebApp Approach

Embedded Web App rendering

Figure 2: Embedded WebApp rendering (Leler 2017)

Embedded WebApps where the first approach to cross-platform development. You would simply build your application with HTML, CSS, and JavaScript and then have it render through a native WebView(Google LLC 2019a; Leler 2017). The problem here is, that developers are limited to the web technology stack and that communication between the app and native services would always have to run through a bridge (Stoll 2018).

Bridges

Bridges connect components with one another. These components can be built in the same or different programming languages (Adinugroho, Reina, and Gautama 2015).

Reactive View Approach

Reactive app rendering

Figure 3: Reactive app rendering (Leler 2017)

Apps build with reactive frameworks (like React Native (Facebook 2015)) are mostly written in a platform-independent language like JavaScript (ECMA 1997). The JavaScript code then sends information on how UI components should be displayed to the native environment. This communication always runs through a bridge. So we end up with native Widgets that are controller through JavaScript. The main problem here is that the communication through the bridge is a bottleneck which can lead to performance issues (Google LLC 2019a; Stoll 2018; Leler 2017; Kol 2017).

Flutter’s Approach

Flutter app rendering

Figure 4: Flutter app rendering (Leler 2017)

Flutter’s approach is to move the entire rendering process into the app. The rendering runs through Flutter’s own engine and uses Flutter’s own Widgets. It only needs a canvas to display the rendered frames on and system events/input it can then forward to your app. The framework also provides a way to access services and sensors through platform-independent interfaces. This way the bridging between the app and the native environment is kept to a minimum which removes that bottleneck (Google LLC 2019a; Stoll 2018; Leler 2017).

You might think that keeping an entire rendering engine inside your app would lead to huge APKs, but as of 2019, the compressed framework is only 4.3MB (Flutter Dev Team 2019a).

Flutter Framework Architecture

Figure 5: Flutter Framework Architecture (Leler 2017)

🕐 TLDR Flutter uses its own engine instead of using the native one. The native environment only renders the finished frames.

Flutter Compiler

One additional advantage of Flutter is that it comes with two different compilers. A JIT-Compiler (Just in time) and an AOT-Compiler (Ahead of Time). The following table will showcase the advantage of each:

Compiler What is does When it’s used
Just in Time Only re-compiles files that have changed. Preserves App State (Flutter Dev Team 2019b) during rebuilds. Enables Hot Reload (Flutter Dev Team 2019d). During Development
Ahead of Time Compiles all dependencies Ahead of time. The output app is faster. For Release

Table 1: Flutter’s 2 Compilers (Moore and Nystrom 2019; Google LLC 2019a)

Hot Reload

Hot Reload (Flutter Dev Team 2019d) is a feature that web developers are already very familiar with. It essentially means, that your changes in the code are displayed in the running application near instantaneously. Thanks to Flutter’s JIT Complier, it is also able to provide this feature.

Hot Reload

Figure 6: Hot Reload (Flutter Dev Team 2019d)

Next Chapter: Thinking Declaratively >

Back to Top