闲鱼Flutter图片框架架构演进（超详细）

那些年

早在闲鱼使用Flutter之初，图片就是我们核心关注和重点优化的功能。图片展示体验的好坏会对闲鱼用户的使用体验产生巨大影响。你们是否也曾遇到过：

• 图片加载内存占用过多？

• 使用Flutter以后本地资源重复，利用率不高？

• 混合方案下Flutter原生图片加载效率不高？

针对上述问题，从第一版Flutter业务上线开始，闲鱼对图片框架的优化就从未停止。从开始的原生优化，到后面黑科技的外接纹理；从内存占用，到包大小；文本会逐一介绍。希望其中的优化思路和手段，能给大家带去一些启发。

原生模式

从技术层面看图片加载，其实简单来说，追求的是无非是加载的效率的最大化—用尽可能小的资源成本，尽可能快地加载尽可能多的图片。

闲鱼图片的第一个版本其实基本上是纯原生的方案。如果你不想魔改很多底层的逻辑，原生方案肯定是最简单和经济的方案。原生方案的功能模块如下：

如果你啥都没做直接上了，那么你可能会发现效果并没有达到你预期的那么美好。那么如果从原生的方案入手，我们有哪些具体的优化手段呢？

设置图片缓存

没错猜对了，是缓存。对于图片加载，最能想到的方案就是使用缓存。首先原生Image的组件是支持自定义图片缓存的，具体的实现类是ImageCache。ImageCache的设置维度是两个方向：1.缓存图片的张数。通过maximumSize设置。默认是1000张。2. 缓存空间的大小。通过maximumSizeBytes 来设置。默认值100M。相比张数的限制，其实大小的设置方式更加符合我们的最终的预期。

通过合理设置ImageCache的大小，能充分利用缓存机制加速图片加载。不仅如此，闲鱼在这个点上还做了额外两个重要优化：

• 低端手机适配

在上线以后，我们陆续收到线上舆情的反馈，发现全部机型设置同一个缓存大小的做法并非最优。特别是大缓存设置在低端机器上面，不仅会出现体验变差，甚至还会影响稳定性。基于实际情况，我们实现了一个能从Native侧获取机器基础信息的Flutter 插件。通过获取的信息，我们根据不同手机的配置设置不同的缓存策略。在低端机器上面适当降低图片缓存的大小，同时在高端手机上将其适当放大。这样能在不同配置的手机上获取最优的缓存性能。

• 磁盘缓存

熟悉APP开发的同学都知道，成熟的图片加载框架一般都有多级缓存。除了常见的内存缓存，一般都会配置一个文件缓存。从加载效率上来说，是通过空间换时间，提升加载速度。从稳定性来说，这又不会过分占用宝贵的内存资源，出现OOM。但是可惜的是，Flutter自带的图片加载框架并没有独立的磁盘缓存。所以我们在原生方案的基础上扩展了磁盘缓存能力。

在具体的架构实现上，我们并没有完全自己撸一个磁盘缓存。我们的策略还是复用现有能力。首先我们将Native图片加载框架的磁盘缓存的功能通过接口暴露出来。然后通过桥接的方式，将Native 磁盘缓存能力嫁接到Flutter层。Flutter侧进行图片加载的时候，如果内存没有命中，就去磁盘缓存中进行二次搜索。如果都没有命中才会走网络请求。

通过增加磁盘缓存，Flutter图片加载效率进一步提升。

设置CDN优化

CDN 优化是另一个非常重要图片优化手段。CDN优化的效率提升主要是：最小化传输图片的大小。常见策略包括：

• 根据显示大小裁剪

简单来说，你要加载图片的真实尺寸，可能会大于你实际