关于提高 Tab 切换速度的思考

发表于 5年以前 | 总阅读数：1187 次

我们每天使用电脑，都要跟形形色色的 Tab 打交道。我正在用来写博客的 Chrome，就开着好多个 Tab。有了 Tab，我可以方便的切到其他页面看看新闻，过会儿再切回来接着写。OSX10.9 非常吸引我，让我能忍着巨多 bug 使用它的原因之一，也是因为 Finder 终于有了 Tab。

在 Web 上，也有着各种 Tab 用来呈现内容。它们一般都有若干触发点（trigger），对应若干个内容区域（container）。触发点接受一些事件，控制着内容区域的显示与否，构成一个完整的 TabView。有时候，它被称之为 Slider，或者 Switchable。

Tab 不同区域的内容可以是事先就存在的，也可以异步加载。不考虑数据加载这个环节，我们想让 Tab 响应更快，就要从它的切换过程说起了。

对于 click 切换的 Tab，延迟来自于 click 事件。我们知道，click事件在 mousedown 和 mouseup 配对之后才触发。这里有两层含义：1）如果鼠标一直不释放，一直不会触发 click；2）如果鼠标移到 mousedown 元素之外再释放，那么这个元素的 click 事件也不会触发。这个特点，对整个操作系统都适用，例如我文章写到一半，点 Chrome 的关闭，只要我在松开鼠标前把光标移出关闭按钮就没事，web 上也是类似。

可以看到，click 事件为用户提供了反悔的机会。很多后果比较严重或者成本较高的操作，如关闭页面、修改数据，页面跳转等，需要使用 click。反观大多数 Tab，内容是事先取好隐藏的，切换也不会引起页面结构变化，这时候我们完全可以使用 mousedown 来代替 click，大家可以试下本博客右侧的 Recent Comments|Recent Posts|Tags 模块，是不是切换速度飞快，也没什么副作用（注：本博客更换主题后，没有这个 tab了）？

实际上，在移动 OS 上，也有类似的场景：iOS 的 TabBar。多数第三方 App 的 TabBar 都是在 release 之后触发，相当于 web 的 mouseup 或 click；而大部分官方 App 的 TabBar，却是在 press 触发，例如 App Store、电话和时钟。国外的第三方 App，采用 press 的会多一些，例如 Twitter、Amazon 等。iOS 的 TabBar 切换不会引起界面框架变化，只有浏览内容会改变，这时候提高响应速度比提供反悔机会更重要，采用 press 有更好的用户体验。从这一点也可以看出苹果的用心之处。

iPhone 的实体按键中，Home 点亮屏幕是 press 触发，立即响应的；但打开 App 后，Home 回到桌面是 release 触发，虽说实体键不能反悔，也可以给用户一个缓冲：手指不松开，还能多看几眼当前的 App。音量键是 press 立即响应的，这个操作当然是越快响应越好。开关键关闭屏幕是 release 才触发的，因为开关键有另外一个功能：长按出现确认关机画面。这时候如果做成 press 立即触发，屏幕马上变黑，后面什么也看不到了。

综上，对于通过点击来切换的 Tab，在切换成本很低、页面框架不发生大的变化、不需要提供反悔，且没有定义有歧义事件（双击、长按等）的前提下，我们可以选择 mousedown/press 事件，提高 Tab 切换的响应速度。

另外一部分 Tab 是在 mouseover/mouseenter 时切换，例如淘宝首页的「便民服务」模块。mouseover 容易产生干扰，鼠标在移动过程中不小心经过 tab，就会触发内容区域切换。所以大部分采用 mouseover 的 Tab，都会延时一会儿才触发。也就是鼠标在触发点悬停一段时间（100~200ms）后才会切换内容，这期间如果鼠标移出了触发点，就当做什么事都没发生。

对于这种 Tab，我们既要提高切换的响应速度，又不能干扰用户，我能想到的办法就是计算用户鼠标运动轨迹，类似于这篇「揭秘 Amazon 反应速度超快的下拉菜单」里的思路。例如在切换横排 Tab 时，鼠标轨迹肯定是横向移动的。那么对于 Tab 区域内鼠标横向移动触发的切换，我们可以忽略延时立即响应。

以上，就是我关于提高 Tab 切换速度的个人看法，欢迎交流。