AliFlutter图片解决方案与优化

2021-08-15 23:10:00

Flutter与Native混合开发将是接下来很长时间的主流开发方式。一套稳定、高效、与官方体系无缝融合的外接图片缓存方案是必不可少的。在AliFlutter系列第三场直播中，由阿里巴巴新零售淘系技术部无线开发专家王乾元为大家介绍AliFlutter提供的适合混合应用的外接图片库方案。首先对Flutter官方原生方案进行了分析，并提出了AliFlutter方案的切入点以及具体优化手段。

演讲嘉宾简介：王乾元，花名神漠，13年加入阿里，先后负责过天猫、支付宝、手机淘宝App的iOS架构工作。目前在AliFlutter团队负责基础组件、iOS架构，以及引擎、工具链等方面的研究。
以下内容根据演讲视频以及PPT整理而成。
观看回放http://mudu.tv/watch/5624777

本次分享主要围绕以下三个方面：

            一、Flutter如何显示、加载图片  
            二、AliFlutter图片解决方案优化  
            三、如何选择最适图片解决方案

一、Flutter如何显示、加载图片

介绍Flutter如何加载、显示图片，以及在线程、缓存设计层面的特点。

线程

闲鱼分享的文章《深入理解Flutter引擎线程模式》中，详细讲解了Flutter引擎线程模型的原理以及作用。

Platform Thread：IOS与安卓平台层应用的主线程。进行Flutter Engine接口的调用，用户手势和输入等也通过Platform Thread输入给Flutter Engine。

UI Thread：Flutter的主线程，也称为Dart线程。同时可运行C++代码。

IO Thread：进行图片上传。图片在IO Thread进行异步上传生成GPU纹理.

GPU Thread：负责Flutter最终的GPU调用。
Worker Thread：Flutter中的fml会创建若干个并发工作线程。可进行图片解码等工作。

如上图所示，图片在Worker Thread完成解码，在IO Thread进行异步上传，在引擎启动时创建的ShellIOManager会创建OpenGL Context。同时GPU Thread创建GPU Context。IO Context与GPU Context将存放在Share Group*享纹理。Flutter中纹理对象是C++的对象，在Flutter底层不会对纹理对象进行任何缓存，而是通过Dart层的ui.Image对象通过引用计数进行管理。

图片加载、显示流程

下图为Flutter从图片加载到显示的相关类关系图，包括类所在文件。

图片加载用到Flutter的Image Widget，一般是使用其“.network”接口加载网络图片。Image Widget进行显示绘制时需要ImageState。ImageState有两个功能，一是驱动Provider下载图片，二是调用State管理底层Render object。Render object负责图片的渲染上屏。

NetworkImage(Provider)在自身resolve方法中异步调用http下载图片。resolve方法调用Provider获取自己的ImageStream。ImageStream会添加到StreamCompleter作为Listener。StreamCompleter可以添加多个ImageStream作为Listeners。图片下载完成后通过Dart层和C++层的接口函数instantiateImageCodec创建底层C++解码器的C++对象。解码器对象获取图片流后在底层进行异步解码，并生成纹理。ImageState接收到事件后获取纹理对象绘制图片。上层获取图片纹理后会调用ImageState的SetState方法将纹理对象传给底层Render object，排版完成后图片就会绘制到屏幕。

底层纹理对象会被上层Dart对象引用，具体为以下几个对象。StreamCompleter负责驱动底层解码器获取纹理对象。因此StreamCompleter会持有底层GPU纹理，并通过Listeners通知所有ImageState。因此ImageState也会持有纹理对象。ImageState将图片传给底层Render object，因此Render object也会持有纹理对象。当上层Image Widget被销毁，Image Cache清空时，触发底层纹理的释放。

Flutter加载显示图片的流程包括了图片的组件、下载、解码、上传、绘制等工作，看似复杂，但是其逻辑较为简单。

二、AliFlutter图片解决方案优化

问题

首先，利用Flutter制作淘宝商品详情页面，图片多，内存、CPU等占用非常高，性能要求高。Flutter图片管理能力较弱，缺乏本地缓存能力，图片的重复下载极易造成内存飙高，易发生OOM（OutOfMemory）情况。因此Flutter原生方案无法满足需求，需要构建适合的AliFlutter方案。

第二，电商APP需要与Native图片库对接，共享缓存、CDN能力以及监控设施。

第三，在使用简单的基础上，AliFlutter需要基于Flutter的强大扩展能力，支持小程序、Canvas等多种场景。

第四，希望AliFlutter与官方Flutter体系尽可能兼容与融合。

AliFlutter图片解决方案总体架构

下图红色标签为AliFlutter方案的重点。在Dart层实现了新的Provider，在C++层实现了新的解码器对象，并基于Flutter规范提供了不同平台的ObjC、安卓的Java接口。

AliFlutter图片解决方案追求以下三个特点。

一致性：与官方体系无缝融合。仅在官方基础上添加代码。
高性能：优化CPU、内存占用，增强List回收能力。
易用性：适配简单、使用简单、易扩展。

AliFlutter：如下图所示，高亮部分为AliFlutter改进部分。
Image Widget添加了新类型的Provider，ExternalAdapterImage。新Provider接收的参数是URL、图片尺寸信息等。可将参数通过Adapter传给Native图片库，进行图片下载或从缓存中加载。Completer会创建新的解码器对象，通过Adapter对接Native图片库，让Native图片库提供图片的原始Buffer，并进行解码。即不依赖Flutter的图片解码能力，而是依赖平台层例如IOS和安卓原生的图片解码能力，可支持更多图片格式。将平台层解码后的bitmap返回给解码器对象，通过位图数据进行图片纹理的上传。AliFlutter解码器底层的C++对象支持这两种工作模式。

一次完整图片加载过程时序图：首先从Image Widget拿到图片请求URL，调用到底层解码器对象的getNextFrame方法会将请求异步上传给对接的Native图片库。由Native图片库做请求，获取平台层的图片对象或Buffer，将图片对象返回给解码器对象。解码器对象在Worker Thread中进行图片解码。图片解码完成后在IO Thread进行图片的GPU纹理上传。上传完成后在UI Thread将图片返回给Dart。上述流程完成一次图片加载，线程模型与Flutter原生保持一致。
图片取消：AliFlutter方案相比Flutter原生方案新增了Cancel能力。Widget通过State将自己添加到Completer的Listeners中。因此Widget销毁时会将自己从Listeners中移除。当Completer的Listeners全部清空时，表示这次图片请求已经不再需要了，调用底层解码器对象的cancel方法。如果图片还未从Native图片库返回，可以取消下载；如果已经返回，还有解码或上传GPU过程，都可以及时取消操作。Cancel能力可以避免许多无用的CPU和内存的消耗，尤其是电商App中常见的快速滑动商品列表的场景。

性能优化

AliFlutter进行了以下层面的优化，除图片取消外，还包括延迟加载、解码并发控制、GIF逐帧上传纹理、增强List回收能力等。

适配与使用：介绍AliFlutter图片方案最终对接到平台层Native图片库的接口。

Flutter的封装是在IOS平台公开了Objective-C接口，在安卓平台提供了Java接口，因此AliFlutter遵循Flutter规范提供了OC接口与Java接口。

IOS平台OC接口只需要实现一个回调。OC回调在对接图片库时接收的是URL以及一些参数，获取图片后向底层返回UIImage即可。使用时可以直接调用Dart的Image.externalAdapter方法加载一张图片。在此可以指定placeholderProvider，可以是AssetImage或其他网络图片，以此可在主图加载失败时加载一张副图。

增强List回收能力

优化前后对比：下图左侧所示为使用Flutter制作的淘宝商品详情页面，其中有多个Cell。其中一个Cell为宝贝详情。宝贝详情Cell最初的实现方式是解析一段HTML。商家有时会上传多张高清大图，若此时将连续的图文详情放在一个Cell中，用户浏览详情页时会同时加载多张大图。另外Flutter默认对所有Cell添加RepaintBoundary属性，该属性默认将Cell中所有内容绘制到一个纹理中，下次浏览时若Cell中内容不变，直接使用纹理绘制图片会比较快速。因此易导致内存飙高问题。

如下图所示，优化前内存容易暴增到600+MB甚至1G，几乎100%会出现OOM问题。在业务代码不进行修改的情况下，优化后的内存增长变得较为平缓。

Flutter List特点：Flutter List回收以Cell为单位。下图所示红色框部分为屏幕大小。默认情况下Flutter默认对所有Cell添加RepaintBoundary。当列表滚动时，若Cell 1绘制过，下次绘制时直接将及纹理上屏即可，无需绘制内部图文元素。而Cell 2会占用大量内存，首先其图文多，同时RepaintBoundary形成的纹理也会占用大量内存。

因此增强List回收能力首先需要解除对部分Cell的RepaintBoundary设置。

优化流程：假设一个Image Widget在一个Cell中，正常情况下当Cell出现，Image Widget也会被创建并且请求图片。List回收能力的优化中试图解除此约定，根据图片是否在屏来判断是否需要图片纹理。若不需要，则释放，若需要，进行请求。

Image Widget的宽、高已知情况下，其排版信息是有效的。SetState完成后触发底层Render Object排版与绘制。在绘制图片过程中添加一段逻辑判断图片是否在屏。若图片不在屏，不作任何处理。若图片在屏幕中，进行图片请求获取真实图片后重复调用SetState，重新进行图片排版和绘制，并判断是否在屏。若图片随着列表滚动不在屏幕中，则回调通知上层解除纹理引用。
若Image Widget的宽、高未知，Flutter只能在获取图片后根据其真实尺寸进行排版。原本底层解码器对象持有getNextFrame接口，该接口导致GPU纹理的生成。在优化后可以不依赖图片纹理上传完成再进行排版。在流程中添加了Request Size接口，Image Widget的宽、高未知时调用该接口可以预先通知底层C++解码器获取图片尺寸。得到图片尺寸后再从SetState开始流程，避免了无效的纹理上传。

关键代码：判断图片是否在屏是通过Dart层的Image Render Object。其paint方法中进行图片是否在屏的判断，根据其是否在屏向上层ImageState发送回调通知。
实现指定Cell不添加RepaintBoundary是通过建立虚类NoRepaintBoundaryHint。若List检测到上层某个Cell继承自NoRepaintBoundaryHint，则不给该Cell添加RepaintBoundary。因此可以在每次屏幕滚动时重新进行绘制，了解图片的在屏、离屏信息。