聊聊动效降级

当前位置:

首页 > 网站开发 > JavaScript >

聊聊动效降级

前言

在日常开发中，经常会碰到包含有大量动效的需求。当一个页面包含有大量动效时，经常会出现卡顿、性能不佳的问题。

正所谓开发三天，优化两星期，为了优化这些动效，很多同学只能一点点抠代码，探寻加载时间点、渲染速度、资源体积等优化点的极限，前端、设计以及测试都疲于奔命。

古语有云，因材施教，话句话说，给合适的人，合适的东西。套用在开发中，可以理解为，为不同用户提供不同的产品效果以提升用户体验。

在动效开发上运用这一点，最后得到的方案就是动效降级。

简介

一句话概括动效降级，即根据机型性能对不同机型进行分级，不同级别提供不同动效。

举个例子，面对高中低端机型，从高到低可以分别提供：视频动画、Lottie 动画以及 CSS 动画。

个人认为，针对中低端机型，更重要的是让用户流畅地体验功能，而不是执着于华丽的效果。

方案设计

机型划分

动效降级的核心在于为合适的机型提供合适的动效，所以，动效降级的第一步是根据规则对不同机型划分不同级别。

IOS 的机型划分相对简单，只需依据机型判断即可，如 iphone6 以下为低端机，iphone8 以下为中端机。

Android 的机型、系统繁多，一个个判断明显不可行，所以需要机型打分平台对 Android 机型进行打分，最终使用评分划分机型级别。

除此之外，还需要维护一个机型黑名单，黑名单主要包括硬件尚可，但是实际显示效果不佳的机型。当命中黑名单时，可以直接降级。

注意，分为高中低三种机型只是一种比较常见的做法，但不是唯一的做法，在实践中，将所有机型分为两种、四种甚至五种级别都是可以的，根据项目自行划分即可。

规则获取

确定完机型规则后，我们还需要获取规则。此时，有两种处理方案：规则写在代码中或服务端下发。

规则写在代码中相对更加简单，性能相对较好（因为省略了请求规则的过程），但是维护不便。

服务端下发方案则刚好相反，易于维护但是性能相对差一些。

如何取舍可以看具体需求。

降级策略

动效降级的策略可以根据不同项目不同背景自行制定，总体来说，按照越高级的机型使用越消耗性能的动效。

举个栗子：

在活动页首页有一个视频动画，针对高端机型保持不变，而中端机型可以使用 Lottie / Canvas 动画，最后的低端机型可以使用 CSS 动画或者 GIF 图片，在最极端情况下，甚至直接使用静态图片或者直接置为空。

TIPS：由于降级流程相对固定，所以可以封装组件，统一使用降级组件进行开发。

特殊场景处理

虽然从原则上来说，所有动效都需要进行动效降级，但是存在部分特殊场景需要特殊处理。

举个栗子：

有一个倒计时页面，使用了很绚丽视频动画，按照制定规则，需要降级为 Lottie 动画，但是产品经理要求降级为 CSS 动画，此时，就需要进行特殊处理。

由于动效场景变化较多，所以降级组件需要提供足够灵活的钩子和配置才能适应更多场景。

兜底处理

前面说的都是根据机型判断、场景判断主动使用动效降级。其实，进行兜底处理的时候，也可以被动使用动效降级。

举个栗子：

在某个高端机上，照理说应该播放视频动画，结果对应的 CDN 资源出问题了，无法拉取到视频动画资源，最终导致播放视频动画失败。此时，可以使用被动动效降级，自动将视频动画降级为 Lottie 动画。以此类推，高端动效降级为中端动效，中端动效降级为低端动效，最终效果是虽然出了 BUG，但是用户没有感知到 BUG。

这就是传说中的：用户都没有感知到 BUG，那就没有 BUG。