开发者聊 Kami 的设计与交互（动效设计）

不知不觉，Kami 已经迭代开发了两个多年头，经历了多次重构和 UI 上的修改。代码量也上了 15K+，经历了 1K+ 次的提交。有人可能会问，为什么一个个人站会有如此庞大的 Codebase，不就一个博客站吗，最多也就几千行差不多了。我想来说说 Kami 内在的东西，从动效的细节开始。

追看最早的版本，还是一个直接复制 Paul 的 CSS 样式的移植风格。为了快速成型整个样貌，使用了 Antd UI 库，但是 UI 上并不是很搭。之后为了更加统一风格移除了 Antd，组件全部重写。如今（v3.10.6），通用组件（不与业务耦合）已有 36 个。C 端组件，主要兼顾视觉和交互。而 B 端组件注重功能。

前几天，我更新了对 Kami 的定义，这是一个注重 Colorful（多彩的）、Flat（扁平化）、Cute（可爱）、Comfortable（舒适的）。

接下来，围绕上方，说说一些设计的细节和交互体验。

动效

从始至终，我都觉得 iOS 的动效是最舒服的。总是有人会用非线性动画说事，尤其在国内各场发布会上一次又一次的错误灌输。其实，只是因为 iOS 的动画曲线符合自然的物理规律。在自然界，任何碰撞都会触发弹性形变，弹性曲线是非常舒适的，iOS 中应用了大量弹性动画（Spring）。当然弹性动画也是非线性的一种。可以看看ios的弹性、惯性和动画曲线。

在 React 生态中，著名开源动画库 React Spring 应用了这一点，用它可以做出媲美iOS 的交互体验。美中不足的是，这个库太重了，构建产物太大在 C 端诟病。由于已经使用了 React 生态 + MobX + Socket.IO 这几个大家伙，所以不考虑再引入庞然大物了。最后找到了一个 css-spring 库，通过动态生成 CSS3 Keyframes 创造弹性动画。为什么说动态生成，因为用 CSS3 动画去模拟弹性需要太多的动画帧，参考如下。

通过封装，实现了一个弹性过度布局。在整个站点内随处可见。甚至，锚点（BackToTop & Toc）的滚动也是弹性的。我非常喜欢弹性动画，因为它看起来让人很舒服。具体体验还请多多留意随处可见的动效。

好了，今天就聊完了动效，下期再见。