MessageThrottle 是什么, 解决了什么痛点
MessageThrottle 是使用 Objective-C 实现的 iOS 函数节流(Throttle)和防抖(Debounce)的工具库. 在实现 App 交互的时候, 逻辑的刷新太频繁会导致性能上的问题, 比如不断有新的数据加载导致列表一直在刷新, 按钮的点击速度太快导致逻辑被多次执行, Slider 或者 滑动手势等频繁回调导致性能跟不上, 数据一直在变化导致耗费诸多性能在中间状态上等. 在业务层, 我们经常要结合业务来做限频或者定时刷新等逻辑, 来解决上面这些问题, 但是 MessageThrottle 提供了新的思路, 在不耦合业务逻辑的情况下, 实现间隔性消息调用, 即函数节流(Throttle)和防抖(Debounce).
使用 MessageThrottle, 只需如下简单的代码
#import "MessageThrottle.h"
// 设置 foo: 每秒调用一次, 默认是防抖模式, 此行代码调用一次即可
[object mt_limitSelector:@selector(foo:) oncePerDuration:1.0];
- (void)foo:
{
// todo: xxx
}
// 业务代码, 正常调用 foo: 即可
- (void)otherFunction
{
[self foo:params];
}
MessageThrottle 实现原理
MessageThrottle 是一个实现函数节流和防抖的工具库, 那么节流和防抖有什么不同呢? 以及 MessageThrottle 怎么来实现对消息的节流的?
节流和防抖有什么不同?
MessageThrottle 的思路源自 Underscore.js.
节流(Throttle) 在 Underscore.js 中的解释如下:
Creates and returns a new, throttled version of the passed function, that, when invoked repeatedly, will only actually call the original function at most once per every wait milliseconds. Useful for rate-limiting events that occur faster than you can keep up with.
By default, throttle will execute the function as soon as you call it for the first time, and, if you call it again any number of times during the wait period, as soon as that period is over.
创建并返回一个像节流阀一样的函数，当重复调用函数的时候，至少每隔 wait 毫秒调用一次该函数
默认情况下，throttle 将在你调用的第一时间尽快执行这个 function，并且，如果你在 wait 周期内调用任意次数的函数，都将尽快的被覆盖。
防抖(Debounce) 的解释如下:
Creates and returns a new debounced version of the passed function which will postpone its execution until after wait milliseconds have elapsed since the last time it was invoked. Useful for implementing behavior that should only happen after the input has stopped arriving. For example: rendering a preview of a Markdown comment, recalculating a layout after the window has stopped being resized, and so on.
创建并返回一个防抖动的函数, 在最后一次执行时间的 wait 毫秒之后才真正执行. 在需要不会再有输入(一般是用户行为等无法预测的改变)的情况下执行原有方法. 比如渲染一个 Markdown 格式的评论预览, 只有当窗口停止改变大小之后才重新计算, 等等.
简单说, 节流就像是公交车每 10 分钟发一班车; 一直没人上车就等待, 第一个人上车后立刻发车, 期间到的人就不管了, 直到 10 分钟后进入等待状态, 来人就立刻发车并进入下一个 10 分钟周期. 防抖是有人上车就开始 10 分钟计时, 计时期间有人上车的话就重新开始 10 分钟计时, 直到计时结束都没人上车的话才发车.
MessageThrottle 怎么对消息做节流
在我的上一篇文章iOS MessageThrottle 防抖与 RAC 的冲突中对此问题以及可能导致的问题有简单的解析.
MessageThrottle 将消息的转发流程(Runtime 相关知识)与限频逻辑做了结合, 将原有的 foo: 方法的IMP 换成了_objc_msgForward, 从而直接触发消息转发流程, 在消息转发中调用动态生成的 hook 方法, 实现了自己的__mt_foo:方法, 在自己的方法中处理了限频逻辑. 实现细节参考文章MessageThrottle Safety或源码即可.
MessageThrottle 实现了哪些节流防抖的功能
MessageThrottle 的三个模式
/**
消息节流模式
- MTPerformModeFirstly: Throttle 模式：执行最靠前发送的消息，后面发送的消息会被忽略
- MTPerformModeLast: Throttle 模式：执行最靠后发送的消息，前面发送的消息会被忽略，执行时间会有延时
- MTPerformModeDebounce: Debounce 模式：消息发送后延迟一段时间执行，如果在这段时间内继续发送消息，则重新计时
*/
typedef NS_ENUM(NSUInteger, MTPerformMode) {
MTPerformModeFirstly,
MTPerformModeLast,
MTPerformModeDebounce
};
具体到代码以及注释如下
// MTPerformModeFirstly
// 如果当前的时间减去上一次执行的时间, 大于规定的周期时长, 才执行本次逻辑
if (now - rule.lastTimeRequest > rule.durationThreshold) {
// 将生成的 __mt_foo: 方法覆盖原有的 selector
invocation.selector = rule.aliasSelector;
// 调用 __mt_foo:
[invocation invoke];
// 修改这个方法最后一次被执行的时间
rule.lastTimeRequest = now;
dispatch_async(rule.messageQueue, ^{
// May switch from other modes, set nil just in case.
rule.lastInvocation = nil;
});
}
// MTPerformModeLast
// 不判断条件, 直接覆盖原有方法
invocation.selector = rule.aliasSelector;
// 引用调用参数, 防止异步执行 invoke 时候 crash, 参数会在 invoke 后自动释放,
[invocation retainArguments];
dispatch_async(rule.messageQueue, ^{
// invocation 准备异步执行, 放到 rule 中以免被释放, 注意rule.lastInvocation 在周期内会被再次替换
rule.lastInvocation = invocation;
// 如果这次的时间距离上一次超过了一个周期才准备执行
if (now - rule.lastTimeRequest > rule.durationThreshold) {
rule.lastTimeRequest = now;
// 会被推迟到这个周期的最后时刻来执行
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(rule.durationThreshold * NSEC_PER_SEC)), rule.messageQueue, ^{
if (!rule.isActive) {
rule.lastInvocation.selector = rule.selector;
}
// 执行此次周期内最后一个 invocation
[rule.lastInvocation invoke];
rule.lastInvocation = nil;
});
}
});
// MTPerformModeDebounce
// 不判断条件, 直接覆盖原有方法
invocation.selector = rule.aliasSelector;
// 引用调用参数, 防止异步执行 invoke 时候 crash, 参数会在 invoke 后自动释放,
[invocation retainArguments];
dispatch_async(rule.messageQueue, ^{
// 替换 lastInvocation, 注意只要不被执行, 并且有新的 invocation, 就会不断被替换
rule.lastInvocation = invocation;
// 延期一个周期
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(rule.durationThreshold * NSEC_PER_SEC)), rule.messageQueue, ^{
// 如果 invocation 被替换了, 就不执行了
if (rule.lastInvocation == invocation) {
if (!rule.isActive) {
rule.lastInvocation.selector = rule.selector;
}
// 没有被替换, 说明这一个周期内没有来新的调用, 直接执行
[rule.lastInvocation invoke];
rule.lastInvocation = nil;
}
});
});
我们通常需要一个怎么样的节流器
如上面代码注释所言, MessageThrottle 提供的两个 Throttle 模式均会丢弃最前面或者最后面一次的消息, 而 Debounce 模式则是会一直延时执行, 但是在很多场景中, 我们希望节流器可以做到以下三点:
- 第一次消息能立即调用, 交互上可以让用户知道已经在开始变化了.
- 最后一次消息不应该被丢弃, 因为最后一次的消息是最新的, 丢弃会使状态处在一个中间状态, 这会给用户传递错误的信息.
- 中间状态应该有序均匀调用, 比如在频繁刷新的场景保持一秒刷一次.
怎么改造 MessageThrottle
基于 MessageThrottle, 我增加了第四种模式 MTPerformModeFirstlyPerDuration. 周期内第一条消息会被立刻执行, 最后一条消息会被延迟到下一个周期的开始执行, 然后中间的消息会被忽略. 这样满足了上面的三个要求.
下面直接上代码
case MTPerformModeFirstlyPerDuration: {
if (now - rule.lastTimeRequest > rule.durationThreshold) {
invocation.selector = rule.aliasSelector;
[invocation invoke];
rule.lastTimeRequest = now;
dispatch_async(rule.messageQueue, ^{
// May switch from other modes, set nil just in case.
rule.lastInvocation = nil;
// 一个周期后 检查是否执行最后一个被忽略的调用
checkWhenNextDuration(rule);
});
} else {
dispatch_async(rule.messageQueue, ^{
if (rule.lastInvocation)
{
rule.lastInvocation = nil; // 清空之前设置的
}
invocation.selector = rule.aliasSelector;
[invocation retainArguments];
rule.lastInvocation = invocation; // 设置为需要延时执行
});
}
break;
}
static void checkWhenNextDuration(MTRule *rule)
{
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(rule.durationThreshold * NSEC_PER_SEC)), rule.messageQueue, ^{
if (rule.lastInvocation)
{
if (!rule.isActive) {
rule.lastInvocation.selector = rule.selector;
}
[rule.lastInvocation invoke];
rule.lastInvocation = nil;
NSTimeInterval now = [[NSDate date] timeIntervalSince1970];
now += MTEngine.defaultEngine.correctionForSystemTime;
rule.lastTimeRequest = now; // 重新计时
checkWhenNextDuration(rule); // 再次延时检查是否需要执行
}
});
}
最后用一张图表示这四个模式:
duration 为 1 秒, 演示四个模式
x / ignore 表示忽略此次消息
delayTo 表示延时处理此次消息
√ / invoke 表示执行消息
MTPerformModeFirstly
0______________1______________2______________3______________
√______x________√_____x______x______√___x______x___
| | | | | | | |
| ignore | ignore ignore | ignore ignore
invoke invoke invoke
MTPerformModeLast
0______________1______________2______________3______________
x______x_____√___x______√________√_________________
| | | | | |
ignore ignore| ignore | |
| | |
delayTo->1 delayTo--->2 delayTo---->3
| | |
Invoke Invoke Invoke
MTModePerformDebounce
0______________1______________2______________3______________
x________x_____x__x________√______________________
| | | | |
ignore ignore ignore |
|
delayTo--------------->Here
duration |
invoke
MTPerformModeFirstlyPerDuration
0______________1______________2______________3______________
√_____x______√_____x___x___√______x__x__√___________
| | | | | | | | |
| ignore | ignore | ignore|
| | | |
| delayTo->1 delayTo-->2 delayTo---->3
| | | |
invoke invoke invoke invoke
