关于flutter:Flutter-图片库高燃新登场

39次阅读

共计 6102 个字符，预计需要花费 16 分钟才能阅读完成。

作者：王振辉 (新宿)

去年，闲鱼图片库在大规模的利用下获得了不错的问题，但也遇到了一些问题和诉求，须要进一步的演进，以适应更多的业务场景与最新的 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 篇挪动技术实际 & 干货给你思考！

正文完
flutter
发表至： flutter
2022-03-17
 0
关于flutter:Flutter-移动安全-ー-Ep1-SSL-Pinning
关于flutter:开发经验Apple-M1开发Flutter报IPA-processing-failed
关于flutter:App复杂动画实现Rive保姆级教程-京东云技术团队
关于flutter:Dart-的编程语言之美-4-个超级特性