How Alibaba Optimized Flutter Image Loading to Match Native Performance

Flutter was introduced to Alibaba.com International's mobile order review module in September last year and has since expanded to support orders, carts, and other transaction‑related screens, offering better development experience, higher efficiency, and improved platform consistency compared with native development.

However, new challenges such as page routing, stack management, and memory usage emerged.

In the first half of the year, Alibaba.com mobile optimized image loading across the global chain with techniques like adaptive compression, WebP, multi‑level caching, domain convergence, and HTTP/2 upgrades. Unlike Weex, which can bridge directly to native APIs, Flutter uses its own rendering engine and image loading API, requiring a strategy to keep Flutter's image handling consistent with native optimizations.

Initial Solution

The team initially wrapped Flutter's NetworkImage to replicate native adaptive slots and WebP handling. Because Flutter only provides in‑memory caching without disk caching, each product image was re‑fetched, leading to inefficiency. The most effective approach was to bridge native image decoding via a MethodChannel, delivering the decoded image data as a Uint8List to Flutter's MemoryImage for display.

// ImageCdnHelper performs cropping and WebP conversion
String url = ImageCdnHelper.convertUrl(widget.imageUrl ?? '', width.toInt(), height.toInt());
// Flutter network image interface
ImageProvider image = NetworkImage(_url);
// Fade‑in animation to improve perceived loading speed
Widget build(BuildContext context) { return FadeInImage(key: key, height: height, width: width, image: image); }

Ongoing Optimization – MethodChannel

MethodChannel is Flutter's built‑in mechanism for communicating with native code. Flutter initiates the call, native code processes the image download and decoding, then returns the data as a Uint8List. Flutter can then use MemoryImage to render the image without an additional cache layer.

class MemoryImage extends ImageProvider<MemoryImage> {
  /// Creates an object that decodes a [Uint8List] buffer as an image.
  const MemoryImage(this.bytes, {this.scale = 1.0})
      : assert(bytes != null),
        assert(scale != null);

  /// The bytes to decode into an image.
  final Uint8List bytes;

  /// The scale to place in the [ImageInfo] object of the image.
  final double scale;
}

This method, however, can cause high memory usage because both native and Flutter maintain separate in‑memory caches, potentially leading to OOM situations.

Solution 2: PlatformView

PlatformView allows embedding native Android/iOS views inside Flutter. Tests showed severe frame drops and poor usability, especially in long lists, and size handling issues because the native view's frame cannot be directly passed to Flutter.

Solution 3: Texture Widget + PixelBuffer

The team explored using a texture widget combined with a pixel buffer. Native code runs a CADisplayLink synchronized with the screen refresh, captures each video frame as a PixelBuffer via AVPlayerItemVideoOutput, and sends it to Flutter through an EventChannel. The same concept can be applied to images, treating them as single‑frame video.

Key implementation details include setting kCVPixelBufferIOSurfacePropertiesKey to share memory between CPU and GPU, and using kCVPixelFormatType_32BGRA for the pixel format.

// Core code to convert UIImage to CVImageBufferRef (illustrative)
// Ensure kCVPixelBufferIOSurfacePropertiesKey is set for shared memory
// Set pixel format to kCVPixelFormatType_32BGRA

Since Flutter's Texture widget lacks a BoxFit property, a FittedBox wrapper is required to control the image's content mode.

Conclusion

Even with the third solution, creating a pixel buffer each frame incurs CPU work, so effective caching and timely release of pixel buffers are essential to avoid memory spikes. After optimization, memory consumption and CPU usage are comparable to Flutter's native APIs.