Flutter: Architecture, Hot Reload, Plugins, Build Process, Performance and Integration

Flutter is Google’s open‑source, cross‑platform UI framework that enables a single codebase to run on iOS, Android and the upcoming Fuchsia OS. Since its first release in May 2017, Flutter has shipped more than 60 versions, including the production‑ready “Beta 3” and “Release Preview” builds.

The framework’s goal is to provide native‑level performance while sharing UI code across platforms. It achieves this by rendering UI with the Skia graphics library and executing app logic in Dart, which supports both AOT (ahead‑of‑time) and JIT (just‑in‑time) compilation.

Flutter defines two core widget types: StatelessWidget for immutable UI and StatefulWidget for components that react to state changes. The framework’s hot‑reload feature injects updated Dart code into the running VM, rebuilding the widget tree within a few hundred milliseconds. Hot‑reload, however, has several limitations:

Compilation errors – the VM will report an error and require a code fix.

Changing a widget from StatelessWidget to StatefulWidget (or vice‑versa) causes type‑mismatch crashes.

Global variables and static members are not refreshed.

Modifying the root widget in main() does not replace the existing root.

Changing a class to an enum or altering generic type parameters also fails.

If hot‑reload cannot apply the changes, a hot‑restart (full VM restart) can be used to reload all code while resetting state.

Flutter plugins bridge Dart code to native Android APIs. Common plugins include:

android_alarm_manager – access Android AlarmManager android_intent – construct Android Intent battery – monitor battery status

connectivity – network connectivity

device_info – device model information

image_picker – pick or capture photos

package_info – app version info

path_provider – common file paths

quick_actions – home‑screen shortcuts

sensors – accelerometer & gyroscope

shared_preferences – key‑value storage

url_launcher – launch URLs, calls, SMS

video_player – video playback

Dependencies are declared in pubspec.yaml:

dependencies:
  flutter:
    sdk: flutter

  shared_preferences: "^0.4.1"

Dart is a strong‑typed, cross‑platform language with optional type inference, generics, top‑level functions, and a simple visibility model (underscore‑prefixed identifiers are library‑private). It can be compiled to JavaScript (dart2js), run on the Dart VM, or AOT‑compiled to native code (used by Flutter).

The Flutter framework is organized in a layered architecture:

Foundation – low‑level utilities.

Painting – wrapper around Skia for drawing.

Animation – value animators and interpolators.

Gesture – touch handling.

Binding – system‑service equivalents (e.g., WidgetsFlutterBinding).

Widgets – Material & Cupertino UI components.

Rendering – RenderObject tree for layout and painting.

Key rendering classes (excerpt):

abstract class RendererBinding extends BindingBase with ServicesBinding, SchedulerBinding, HitTestable { ... }
abstract class RenderObject extends AbstractNode with DiagnosticableTreeMixin implements HitTestTarget { ... }
abstract class RenderBox extends RenderObject { ... }
class RenderParagraph extends RenderBox { ... }
class RenderImage extends RenderBox { ... }
class RenderFlex extends RenderBox with ContainerRenderObjectMixin<RenderBox, FlexParentData>, RenderBoxContainerDefaultsMixin<RenderBox, FlexParentData>, DebugOverflowIndicatorMixin { ... }

Widget base classes (excerpt):

class WidgetsFlutterBinding extends BindingBase with GestureBinding, ServicesBinding, SchedulerBinding, PaintingBinding, RendererBinding, WidgetsBinding { ... }
abstract class Widget extends DiagnosticableTree { ... }
abstract class StatelessWidget extends Widget { ... }
abstract class StatefulWidget extends Widget { ... }
abstract class RenderObjectWidget extends Widget { ... }
abstract class Element extends DiagnosticableTree implements BuildContext { ... }
class StatelessElement extends ComponentElement { ... }
class StatefulElement extends ComponentElement { ... }

To integrate Flutter into an existing Android app, the project can be built as an AAR by adding flutter create . and adjusting build.gradle. The resulting AAR contains all Flutter runtime assets (engine SO, ICU data, snapshots).

Image resources are usually placed in Android drawable directories. Since Flutter expects assets, a custom WMImage widget loads images from the app’s private file area, preserving the original resource layout without inflating the APK.

Platform channels enable Dart ↔ Java communication. Example Dart side:

import 'dart:async';
import 'package:flutter/services.dart';
const MethodChannel _channel = MethodChannel('com.sankuai.waimai/network');
Future<Map<String, dynamic>> post(String path, [Map<String, dynamic> body]) async {
  return _channel.invokeMethod('post', {'path': path, 'body': body})
      .then((result) => Map<String, dynamic>.from(result))
      .catchError((_) => null);
}

Corresponding Java implementation:

public class FlutterNetworkPlugin implements MethodChannel.MethodCallHandler {
  private static final String CHANNEL_NAME = "com.sankuai.waimai/network";
  @Override
  public void onMethodCall(MethodCall methodCall, MethodChannel.Result result) {
    switch (methodCall.method) {
      case "post":
        RetrofitManager.performRequest(
            post((String) methodCall.argument("path"), (Map) methodCall.argument("body")),
            new DefaultSubscriber<Map>() {
              @Override public void onError(Throwable e) { result.error(e.getClass().getCanonicalName(), e.getMessage(), null); }
              @Override public void onNext(Map response) { result.success(response); }
            }, tag);
        break;
      default:
        result.notImplemented();
        break;
    }
  }
}

Flutter’s official engine ships SO libraries for armeabi‑v7a, arm64‑v8a, x86, and x86‑64. To support devices that only provide the older armeabi ABI, the engine JAR can be repackaged by moving lib/armeabi‑v7a/libflutter.so to lib/armeabi/libflutter.so in each android‑arm* artifact.

During gray‑release, a feature flag (Horn) controls whether the Flutter page is enabled. If a device crashes in native code (JNI crash), a flag file FLUTTER_NATIVE_CRASH_FLAG is created; subsequent launches skip Flutter on that device, providing an automatic downgrade path.

Dart exceptions include full stack traces with file names and line numbers, while native crashes require symbolication. Using ndk‑stack together with the engine’s symbols.zip (downloaded from the Flutter infra bucket) resolves addresses to source locations.

Performance comparison:

Load time – native AllCategoryActivity median 210 ms vs. Flutter FlutterCategoryActivity median 231 ms (extra cost from Flutter view initialization).

Frame rendering – Android native average 10.21 ms per frame (8.51 % jank) vs. Flutter average 12.28 ms (9.87 % jank). After the first few frames both achieve comparable smoothness.

Native frame metrics are captured via Window.OnFrameMetricsAvailableListener. Flutter’s rasterizer was instrumented (in src/flutter/shell/common/rasterizer.cc) to log per‑frame timings, enabling a fair comparison.

In summary, Flutter offers a modern, high‑performance UI toolkit for mobile, with fast development cycles (hot reload) and a single Dart codebase. Integration into existing native apps is feasible via AAR packaging, though it adds ~5.5 MB to the APK (including engine SO and ICU data). Flutter excels in scenarios demanding consistent cross‑platform UI and smooth animations, while dynamic code deployment remains easier on Android than iOS.