Exploring Flutter Memory Management and Image Handling on Android

We aim to use Flutter for unified mobile app development and investigate its memory usage, which is a critical concern on resource‑limited devices. This article introduces Flutter’s memory mechanisms, presents test results, and discusses practical implications for Bitmap and View memory consumption.

Dart Runtime Overview

Flutter’s framework runs on the Dart VM, which is AOT‑compiled to native bytecode, eliminating interpretation overhead. The Dart VM separates memory into a New Generation (young) and an Old Generation (old). The young generation uses a copying‑and‑clearing GC (from/to spaces), while the old generation employs a concurrent mark‑and‑clear algorithm similar to the JVM.

Image Memory Exploration

Flutter provides an Image widget for displaying pictures. To compare its memory impact with Android’s ImageView, we added images one by one on a screen, slightly shrinking each new image to avoid complete overlap, and recorded memory usage with Android Profiler on Android 6.0, 7.0 and 8.0 devices.

Results:

On Android 6.0 and 7.0 the Java heap grew, while on Android 8.0 the native heap grew. The conclusion is that the native ImageView uses Java heap on older versions and native heap on newer ones.

Flutter’s Image consumes neither Java heap nor native heap; it resides in a separate Graphics memory region, which reduces the risk of OOM on Android devices.

Flutter’s ImageCache caches loaded images, but unlike Android’s LruCache it limits the number of cached images rather than the exact memory size.

FlutterView Memory Exploration

When integrating Flutter into an existing Android app, developers can either create a new FlutterView for each Activity or reuse a single view across activities. Reusing saves native memory (≈0.08 MiB per page) but adds complexity such as handling activity‑level references to avoid leaks.

Memory impact of the two approaches (average per empty page):

• Not reusing: Java +0.02 MiB, Native +0.73 MiB • Reusing: Java +0.019 MiB, Native +0.65 MiB

Code snippet for attaching a FlutterView to an activity:

mNativeView.attachViewAndActivity(this, activity);

To mitigate the high first‑frame latency of a debug FlutterView, we can pre‑render the first frame in an off‑screen 1‑pixel window and remove it once rendering completes. The following code demonstrates this technique:

final WindowManager wm = mFakeActivity.getWindowManager();
final FrameLayout root = new FrameLayout(mFakeActivity);
FrameLayout.LayoutParams params = new FrameLayout.LayoutParams(1, 1);
root.addView(flutterView, params);
WindowManager.LayoutParams wlp = new WindowManager.LayoutParams();
wlp.width = 1;
wlp.height = 1;
wlp.flags |= WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE;
wlp.flags |= WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE;
wm.addView(root, wlp);
final FlutterView.FirstFrameListener[] listenerRef = new FlutterView.FirstFrameListener[1];
listenerRef[0] = new FlutterView.FirstFrameListener() {
    @Override
    public void onFirstFrame() {
        wm.removeView(root);
        flutterView.removeFirstFrameListener(listenerRef[0]);
    }
};
flutterView.addFirstFrameListener(listenerRef[0]);
String appBundlePath = FlutterMain.findAppBundlePath(mFakeActivity.getApplicationContext());
flutterView.runFromBundle(appBundlePath, null, "main", true);

These experiments, conducted by the Xianyu team, illustrate practical strategies for managing memory when using Flutter in Android applications and provide insights for developers seeking to balance performance, memory consumption, and architectural complexity.