SVGA 是一种使用简单、性能卓越的跨平台开源动画格式。它的出现，使原本复杂的动画开发流程分工明确，所有人都只需专注于自身领域，大大减少了动画交互的沟通成本。 # 典型的 SVGA 动画开发流程 * 动画设计师 1. 使用 AE、Animate(Flash) 等工具制作动画； 2. 使用 SVGAConverter 将动画源文件转换为 SVGA 文件； * 开发工程师 3. 根据不同平台的需要集成相应平台的 SVGAPlayer； 4. 调用 SVGAParser 从本地资源或远程服务器解析 SVGA 文件； 5. 将解析出的内容交给相应平台的 SVGAPlayer 播放。 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/7545e83ed88c463a8efadebdfea17f27~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1757648232&x-signature=DhimHGswUii6diaqpjTHARanHuc%3D) # SVGA 与 GIF、Lottie 孰优孰劣？ SVGA 文件的本质就是一个采用了 ProtoBuf + Zlib 方式打包的压缩文件，其最大的特点在于，创新性地将一个动画拆分成了以下两个部分： * **动画元素**：指的是动画过程中运用到的各种切图素材（包含位图、矢量图等）。 * **动画帧**：代表所有元素在某一时刻的位置、大小、旋转角度、透明度等信息。 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/9eb74534defc42a9b1ff2dce72383227~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1757648232&x-signature=tvdgv7gFblWCjhrpnEeSKmTJ71k%3D) ### 与 GIF 相比由于 GIF 的每一帧都是一张完整的图片，因此无论是文件大小，还是播放时占用的资源，都不太符合生产的要求，且由于 GIF 只支持 8 bit 的色深，实际的动画表现效果也不够理想。而 SVGA 所包含的动画元素是有限的，且在动画过程中也在不断复用，因而可以有效地降低文件大小和播放时占用的资源，且由于 PNG 格式的动画元素可以支持 32 bit 的色深，因而在动画表现效果上也更胜 GIF 一筹。 ### 与 Lottie 相比 Lottie 与 SVGA 其实是有点类似的，只不过它导出的内容是「动画元素」与「动画脚本」，它实际上是把完整的动画逻辑在相应平台上重新实现了一次。这也就意味着，如果遇上了较为复杂的动画效果，如需要进行一些高阶的插值运算（二次线性方程、贝塞尔曲线方程等）时，Lottie 同样会面临性能问题的困扰。而 SVGA 则是在导出动画时，把动画逻辑封装在了每一个动画帧的帧信息中，播放器只需读取帧信息，然后粗暴地把每一个动画元素，丝毫不差地渲染到屏幕上即可，无需进行任何的插值运算，从而提高了性能。 ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/45790d7aca534a83bc7a5a8b43e30e17~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1757648232&x-signature=GPFnbH551VVrYZeUzl%2FwLTe%2FzF8%3D) 所以我们才会说，“**SVGA 不关心关键帧，因为 SVGA 里面的每一帧都是关键帧**”。如果你还是无法理解二者的区别，我们可以用一个生活化的例子来进行类比。假设你想拍摄一部低成本的科幻片，有一幕是主角用念力驱使桌子上的一个杯子移动一段距离。毫无疑问，这一幕里的动画元素就是一个杯子、一张桌子和一个便秘表情的主角。如果用 Lottie 实现，就相当于你需要构思如何在不接触杯子的情况下让杯子移动。你可能需要在桌子底下安上一块磁铁，或者同时调整桌子角度和拍摄角度，你需要在拍摄脚本中写一遍，然后在实际拍摄中操作一遍。拍摄脚本就相当于 Lottie 的动画脚本，越复杂的场景拍摄方式就越困难。如果用 SVGA 实现，就相当于你只需要在桌子上每隔1厘米做上标记，这些标记就相当于 SVGA 的动画帧，记录着杯子在某一时刻的位置，然后我们只需要固定镜头角度，然后每移动杯子到下一个标记就拍摄一次，之后将所有镜头串联起来，即可实现相同的效果，非常简单粗暴。 # 现有 SVGA 使用场景存在的问题近年来，随着 VAP 等动画特效库的兴起，MP4 逐渐取代 SVGA 成为了直播间礼物的主流格式。只不过，凭借其自身独特的优势，SVGA 仍在小型动画（诸如头像框、声波特效等）领域保有一席之地。在对现有的 SVGA 使用场景展开了一轮考察之后，我们发现了以下几个颇为显著的问题： ## 问题1：内存占用高且长期驻留虽然 SVGA 支持动态绘制矢量图，然而在实际的应用中，动画设计师们更多地会使用提前做好的位图来制作动画，且往往会出于对动画效果的极致追求，在动画中使用了大量的位图素材。诸如此类的原因，最终致使 SVGA 成为了仅次于 MP4 礼物的内存消耗大户，而且相较于仅播放 1 次的 MP4 礼物，某些 SVGA 是需要重复播放的（如头像框），这就导致只要页面不销毁，SVGA 就会长期驻留在内存当中。 ## 问题2：不同尺寸适配成本较大同一个 SVGA 可能会以不同的尺寸展示于多个地方（如特效商品的预览与正常展示），如果要求生成不同的尺寸，一来会增加动效制作人员的工作量，二来也会增大包体大小或磁盘缓存大小；而如果仅产出单一的尺寸，在小尺寸的控件上使用大尺寸的 SVGA 显然性价比不高。 ## 问题3：前期规范缺失难以修正某些项目的前期没有为 SVGA 制定产出规范，导致某些 SVGA 的素材资源不符合要求，全部进行修改的话成本过高，并且某些 SVGA 资源出于成本与效率的考量，采用了外部购买的方式，规范也难以覆盖。 # SVGA 总内存占用估算方式 SVGA 内存占用的主要来源还是其动画过程中使用到的各种切图素材，因此，可以通过单独计算并汇总其中每个切图素材的内存占用，来估算 SVGA 的总内存占用。 Android/iOS/Flutter 默认都是以 32 bit 的色深解码图片，1 byte = 8 bit，因此每个切图素材的内存占用的计算公式为：图片分辨率 \* 4 bytes。按照这个计算方法得出的 SVGA 总内存占用，与其在 SVGA 官网预览时所得到的内存占用数值是一致的：内存占用：2.7479171752929688 MB Dian---{"width":30, "height":30, memoryUsage: 0.0034332275390625 MB} GuangHuan---{"width":169, "height":95, memoryUsage: 0.061244964599609375 MB} Ren01---{"width":174, "height":293, memoryUsage: 0.19448089599609375 MB} ShanGuang---{"width":154, "height":154, memoryUsage: 0.0904693603515625 MB} Shou01---{"width":125, "height":78, memoryUsage: 0.03719329833984375 MB} tou---{"width":126, "height":135, memoryUsage: 0.06488800048828125 MB} ... ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/e4714b7869f7489b98af4c78d71e016c~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1757648232&x-signature=oPifIG%2FOLvAxX%2B6WhQXfJr4w3lI%3D) 有了 SVGA 动画实现原理作为支撑，也梳理出了现有 SVGA 使用场景问题，同时获知了 SVGA 内存计算方式，接下来我们便以 Flutter 平台为例，给出相应的内存优化方案，方案是通用的，其他平台均可借鉴其思路。 # Flutter 是如何揪出尺寸过大的图片的？在 Flutter inspector 工具里有一个「高亮尺寸过大的图片」的选项，启用该选项之后，Flutter会**将尺寸过大的图片进行「垂直翻转」与「色调反转」：** *** ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/51f7f5d1def64bb7a220557a5c0a6f9a~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1757648232&x-signature=%2F9KxcHvUIKoTFrkam1ff5ZJTD9w%3D) *** ![](https://p6-xtjj-sign.byteimg.com/tos-cn-i-73owjymdk6/5d6cff064b8146e8be721154a3e02914~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAg5pif6ZmF56CB5LuU:q75.awebp?rk3s=f64ab15b&x-expires=1757648232&x-signature=SVN6TsLTykXjQ3EJxCJSJtZQEFQ%3D) *** **同时，在** **控制台中打印图片的「显示尺寸」、「解码尺寸」以及「额外内存消耗」**： dash.png has a display size of 213×392 but a decode size of 2130×392, which uses an additional 2542KB. dash.png 的显示尺寸为 213×392，但解码尺寸为 2130×392，这额外使用了 2542KB 。这部分逻辑的相关代码实现位于 decoration\_image.dart 源文件当中： /// 仅在 Debug 模式或 Profile 模式下执行 if (!kReleaseMode) { // 我们假设所有图像都针对具有最高设备像素比的视图进行解码，并将其用作图像显示尺寸的上限。 final double maxDevicePixelRatio = PaintingBinding.instance.platformDispatcher.views.fold( 0.0, (double previousValue, ui.FlutterView view) => math.max(previousValue, view.devicePixelRatio), ); final ImageSizeInfo sizeInfo = ImageSizeInfo( source: debugImageLabel ?? '', imageSize: Size(image.width.toDouble(), image.height.toDouble()), displaySize: outputSize * maxDevicePixelRatio, ); assert(() { /// 启用了「高亮尺寸过大的图片」选项 & 解码尺寸大于显示尺寸 if (debugInvertOversizedImages && sizeInfo.decodedSizeInBytes > sizeInfo.displaySizeInBytes + debugImageOverheadAllowance) { final int overheadInKilobytes = (sizeInfo.decodedSizeInBytes - sizeInfo.displaySizeInBytes) ~/ 1024; final int outputWidth = sizeInfo.displaySize.width.toInt(); final int outputHeight = sizeInfo.displaySize.height.toInt(); /// 打印显示尺寸 & 解码尺寸 & 额外内存消耗 FlutterError.reportError(FlutterErrorDetails( exception: 'Image $debugImageLabel has a display size of ' '$outputWidth×$outputHeight but a decode size of ' '${image.width}×${image.height}, which uses an additional ' '${overheadInKilobytes}KB (assuming a device pixel ratio of ' '$maxDevicePixelRatio).\n\n' 'Consider resizing the asset ahead of time, supplying a cacheWidth ' 'parameter of $outputWidth, a cacheHeight parameter of ' '$outputHeight, or using a ResizeImage.', library: 'painting library', context: ErrorDescription('while painting an image'), )); // 色调反转 canvas.saveLayer( destinationRect, Paint()..colorFilter = const ColorFilter.matrix([ -1, 0, 0, 0, 255, 0, -1, 0, 0, 255, 0, 0, -1, 0, 255, 0, 0, 0, 1, 0, ]), ); // 垂直翻转 final double dy = -(rect.top + rect.height / 2.0); canvas.translate(0.0, -dy); canvas.scale(1.0, -1.0); canvas.translate(0.0, dy); invertedCanvas = true; } return true; }()); } 这一类尺寸过大的图片会导致应用性能低下，在低端设备上这一情况尤为显著。而当列表中存在大量此类图片时，性能下降的影响还会叠加。 * 可能的情况下，最好的办法还是直接调整图片资源的大小，让它变得更小； * 如果调整困难，还有一种办法，那就是在构造 Image Widget 时传递参数「cacheHeight」、「cacheWidth」； * 这两个参数可以**让 Flutter 引擎按照指定的大小来解析图片，从而减少内存使用量；** * 只不过相较于直接缩小图像资源本身，解码和存储图像的开销仍然是相对比较昂贵的。我们从源码的角度来看一下「cacheHeight」与「cacheWidth」参数让 Image Widget 做了什么事情。 1. 当任一参数不为空时，Image 就会包装成 ResizeImage： static ImageProvider