这类界面，通常商品列表展示的图片不一样并且用户也不会频繁进某一个特定的商详，所以更适合优先移除这部分的内存。
对于部分弹窗功能，图片显示后并不会再次使用，可以考虑不添加到内存中。
使用更好的图片格式
使用更好的图片格式通常可以带来更小的图片字节大小。同时因为压缩率的提高，可以在减少大小的同时提高图片质量。
提示：使用系统支持硬解码的图片格式更有优势。硬解码就是使用GPU进行解码，相比使用CPU软解码性能更好更省电。
APNG/动画WebP代替GIF- 按照Google官方的说法，GIF转换为有损WebP的字节数缩小了64％，而无损WebP字节数缩小了19％。所以使用动画WebP可以减少更多的网络流量传输。APNG是Mozilla推出的基于PNG的动图格式并且完全支持RGBA，相比GIF可以减少20%+的图片大小。而且GIF本身只支持256色索引颜色以及1位alpha(加上透明度后，边缘会出现明显的锯齿)，使用APNG/WebP也可以带来相比GIF更好的显示效果。
提示：相比GIF，WebP的解码比GIF占用更多的CPU资源。有损WebP的解码时间是GIF的2.2倍，而无损WebP的解码时间是GIF的1.5倍。
HEIC-HEIC是基于H.265视频编码格式推出的图片格式。HEIC相比WebP可以减少20%+的图片大小，并且编解码性能更好。在系统兼容性上，Android 9.0以上的系统支持HEIC。苹果在iOS14以上系统才提供了WebP硬解码，之前的系统只能使用软解码，而HEIC在iOS11之后的机器上都已经支持硬解码，不过并不支持浏览器。AVIF-AVIF是基于AV1编码格式推出的图片格式。AVIF相比WebP可以减少30%+的图片大小。不过目前只有Android 12以上的版本支持。
提示：这里主要是以VP8编码格式的WebP，VP9编码格式的WebP整体性能和HEIC差异不大。
不过这些图片格式需要图片服务器支持之后才能使用。
Flutter
虽然我们对Flutter图片库做了一些优化，但总体上还有很多优化空间。包括业界有在使用的基于纹理的图片方案。在原生侧将图片解码后，通过Flutter引擎创建纹理。之后讲图片纹理id传递给Flutter进行渲染。这样可以统一在原生侧管理图片内存缓存，优化之前Flutter和原生都分别有一份内存缓存的方式。而且针对于混合栈的导航栈方式，也可以更好的进行图片内存回收。另外针对Flutter，需要提供更灵活的图片内存回收策略，避免内存消耗过高。
提示：纹理可以复用内存中的位图缓存，所以并不会导致更多的内存占用。纹理方式大概能减少30%的内存消耗相比Flutter引擎图片库，主要是一些其他对象使用导致。
优化H5图片加载
我们可以通过拦截WebView图片加载的方式，让原生图片库来下载图片之后传递图片二进制数据给WebView显示。
减少流量消耗
通过这种方式，我们可以将原生图片库URL预处理相关功能支持到H5图片，减少H5加载过程中图片流量消耗，提高图片加载速度。同时因为APP原生和WebView图片缓存机制是相互独立的，所以通过统一在原生侧管理图片缓存，可以减少相同图片的重复下载。
支持更多图片格式
例如在iOS系统上，WKWebView目前只支持PNG/JPG/GIF图片格式。所以我们可以通过在原生端实现下载WebP/HEIC图片，之后对图片进行解码再传给WebView，这样就可以支持其他图片格式的显示。
提示：因为WebView不支持直接传递位图二进制数据显示，所以需要提前转换为PNG/JPG二进制数据传递。所以对于其他图片格式增加一次PNG/JPG编码过程会造成更多的性能消耗。不过对于Android系统应该可以在web内核层优化减少这块消耗。
总结
本文并没有讲底层图片加载库的具体实现，目前图片库不管是直接用第三方库还是自研图片库实现方式通常差异不大。我们更多是关注自身业务以及如何利用图片服务器能力最大化改善网络图片加载性能。所以部分策略可能不一定针对所有APP都合适，应该针对自身业务场景仔细评估优化方案。
扩展链接