The core architecture of flutter

Flutter is a cross-platform UI toolkit for iOS and Android, promoting code reuse and direct platform service integration to create high-performance, platform-specific apps with shared code. Flutter compiles apps to machine code for various platforms or JavaScript for the web, boasting open-source flexibility with a BSD license and a rich ecosystem of third-party packages.

Architectural layers

Flutter is designed as an extensible, layered system. It exists as a series of independent libraries that each depend on the underlying layer. No layer has privileged access to the layer below, and every part of the framework level is designed to be optional and replaceable.

Flutter's embedder is tailored to each platform, like Objective-C for iOS, Java for Android, and C++ for Windows, At the core of Flutter is the Flutter engine, which is mostly written in C++ providing the essential building blocks to power all Flutter applications.

dart:ui exposes the engine to the Flutter framework by encapsulating the underlying C++ code into Dart classes. Typically, developers interact with Flutter through the Flutter framework, which provides a modern, reactive framework written in the Dart language.

Anatomy of an app

Dart App: Composes UI widgets, implements business logic, and is owned by the app developer.

Framework: Offers a higher-level API for building quality apps, including widgets, hit-testing, gesture detection, and text input. Composites the app's widget tree into a scene.

Engine: Rasterizes composited scenes, provides low-level implementation of Flutter's core APIs (e.g., graphics, text layout, Dart runtime), and integrates with platforms using the Engine's Embedder API.

Embedder: Coordinates with the OS for rendering, accessibility, and input services, manages the event loop, and exposes platform-specific APIs for integration into apps.

Runner: Combines platform-specific APIs exposed by the Embedder into a runnable app package on the target platform, typically generated by flutter create and owned by the app developer.

Reactive User Interface

Flutter is a reactive, declarative UI framework, in which the developer provides a mapping from application state to interface state, and the framework takes on the task of updating the interface at runtime when the application state changes. This model is inspired by React framework, which includes a rethinking of many traditional design principles.

Apps update their user interface in response to events (such as a user interaction) by telling the framework to replace a widget in the hierarchy with another widget. The framework then compares the new and old widgets, and efficiently updates the user interface.

Composition
The class hierarchy is deliberately shallow and broad to maximize the possible number of combinations, focusing on small, composable widgets that each do one thing well. Core features are abstract, with even basic features like padding and alignment being implemented as separate components rather than being built into the core. 

for example, to center a widget, rather than adjusting a notional Align property, you wrap it in a Center widget.

Building widgets
Override the build() function to return a new element tree. This tree represents the widget’s part of the user interface in more concrete terms. For example, a toolbar widget might have a build function that returns a horizontal layout of some text and various buttons. As needed, the framework recursively asks each widget to build until the tree is entirely described by concrete renderable objects. The framework then stitches together the renderable objects into a renderable object tree.

The framework does the heavy lifting work to determine which build methods need to be called based on the render object tree

On each rendered frame, Flutter can recreate just the parts of the UI where the state has changed by calling that widget’s build() method. Therefore it is important that build methods should return quickly, and heavy computational work should be done in some asynchronous manner and then stored as part of the state to be used by a build method.

Widget state

If a widget has a counter that increments whenever the user taps a button, then the value of the counter is the state for that widget. When that value changes, the widget needs to be rebuilt to update its part of the UI. These widgets subclass StatefulWidget, and (because the widget itself is immutable) they store mutable state in a separate class that subclasses State. StatefulWidgets don’t have a build method; instead, their user interface is built through their State object.

import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: MyCounterWidget(),
    );
  }
}

class MyCounterWidget extends StatefulWidget {
  @override
  _MyCounterWidgetState createState() => _MyCounterWidgetState();
}

class _MyCounterWidgetState extends State<MyCounterWidget> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Counter App'),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'Counter Value:',
            ),
            Text(
              '$_counter',
              style: TextStyle(fontSize: 48),
            ),
            ElevatedButton(
              onPressed: _incrementCounter,
              child: Text('Increment'),
            ),
          ],
        ),
      ),
    );
  }
}

Whenever you mutate a State object (for example, by incrementing the counter), you must call setState() to signal the framework to update the user interface by calling the State’s build method again.