在写MultiPicker之前写了一篇文章——“为移动端而生”的自定义多级联动选择器，受到了很多人的关注。鉴于很多人都很好奇这个手写插件的流程，所以特地写了几篇文章来说说它的成长史~看这篇文章之前，请确保你已经阅读了MultiPicker的源码~点击查看源码，也可以在npm上找到它们：DateSelector-DateSelector-NPM。自定义json选择器-MultiPicker。NPM。回顾上一集：如何创建移动联动选择器（一）回顾上一集：如何创建移动联动选择器（二）4.日期选择器与自定义JSON选择器的联动区别思考第五个问题：“如果滑动手势是它们之间的共同点，它们之间有什么区别？”』其中一个最明显的区别是，日期选择器可以在多个级别之间重复调整，而自定义JSON选择器只能从高级别联动向下调整。例如，在使用日期选择器选择生日时。一不小心弄错了，选择变成了1994-1-16。我想把年份改成1995年，当我滑动第一级联动时，后面的联动不会改变。但是当我选择城市的时候，如果我选择了北京，下面的联动层级都会匹配“北京”的高层联动，自适应向下变化。如果选择广东，下面的联动层级都会匹配“广东”的高层联动，向下自适应变化。因此，为了区分这两种不同的联动场景，出现了两种不同的联动算法。5、日期选择器的联动算法思考第六个问题：“如何协调用户设置的时间点与实际时间点的联动？”』如前所述，如果用户设置了【月、日、时、分】四个时间单位，则可能输入beginTime：[3,27,12,12]，endTime和recentTime类似。但是计算机如何快速识别这个开始时间，实际上是[2016,3,27,12,12]？如果将用户设定的时间点称为【虚拟时间】，将计算机能够处理的完整时间点称为【实时】，这个问题就会简化很多。我做了一个小技巧，就是将用户作为参数传入的【虚拟时间】（如：beginTime、endTime、recentTime）转换为代码在判断合法性的同时可以快速识别的【实时时间】用户参数。]（例如：begin_time、end_time、recent_time）。另外，idxArr、maxHeight、distance对应的下标值与【VirtualTime】对应的下标值一致。思考第七个问题：“如何计算联动数据，使其可以在多级之间反复调整？”』在我最新的重构算法中，我的解决方案是：当ul滑动时，从最高级的链接开始【递归调用】。被递归的函数称为checkRange。实现步骤如下：①每次touchend时，先保存当前滑动结果，然后调用checkRange(0)；②checkRange会直接根据你的参数设置下一级联动应该有的数据范围：③判断好下一级的数据范围后，需要判断slide是否到了开始时间（即是，top）还是结束时间（也就是bottom）：这里的循环是一个自己封装的for循环，需要了解这里的dir是怎么计算的。④判断dir的值后，需要调整上一步②生成的数据范围：如果滑动到开始时间的分界点，需要处理min的值；如果滑动到结束时间的分界点，需要处理maxvalue的值；处理完成后调用initRangeArr更新dom。⑤initRangeArr中更新dom后，需要根据数据调整ul的translate3d。通过一系列的计算，得到targetLong的值，用于设置translate3d。并同步所有控制结果的数据，不仅更新了recent_time和resultArr，还更新了maxHeight和distance。⑥然后递归调用checkRange；PS：注意区分【虚拟时间】和【实时】的下标含义。[虚拟时间]的下标是指接口上每个ul的下标，比如有3个ul，那么就是[0,1,2]；[realtime]的下标是指[0:year]【1:month】【2:day】...等等。Github地址：《为移动端而生》自定义多级联动选择器至此，时间选择器的核心算法已经基本掌握。预示会发生什么，过两天再见。我是加宝阿皮安，一个可爱的算法少女出家了。
