Flutter 圖片庫高燃新登場

背景

去年，閒魚圖片庫在大規模的應用下取得了不錯的成績，但也遇到了一些問題和訴求，需要進一步的演進，以適應更多的業務場景與最新的 flutter 特性。比如，因為完全拋棄了原生的 ImageCache，在與原生圖片混用的場景下，會讓一些低頻的圖片反而佔用了快取；比如，我們在模擬器上無法展示圖片；比如我們在相簿中，需要在圖片庫之外再搭建圖片通道。

這次，我們巧妙地將外接紋理與 FFi 方案組合，以更貼近原生的設計，解決了一系列業務痛點。沒錯，Power 系列將新增一員，我們將新的圖片庫命名為 「PowerImage」！

我們將新增以下核心能力：

• 支援載入 ui.Image 能力。在去年基於外接紋理的方案中，使用方無法拿到真正的  ui.Image 去使用，這導致圖片庫在這種特殊的使用場景下無能為力。

• 支援圖片預載入能力。正如原生 precacheImage 一樣。這在某些對圖片展示速度要求較高的場景下非常有用。

• 新增紋理快取，與原生圖片庫快取打通！統一圖片快取，避免原生圖片混用帶來的記憶體問題。

• 支援模擬器。在  flutter-1.23.0-18.1.pre 之前的版本，模擬器無法展示  Texture Widget 。

• 完善自定義圖片型別通道。解決業務自定義圖片獲取訴求。

• 完善的異常捕獲與收集。

• 支援動圖。

去年圖片方案可以參考 《閒魚Flutter圖片框架架構演進（超詳細）》 。

Flutter 原生方案

在我們新方案開始之前，先簡單回憶一下 flutter 原生圖片方案。

原生 Image Widget 先通過 ImageProvider 得到 ImageStream，通過監聽它的狀態，進行各種狀態的展示。比如 frameBuilder 、 loadingBuilder ，最終在圖片載入成功後，會  rebuild  出  RawImage ， RawImage  會通過  RenderImage  來繪製，整個繪製的核心是  ImageInfo  中的  ui.Image 。

• Image：負責圖片載入的各個狀態的展示，如載入中、失敗、載入成功展示圖片等。

• ImageProvider：負責 ImageStream 的獲取，比如系統內建的 NetworkImage、AssetImage 等。
  

• ImageStream：圖片資源載入的物件。

在梳理 flutter 原生圖片方案之後，我們發現是不是有機會在某個環節將 flutter 圖片和 native 以原生的方式打通？

新的方案

我們巧妙地將 FFi 方案與外接紋理方案組合，解決了一系列業務痛點。

FFI

正如開頭說的那些問題，Texture 方案有些做不到的事情，這需要其他方案來互補，這其中核心需要的就是  ui.Image 。我們把 native 記憶體地址、長度等資訊傳遞給 flutter 側，用於生成  ui.Image 。

首先 native 側先獲取必要的引數（以 iOS 為例）：

_rowBytes = CGImageGetBytesPerRow(cgImage);

    CGDataProviderRef dataProvider = CGImageGetDataProvider(cgImage);
    CFDataRef rawDataRef = CGDataProviderCopyData(dataProvider);
    _handle = (long)CFDataGetBytePtr(rawDataRef);

    NSData *data = CFBridgingRelease(rawDataRef);
    self.data = data;
    _length = data.length;

dart 側拿到後

@override
  FutureOr<ImageInfo> createImageInfo(Map map) {
    Completer<ImageInfo> completer = Completer<ImageInfo>();
    int handle = map['handle'];
    int length = map['length'];
    int width = map['width'];
    int height = map['height'];
    int rowBytes = map['rowBytes'];
    ui.PixelFormat pixelFormat =
        ui.PixelFormat.values[map['flutterPixelFormat'] ?? 0];
    Pointer<Uint8> pointer = Pointer<Uint8>.fromAddress(handle);
    Uint8List pixels = pointer.asTypedList(length);
    ui.decodeImageFromPixels(pixels, width, height, pixelFormat,
        (ui.Image image) {
      ImageInfo imageInfo = ImageInfo(image: image);
      completer.complete(imageInfo);
      //釋放 native 記憶體
      PowerImageLoader.instance.releaseImageRequest(options);
    }, rowBytes: rowBytes);
    return completer.future;
  }

我們可以通過 ffi 拿到 native 記憶體，從而生成 ui.Image。這裡有個問題，雖然通過 ffi 能直接獲取 native 記憶體，但是由於  decodeImageFromPixels  會有記憶體拷貝，在拷貝解碼後的圖片資料時，記憶體峰值會更加嚴重。

這裡有兩個優化方向：

• 解碼前的圖片資料給 flutter，由 flutter 提供的解碼器解碼，從而削減記憶體拷貝峰值。

• 與 flutter 官方討論，嘗試從內部減少這次記憶體拷貝。

FFI 這種方式適合輕度使用、特殊場景使用，支援這種方式可以解決無法獲取 ui.Image 的問題，也可以在模擬器上展示圖片（flutter <= 1.23.0-18.1.pre），並且圖片快取將完全交給 ImageCache 管理。

Texture

Texture 方案與原生結合有一些難度，這裡涉及到沒有  ui.Image  只有 textureId。這裡有幾個問題需要解決：

問題一：Image Widget 需要  ui.Image  去 build  RawImage  從而繪製，這在本文前面的Flutter 原生方案介紹中也提到了。

問題二：ImageCache 依賴 ImageInfo 中  ui.Image  的寬高進行 cache 大小計算以及快取前的校驗。

問題三：native 側 texture 生命週期管理

都有解決方案：

問題一：通過自定義 Image 解決，透出 imageBuilder 來讓外部自定義圖片 widget

問題二：為 Texture 自定義  ui.image ，如下：

import 'dart:typed_data';
import 'dart:ui' as ui show Image;
import 'dart:ui';

class TextureImage implements ui.Image {
  int _width;
  int _height;
  int textureId;
  TextureImage(this.textureId, int width, int height)
      : _width = width,
        _height = height;

  @override
  void dispose() {
    // TODO: implement dispose
  }

  @override
  int get height => _height;

  @override
  Future<ByteData> toByteData(
      {ImageByteFormat format = ImageByteFormat.rawRgba}) {
    // TODO: implement toByteData
    throw UnimplementedError();
  }

  @override
  int get width => _width;
}

這樣的話，TextureImage 實際上就是個殼，僅僅用來計算 cache 大小。實際上，ImageCache 計算大小，完全沒必要直接接觸到 ui.Image，可以直接找 ImageInfo 取，這樣的話就沒有這個問題了。這個問題可以具體看 @皓黯 的  ISSUE ^[1] 與  PR ^[2] 。

問題三：關於 native 側感知 flutter image 釋放時機的問題

• flutter 在 2.2.0 之後，ImageCache 提供了釋放時機，可以直接複用，無需修改。

• < 2.2.0 版本，需要修改 ImageCache，獲取 cache 被丟棄的時機，在 cache 被丟棄的時候，通知 native 進行釋放。

修改的 ImageCache 釋放如下(部分程式碼)：

typedef void HasRemovedCallback(dynamic key, dynamic value);

class RemoveAwareMap<K, V> implements Map<K, V> {
  HasRemovedCallback hasRemovedCallback;
  ...
}
//------
  final RemoveAwareMap<Object, _PendingImage> _pendingImages = RemoveAwareMap<Object, _PendingImage>();
//------
void hasImageRemovedCallback(dynamic key, dynamic value) {
    if (key is ImageProviderExt) {
      waitingToBeCheckedKeys.add(key);
    }
    if (isScheduledImageStatusCheck) return;
    isScheduledImageStatusCheck = true;
    //We should do check in MicroTask to avoid if image is remove and add right away
    scheduleMicrotask(() {
      waitingToBeCheckedKeys.forEach((key) {
        if (!_pendingImages.containsKey(key) &&
            !_cache.containsKey(key) &&
            !_liveImages.containsKey(key)) {
          if (key is ImageProviderExt) {
            key.dispose();
          }
        }
      });
      waitingToBeCheckedKeys.clear();
      isScheduledImageStatusCheck = false;
    });
  }

整體架構

我們將兩種解決方案非常優雅地結合在了一起：

我們抽象出了 PowerImageProvider ，對於 external（ffi）、texture，分別生產自己的 ImageInfo 即可。 它將通過對 PowerImageLoader 的呼叫，提供統一的載入與釋放能力。

藍色實線的 ImageExt 即為自定義的 Image Widget，為 texture 方式透出了 imageBuilder。

藍色虛線 ImageCacheExt 即為 ImageCache 的擴充套件，僅在 flutter < 2.2.0 版本才需要，它將提供 ImageCache 釋放時機的回撥。

這次，我們也設計了超強的擴充套件能力。除了支援網路圖、本地圖、flutter 資源、native 資源外，我們提供了自定義圖片型別的通道，flutter 可以傳遞任何自定義的引數組合給 native，只要 native 註冊對應型別 loader，比如「相簿」這種場景，使用方可以自定義 imageType 為 album ，native 使用自己的邏輯進行載入圖片。有了這個自定義通道，甚至圖片濾鏡都可以使用 PowerImage 進行展示重新整理。

除了圖片型別的擴充套件，渲染型別也可進行自定義。比如在上面 ffi 中說的，為了降低記憶體拷貝帶來的峰值問題，使用方可以在 flutter 側進行解碼，當然這需要 native 圖片庫提供解碼前的資料。

資料對比

FFI vs Texture：

機型：iPhone 11 Pro，圖片：300 張網路圖，行為：在listView中手動滾動到底部再滾動到頂部，native Cache：100MB，flutter Cache：100MB

這裡有兩個現象：

Texture：395MB波動，記憶體較平滑
FFI：480MB波動，記憶體有毛刺

Texture 方案在記憶體方面表現優於 FFI，在記憶體水位與毛刺兩方面：

• 記憶體水位：由於 Texture 方案在 flutter 側的 cache 為佔位空殼，沒有實際佔用記憶體，因此只在 native 圖片庫的記憶體快取中存在一份，所以 flutter 側記憶體快取實際上比 ffi 方案少了 100MB

• 毛刺：由於 ffi 方案不能避免 flutter 側記憶體拷貝，會有先拷貝再釋放的過程，所以會有毛刺。

結論：

1. Texture 適用於日常場景，優先選擇；

2. FFI 更適用於

1. flutter <= 1.23.0-18.1.pre 版本中，在模擬器上顯示圖片

2. 獲取 ui.Image 圖片資料

3. flutter 側解碼，解碼前的資料拷貝影響較小。（比如集團 Hummer 的外接解碼庫）

滾動流暢性分析：

裝置: Android OnePlus 8t，CPU和GPU進行了鎖頻。
case: GridView每行4張圖片，300張圖片，從上往下，再從下往上，滑動幅度從500，1000，1500，2000，2500，5輪滑動。重複20次。
方式: for i in {1..20}; do flutter drive --target=test_driver/app.dart --profile; done 跑資料，獲取TimeLine資料並分析。

結論：

• UI thread 耗時 texture 方式最好，PowerImage 略好於 IFImage，FFI方式波動比較大。

• Raster thread 耗時 PowerImage 好於 IFImage。Origin 原生方式好是因為對圖片 resize了，其他方式載入的是原圖。

更精簡的程式碼：

dart 側程式碼有較大幅度的減少，這歸功於技術方案貼合 flutter 原生設計，我們與原生圖片共用較多程式碼。

FFI 方案補全了外接紋理的不足，遵循原生 Image 的設計規範，不僅讓我們享受到 ImageCache 帶來的統一管理，也帶來了更精簡的程式碼。

未來

相信很多人注意到了，上文中少了動圖部分。當前動圖部分正在開發中，內部的 Pre Release 版本中，在 load 的時候返回的實際上是  OneFrameImageStreamCompleter ，對於動圖，我們將替換為  MultiFrameImageStreamCompleter ，後面如何做，只是一些策略問題，並不難。順便拋個另一種方案：可以把動圖解碼前的資料給 flutter 側解碼與渲染，但支援的格式不如原生豐富。

我們希望能將 PowerImage 貢獻給社群，為了實現這一目標，我們提供了詳細的設計文件、接入文件、效能報告，另外我們也在完善單元測試，在程式碼提交後或者 CR 時，都會進行單元測試。

最後，也是大家最關心的：我們計劃在今年十二月底將程式碼開源在 「 XianyuTech ^[3] 」。

References