安卓点击防抖优化手册（非代码层指导）

1.1.1. 什么是点击防抖？

在应用日常使用过程中，短时间内超过一次点击某个按钮会触发多次这个按钮的后续逻辑代码运行，这时加入某些手段屏蔽掉除第一次以外的点击事件去重复触发逻辑的控制称为点击防抖。

1.1.2. 为什么需要添加点击防抖?

正如上面介绍的，在没有添加点击防抖的情况下短时间内多次点击某按钮会多次触发相关逻辑，比如多次打开某个页面，多次提交某些网络请求等等，这些通常不是我们所期望的，而且有些逻辑多次触发也有可能引起程序卡顿、数据异常、应用崩溃等问题。

综上所述，我们在某些场景下是需要添加点击防抖的，以此来进行限制用户有意或无意的短时间内频繁点击按钮的操作，来规避由此产生的期望外的运行结果。

1.1.3. 点击防抖的间隔

点击防抖的间隔是否越长越好呢？当然不是，过长的点击防抖间隔会给用户造成按钮点击无效的感觉，通常点击防抖的间隔不宜大于500ms。

点击防抖的间隔是否越短越好呢？当然也不是，间隔过短，点击防抖也就失去了意义，点击防抖本身的意义就是通过屏蔽短时间的连续点击来规避异常逻辑，如果点击防抖间隔过短，那这个设置本身就失去了他自身的意义。通常点击防抖的间隔应大于100ms。

综上所述，通常情况下点击防抖间隔应取100ms到500ms之间，但是这个值并非固定值，需要根据实际的业务场景进行调整，一般原则是和你的点击事件处理逻辑时间成正比，逻辑处理时间越长，则点击间隔应该越长，逻辑处理时间越短，则点击间隔应该尽量短。比如点击逻辑是打开页面，这个逻辑只有100ms，则点击间隔应该尽量短，比如点击逻辑是打开蓝牙，这个逻辑有800ms，则点击间隔就需要适量增加。

1.1.4. 是否所有点击都需要点击防抖？

并不是，通常我们需要添加点击防抖都是根据实际业务去填加，并不建议所有按钮都统一添加，这是因为有很多按钮都是实时操作的，如果添加了点击防抖，会让用户产生点击无效的体验。

那么哪些场景是建议添加点击防抖的呢？

首先，重复点击事件对业务逻辑有异常影响的，这种情况除了要添加点击防抖，也要控制短时间内两次事件如何规避影响。

其次，点击业务逻辑是非即时操作，但具体耗时通常也不会很长（1秒左右），比如打开关闭蓝牙、打开关闭wifi这种点击事件，这种是需要添加点击防抖的，真正的耗时操作反而不建议添加点击防抖，比如网络请求、数据IO，这种耗时操作可以直接点击后禁用按钮点击，并且展示加载弹窗，在业务逻辑完成后关闭弹窗，重新启用点击按钮。

1.1.4. 点击防抖优化进阶

点击防抖的方法除了最基本的添加点击间隔外还需要考虑异常情况，比如某个点击事件逻辑，通常完成时间为100ms-200ms，这时如果添加了250ms的点击间隔，那么就可以规避多次点击造成的重复逻辑，但是在某些异常情况下如果点击事件逻辑为500ms，则依然可能出现多次点击有效，这时候就可能需要考虑进行优化。

还是以经典的打开关闭蓝牙为例，通常打开关闭蓝牙是比较快的，但是有时候系统反应会出现延迟，这时候如果处理不当就可能出现蓝牙状态按钮跳动、状态显示错乱等问题，这种情况下，简单粗暴的使用点击间隔并不合适，建议采用以下逻辑进行处理：

关键点有几个：

l 监听蓝牙状态按钮的父布局点击事件而不是直接监听蓝牙按钮的onCheck事件，因为打开关闭蓝牙需要根据广播状态去显示真实状态，check事件容易混乱，虽然也有规避方法，但是最简单的就是直接禁用switch或checkbox的点击，而去监听父布局。

l 可以在监听到点击后立即去改变按钮选中状态而不是去等待广播回调，这样用户可见的就是立即生效，就避免了用户看到状态没有变化而主动反复去点击按钮。

l 点击事件触发后直接禁用点击，等待最终状态广播回来后再恢复父布局的点击。

l 最终状态广播回来后需要再去根据实际状态回来后需要再去设置一遍蓝牙状态按钮的选中状态，这个主要是为了防止打开或关闭失败时状态显示错误的问题，但是通常是不会出错的，这时候如果按钮状态出现闪动说明蓝牙底层就有问题，是需要底层去排查。

如果为了进一步提升用户体验，也可以在点击事件触发后蓝牙状态显示闪烁动画，示意用户正在进行操作，在最终蓝牙状态广播回来后关闭这个动画，这也是大部分手机厂商的做法。

1.1.5. 总结

点击防抖的终极优化其实就是程序对用户的点击给出即时反馈，用户连续点击某个按钮绝大部分情况一定不是源于手抖，而是因为点击了某个按钮，但是没有收到反馈，那么用户下意识就会再次点击或者频繁点击，最终造成程序数据异常或崩溃。

比如点击一个按钮跳转页面，如果用户点击后1秒没有跳转，那么用户就有可能再次点击，这是大概率事件，所以这种情况，实际上我们应该想的是怎么去优化页面打开速度，而不是直接把打开页面的事件防抖间隔设置为1秒，再比如打开蓝牙这个操作，如果用户点击后你在收到最终广播之后才去改变按钮状态，且中间没有任何交互提醒，那么当这个广播回来的时间稍久，用户就会认为点击无效，而再次点击，这些才是用户频繁点击的根源，没有几个用户会无聊到频繁去点击一个按钮。

那么从交互角度来说，给这些逻辑时间可能会有延迟到事件统一使用弹出loading的方式行吗？答案是不行，因为这种逻辑的时间只是偶尔延迟，或者稍微延迟，在这样的场景下如果弹窗，有可能只是弹窗闪现一下就消失了，因为逻辑执行完了，这种在用户看起来是非常难受的。为什么ios系统直到现在依然被认为流畅度超越安卓，哪怕很多时候应用打开速度等并不如安卓呢，因为ios给用户的交互体验是远超安卓的，安卓在很多交互的优化上官方没有进行处理，完全需要开发者自己去处理，而很多人其实是不会花时间去处理的。所以为了产品更好的体验，多去溯源一些体验不好问题的根源尤为重要。