Flutter 圖片庫高燃新登場

阿里巴巴移動技術發表於2022-03-23
Flutter

作者：王振輝(新宿)

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

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

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

  • 支援載入 ui.Image 能力。在去年基於外接紋理的方案中，使用方無法拿到真正的 ui.Image 去使用，這導致圖片庫在這種特殊的使用場景下無能為力；
  • 支援圖片預載入能力。正如原生precacheImage一樣。這在某些對圖片展示速度要求較高的場景下非常有用；
  • 新增紋理快取，與原生圖片庫快取打通！統一圖片快取，避免原生圖片混用帶來的記憶體問題；
  • 支援模擬器。在 flutter-1.23.0-18.1.pre之前的版本，模擬器無法展示 Texture Widget；
  • 完善自定義圖片型別通道。解決業務自定義圖片獲取訴求；
  • 完善的異常捕獲與收集；
  • 支援動圖。

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

這裡有兩個現象：

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

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

  • 記憶體水位：由於 Texture 方案在 flutter 側的 cache 為佔位空殼，沒有實際佔用記憶體，因此只在 native 圖片庫的記憶體快取中存在一份，所以 flutter 側記憶體快取實際上比 ffi 方案少了 100MB；
  • 毛刺：由於 ffi 方案不能避免 flutter 側記憶體拷貝，會有先拷貝再釋放的過程，所以會有毛刺。

結論：

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

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

b、獲取 ui.Image 圖片資料

c、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 時，都會進行單元測試。

References

[1] ISSUE: https://github.com/flutter/fl...\
[2] PR: https://github.com/flutter/fl...

關注【阿里巴巴移動技術】微信公眾號，每週 3 篇移動技術實踐&乾貨給你思考！

相關文章