Understanding Flutter Image Loading, Caching, and Memory Optimization

With the continuous iteration of Flutter stable releases, the JD.com app has increasingly adopted Flutter, offering fast development, cross‑platform support, rich widgets, and near‑native performance, but it also faces OOM issues caused by loading many large images.

The basic usage of the Image widget requires an image parameter, which can be an asset, network, file, or memory source. For example, loading a network image looks like:

Image( image: NetworkImage("https://avatars2.githubusercontent.com/u/20411648?s=460&v=4"), width: 100.0, height: 100.0, )

The image loading flow in Flutter mirrors native image frameworks: generate a unique cache key from the source, check the cache, load and decode the image if missing, store it in the cache, and finally notify the widget to repaint.

During app startup, PaintingBinding creates a singleton ImageCache . The cache defaults to a maximum of 1,000 objects or 100 MB and uses a LinkedHashMap to implement an LRU‑like eviction policy via keys.first .

ImageProvider is the abstract source of image data, defining resolve , obtainKey , and load . Subclasses such as NetworkImage , AssetImage , FileImage , and MemoryImage implement these methods. resolve returns an ImageStream , while load returns an ImageStreamCompleter that produces ImageInfo objects.

For network images, NetworkImage creates a MultiFrameImageStreamCompleter . It downloads the bytes, decodes them via PaintingBinding.instance.instantiateImageCodec , and generates frames for static or animated images.

Rendering is handled by the widget’s state ( _ImageState ) which listens to the ImageStream . When an ImageInfo arrives, the state calls setState to update a RawImage (a RenderObjectWidget ). RenderImage then paints the image onto a Skia Canvas , applying transformations such as scaling, cropping, or nine‑patch drawing via drawImageNine and drawImageRect .

In summary, Flutter creates a global ImageCache in PaintingBinding , limits it to 100 MB, and manages entries with an LRU‑style algorithm. Images are fetched through ImageProvider , decoded by a codec, and delivered to the widget tree via ImageStream and ImageInfo .

Practical optimizations include manually evicting off‑screen images, using precacheImage() to preload assets, implementing disk caching by extending NetworkImage , customizing placeholders and error widgets via frameBuilder and errorBuilder , showing download progress, and configuring stretchable regions with the centerSlice property.

Future work will explore non‑intrusive memory‑sharing between native and Flutter image frameworks, external texture solutions, and continued refinements as the Flutter SDK evolves.