hi 大家好， 在最近的一年里我主要在做 antd-mobile 5.0 版本的开发，这是一个移动端组件库。今天，我们来聊一聊其中的一个组件——选择器 Picker，它的实现思路和技术选型。

这个小分享大概会包括以下几个部分：API 设计、手势和动画、性能、无障碍。

API 设计

让我们从 API 设计开始，先来定义一下 Picker 组件的属性。Picker 是一个数据录入型的组件，所以它需要 value onConfirm 这两个属性来和外界进行数据的交互。然后它还需要一个 columns 属性，用来配置 Picker 中每一列的选项列表。这里我们省略了一些属性，只保留了这几个最关键的。

需要注意的是，columns 属性是一个二维的数组，第一级对应的是选项列，第二级对应的是每一列中的选项列表。

定义好属性之后，我们来拆解一个这个组件的元素构成。

首先呢，我们在这里先放一个 Popup 组件，这是 antd-mobile 中的一个基础布局组件，我们可以直接用它来作为弹层的容器。然后我们往里面填充一些内容：我们在头部放两个操作按钮；在主内容区，根据 columns 属性渲染出对应的选项列表，也就是“拨轮”。拨轮的本质就是一个长长的列表，我们会通过 CSS 的 transform: translate 让它进行上下的偏移，并且把溢出的部分隐藏起来，这样看起来就像是一个轮盘在被转动了。

最后，我们来增加一个遮罩层，在拨轮的上半部分和下半部分都盖上一层渐变的白色遮罩，这样用户能就看清当前选中的是哪一项了。 由于拨轮这块的逻辑会比较复杂，所以我们可以把它独立拆一个组件出来。这样我们往下的讨论也可以更聚焦一些。 Wheel 只有三个属性：column 选项列表；value 当前选中的值；onSelect 当用户进行选择时会触发的事件。

⼿势 & 动画

接下来呢，我们为它增加一些交互。在用户对 Picker 进行操作时，有两种可能的方式。第一种是直接点击选项，另外一种是通过手势拖拽。

为了更好的描述我们如何去实现手势和动画，这里我们把这个问题抽象成一个最简化的版本。这里有一个小方块，我们可以按住鼠标，把它拖拽起来，当我们松开鼠标的时候，小方块会落回原位。

那这里首先呢是需要实现手势的处理，手势的本质就是鼠标或者是手指在 x 轴、y 轴方向上的移动距离。在 React 的生态社区之中，有很多的手势库，我们选择了 use-gesture。我们可以使用它提供的 useDrag hook 来定义一个手势，当触发了拖拽事件时，我们将滑块的 y 轴位移 translateY 设置为当前手势的移动量。

接下来，我们需要在拖拽结束的时候，让小球落回原位，这里就涉及到了动画。

相信大家提到动画，首先都会想到 CSS transition，因为它实在是太简单直接了。通过这行 CSS 代码，我们可以让滑块的 transform 属性（也就是它的位移）自动的实现动画过渡。但是我们其实只希望它在回落的时候有这个动画效果，而在拖拽中滑块应该是立即跟随鼠标位置的。所以这里我们在手势中增加一个判断，如果用户还正在进行拖拽，那我们给它增加一个 grabbing 的 class name，从而禁用掉 transition。当手势结束时，我们移除掉 grabbing 这个 class name，并且将它的位置设置回原位。这样就回出现一个回落的动画效果。

来看一下效果，似乎还是不错的。但是，我们需要再考虑一种边界情况。如果我们在这个滑块正在下落的过程中，再次点击了它，那么我们应该需要实现的是能够在半空中“接住”这个滑块，并且继续拖动它。

而事实上现在的效果是，我们一点这个滑块，它就会重新从原点开始被拖拽。这是因为，对于 CSS 动画来说，我们很难获取到它的动画进行到了哪个状态。如果我们希望得到在鼠标按下时滑块当前的位置，那可能就需要通过一些比较特殊的方法来实现了，比如说 getBoundingRect。所以，CSS 动画在某些场景下的确简单好用，但是当我们需要对动画状态做很多的干预和处理的时候，我们很容易会遇到一些它的短板。

所以呢，我们需要换一种方案，也就是基于 js 的动画。

让我们以 react-spring 为例，它是一个有点像物理引擎的动画库。 首先，我们使用它提供的 useSpring 创建出一个弹簧动画，动画的初始位置是 y 等于 0。然后我们通过 animated.div 这样一个特殊的元素，把刚刚得到的动画量 y 和 slider 的位移量绑定在一起。接下来我们对手势的处理逻辑进行一下调整，当手势结束时，我们把 y 重置为 0。而如果手势还在拖拽中，我们把 y 立即更新为当前的手势偏移量。然后这里需要特别注意的是，我们在手势的配置中增加了一个 from 参数，它表示的是每一次手势开始的时候，初始的偏移量是多少。而大家可以看到，这里我们给它设置的初始偏移量是 y 这个动画变量的当前值。也就是说，我们会让手势从动画当前进行到位置继续，而不是强制它从原点开始。

现在，我们就可以拥有完美的手势体验了。基于同样的思路，我们可以给 Picker 也增加上手势和动画效果，当然会更复杂一些，但是思路是相通的。

说完手势和动画，我们再来考虑另一个问题。当我们在使用选择器时，很多个拨轮之间可能是有联动关系的。比如省市区的选择。但是就目前的数据结构而言，Picker 组件的多个拨轮之间是彼此独立的。所以我们需要能够在第一列变化时动态调整第二列的选项列表。

OK，那我们来改一下 columns 属性，让它允许用户传入函数动态生成 columns。然后我们基于 Picker 的这个能力，封装出一个 CascadePicker。

所以我们现在有了两个组件：一个通用的 Picker 和一个专用于级联场景的 CascadePicker。他们的属性几乎是完全一样的，但是 Picker 的选项是通过 columns 配置的，columns 是一个二维的数组。而 CascadePicker 的选项是通过 options 配置的。和 columns 不同的是，它是一个树形的结构，更准确的说，是多个树形节点组成的数组。

大家可以看到，这两个组件，有 16 个完全相同的属性，却只有一个不同的属性

那为什么不把这两个组件合二为一呢？就像这样： 我们可以让 columns 属性同时支持两种类型的数据格式，然后在 Picker 组件中去做判断，看用户当前的数据是不是级联模式，然后用对应的逻辑去进行处理。听起来也不难实现。但是这种方案也存在着一些弊端：

首先，左右两种数据结构看起来只是增加了一个可选的 children 属性，但是数据类型已经不一致了，左边是一个两级的数组，而右边是一个一级的数组。如果不特别注意，非常容易搞混和写错。

第二点就是 columns 属性已经不再名副其实了，如果说 columns 是一个数组，代表的是很多列选项，那这个数组其中的每一个元素应该是一列选项才对，就像左边这样，第一列是省，第二列是市。而对于右边这种级联的数据结构，数组中的第一个元素是浙江节点，第二个元素是江苏节点，我们能说浙江是一列、江苏是另一列么？显然是不可以的。如果我们给这种结构的数据起个名字，那也应该叫做 tree、treeNodes 或者是 options。第三点，是这样做会导致很多逻辑被塞在 Picker 组件中，而过度的逻辑耦合可能会对组件的后续改动造成一些限制。假如说我们想给 Picker 组件增加一个新属性，那就要同时考虑级联和非级联的两种情况。而如果我们希望做一些内部实现上的优化，复杂的参数结构也可能会带来额外的成本。

我们的原则是，可以选择重复，但不应该去选择错误的抽象。优秀的代码结构和 API 设计不应该以组件数量、属性数量来进行评判。如果我们不去谨慎地处理抽象，仅仅是依靠外在的“形似”来做聚合，那反而可能会导致代码越来越难以维护。

基于类似的思路，我们还可以制作日期选择器组件。它最核心的部分也是这个 columns 的生成函数。

性能

我们来试一下：感觉还是很流畅的。不过，如果我们把 CPU 的性能做一些限制，让它变慢 6 倍，就会发现有一点点的卡顿，在 Chrome 的性能面板中，我们可以很明显的观察到有几帧丢失了。 那我们来排查一下，这里我们用到了 React dev tools 的 profiler 工具，我们对刚刚这个操作进行一下录制和分析，会发现 Wheel 组件被频繁的渲染了。 如果我们把被渲染的组件高亮一下，就会发现，当滑动第三个拨轮的时候，可以看到五个拨轮全部都被重新渲染了，这显然是不符合预期的。

解决方案自然是给 Wheel 加个 memo，但是这里直接套一层 memo 是不会有效果的，我们还需要做一些特殊的处理，包括调整 Wheel 的属性、自定义 props 的对比逻辑。因为今天时间有限，这些我们就不具体展开了，感兴趣的朋友可以在 GitHub 上阅读 antd-mobile 的源代码。

OK，经过这波优化之后，我们再来测试一下效果，可以看到转动第三个拨轮，只会触发它自己的重新渲染。React Profiler 中也可以看到组件的渲染有明显的减少。丢帧的情况也不存在了。

⽆障碍

大家可能会觉得，现在这个 Picker 组件总该算是做的差不多了吧？很遗憾，并不是。

在我们的身边，有很多的失明人士，根据 2018 年的统计，在中国，每 80 个人中就有一位视力残疾患者。他们没有办法清楚地看到屏幕上显示的文字和按钮，那对于他们来说，想要操作手机，就需要借助于屏幕阅读器。大家可以想象出来，一位盲人，该如何使用这个 Picker 组件吗？

我们来直接试验一下：

相信这个体验不用多说，正常人都没办法忍受，那，又该怎么优化呢？

作为开发者，我们大多数人应该都对无障碍这件事情挺头大的，特别是对于 Picker 这种看起来交互就很复杂的组件。无障碍能力本身并不复杂，通过屏幕阅读器，我们能做的操作就是非常简单的上一项、下一项、点击一下当前项，这本身再简单不过了。但是我们的网页是在一个二维平面上呈现的，而屏幕阅读器却只能把它识别为一个一维的线性的信息结构，这之间的差异，才是导致无障碍能力实现困难的根源。我们尝试了很多办法，最终，选择了去为屏幕阅读器单独实现一套交互。 首先，我们让下面的这层拨轮被屏幕阅读器忽略掉，然后我们再往上面叠加一层内容，包括一段文字，表示当前这一列选择了哪个选项，以及两个操作按钮，用来选择上一项和选择下一项。最后，我们把上面这一层内容设置为完全透明，让我们来看一下实际效果。

说了这么多，我们已经差不多要结束了，但在最后，我想替整个 antd-mobile 的社区，以及所有 antd-mobile v5 的使用者感谢参与过 v5 版本建设的同学，从 21 年 7 月推送到 GitHub 开始，到年底为止，在这短短半年的时间里，我们收到了来自 50 位社区同学的 325 个 PR ， 460 个 commit 和 416 个 issue。不论是参与代码的编写，还是反馈问题或者是参与讨论，这些都对 antd-mobile 的建设都有着非常非常重要的意义，感谢大家对 antd-mobile 的支持。

人们常说，“一个人可以走的更快，但一群人可以走的更远”，我想或许这也是对开源精神的最佳诠释吧。