Flutter 新图片库 PowerImage 架构

//释放 native 内存

PowerImageLoader.instance.releaseImageRequest(options);

}, rowBytes: rowBytes);

return completer.future;

}

我们可以通过 ffi 拿到 native 内存，从而生成 ui.Image。这里有个问题，虽然通过 ffi 能直接获取 native 内存，但是由于 decodeImageFromPixels 会有内存拷贝，在拷贝解码后的图片数据时，内存峰值会更加严重。

这里有两个优化方向：

1. 解码前的图片数据给 flutter，由 flutter 提供的解码器解码，从而削减内存拷贝峰值。

2. 与 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 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 释放时机的问题

1. flutter 在 2.2.0 之后，ImageCache 提供了释放时机，可以直接复用，无需修改。

2. < 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 图片库提供解码前的数据。

数据对比

▐  Texture

机型：iPhone 11 Pro，图片：300 张网络图，行为：在listView中手动滚动到底部再滚动到顶部，native Cache：100MB，flutter Cache：100MB

这里有两个现象：

Texture：395MB波动，内存较平滑

FFI：480MB波动，内存有毛刺

Texture 方案在内存方面表现优于 FFI，在内存水位与毛刺两方面：

1. 内存水位：由于 Texture 方案在 flutter 侧的 cache 为占位空壳，没有实际占用内存，因此只在 native 图片库的内存缓存中存在一份，所以 flutter 侧内存缓存实际上比 ffi 方案少了 100MB

2. 毛刺：由于 ffi 方案不能避免 flutter 侧内存拷贝，会有先拷贝再释放的过程，所以会有毛刺。

结论：

1. Texture 适用于日常场景，优先选择；

2. FFI 更适用于

flutter <= 1.23.0-18.1.pre 版本中，在模拟器上显示图片

获取 ui.Image 图片数据

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数据并分析。

结论：

1. UI thread 耗时 texture 方式最好，PowerImage 略好于 IFImage，FFI方式波动比较大。

2. Raster thread 耗时 PowerImage 好于 IFImage。Origin 原生方式好是因为对图片 resize了，其他方式加载的是原图。

▐  更精简的代码

dart 侧代码有较大幅度的减少，这归功于技术方案贴合 flutter 原生设计，我们与原生图片共用较多代码。

FFI 方案补全了外接纹理的不足，遵循原生 Image 的设计规范，不仅让我们享受到 ImageCache 带来的统一管理，也带来了更精简的代码。

数据对比

相信很多人注意到了，上文中少了动图部分。当前动图部分正在开发中，内部的 Pre Release 版本中，在 load 的时候返回的实际上是 OneFrameImageStreamCompleter，对于动图，我们将替换为 MultiFrameImageStreamCompleter，后面如何做，只是一些策略问题，并不难。顺便抛个另一种方案：可以把动图解码前的数据给 flutter 侧解码与渲染，但支持的格式不如原生丰富。

我们希望能将 PowerImage 贡献给社区，为了实现这一目标，我们提供了详细的设计文档、接入文档、性能报告，另外我们也在完善单元测试，在代码提交后或者 CR 时，都会进行单元测试。

最后，也是大家最关心的：我们计划在今年十二月底将代码开源在「XianyuTech[3]」。

References

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

总结

Android架构学习进阶是一条漫长而艰苦的道路，不能靠一时激情，更不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。所以：贵在坚持！

上面分享的字节跳动公司2021年的面试真题解析大全，笔者还把一线互联网企业主流面试技术要点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。

【Android高级架构视频学习资源】

Android部分精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

，笔者还把一线互联网企业主流面试技术要点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节。
[外链图片转存中…(img-z9HYk0cl-1712262568888)]

【Android高级架构视频学习资源】

Android部分精讲视频领取学习后更加是如虎添翼！进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水，赶快领取吧！

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！