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 與 PR。

問題三：關於 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 側內存拷貝，會有先拷貝再釋放的過程，所以會有毛刺。

結論：

Texture 適用於日常場景，優先選擇；
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」。

Flutter 圖片庫高燃新登場

背景

Flutter 原生方案

新的方案

FFI

Texture

整體架構

數據對比

FFI vs Texture：

滾動流暢性分析：

更精簡的代碼：

未來

認知提升的方法

螞蟻面試：Springcloud核心組件的底層原理，你知道多少？

Flutter Fish_Redux 3.0起航！序言 fish_redux 3.0.1 總結

Flutter PlatformView 在閒魚直播業務中的實踐

Flutter 圖片庫高燃新登場

Flutter難點問題之GPU後臺Crash

怎樣寫好Flutter代碼

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結