一款简单的消息防抖框架

简介: 一款简单的消息防抖框架

WQthrottle 是一款消息防抖框架,在一定的时间延时中做到只触发一次结果的回调。

使用


使用的话,还是看 github 的 README 吧。

开发目的


开发这款框架的初衷是为了解决以下的几个痛点:

  • 多余的操作请求
  • 多页面消息传递

痛点一(多余的操作请求)


这个痛点在我们的业务中经常出现,下面列出两个比较常见的业务操作:

点赞


在我们设计点赞的时候,每点击一次 操作都会请求服务器,以告知服务器当前是 点赞 操作还是 取消赞 操作,如果用户这时频繁去点赞,就会导致过多的网络请求,产生了不必要的浪费。对于设计层面来说,点赞功能无非就是两种状态,赞或是没赞 ,我们完全可以等待用户停止操作后再去请求服务器。

搜索


实时搜索展示搜索内容也是我们平时业务中比较常见的功能,我们给 EditText 注册 TextWatcher 监听,在 onTextChanged 中实时拿到用户输入的内容然后请求网络,看似一段没有任何问题的操作,就败在不同用户的输入习惯,有的人打字非常慢,打入一些词组,onTextChanged 收到消息立马请求服务器显示结果,而有的人打字非常快,而且每打一个词组就回车到 EditText 上,这就会导致频繁的网络请求,更糟糕的情况就是频繁的页面渲染,100次请求就会导致100次的页面渲染。

痛点二(多页面消息传递)


在刚接触 Android 开发时,页面的消息传递一般都是 Intent ,回传通过 setResult 将结果带回上一个页面,非常蛋疼的操作,直到后来出现 EventBus ,在业内非常流行,一款非常解耦的框架,可以做到在任何地方发送消息和接收消息,但对于我来说,缺点还是蛮多的:

  • Subcribe 太随意,导致后面项目乱,不好维护
  • Eventbus 的内部实现原理是反射,性能问题需要斟酌
  • 每次 post 一个消息过去都要想,我这个 bean 会不会影响到其他的消息接收,算了,还是创建一个 bean 类吧

原理剖析


实现原理非常简单, 就一个核心东西------《Handler》

初始化


初始化操作使用的单例,他会默认构造一个 handler 处理类:

handler = HandlerFactory.create(HandlerType.MAIN_THREAD, callBacks);
复制代码

HandlerType 是一个枚举类,该枚举主要为了告知接收器是在主线程还是子线程,具体可看 HandlerFactory 类。

注册


注册非常简单,就是注册一个 CallBack 接口,等 post 消息时,会一一回调注册的 callback

private List<CallBack> callBacks = new ArrayList<>();
public void register(CallBack callBack) {
        callBacks.add(callBack);
}
复制代码

发送消息


发送消息整个框架的核心部分:

WQThrottle.getInstance().delay(int tag, long timeMillis, Object params);
复制代码

我们来看下 delay 做的什么东西:

public void delay(int tag, long timeMillis, Object params) {
        handler.removeMessages(tag);
        Message msg = handler.obtainMessage();
        msg.obj = params;
        msg.what = tag;
        handler.sendMessageDelayed(msg, timeMillis);
   }
复制代码

还是非常简单,就是在 delay 时间内,移除之前触发的消息,然后重新发送消息,直到用户不触发了,等 delay 时间到了,消息就会发送出去了。

消息接收


消息的接收需要先看看回调部分的代码:

new Handler(Looper.getMainLooper()) {
            @Override
            public void handleMessage(Message msg) {
                super.handleMessage(msg);
                sendMessages(msg, callBacks);
            }
};
private static void sendMessages(Message msg, List<WQThrottle.CallBack> callBacks) {
        for (int i = 0, len = callBacks.size(); i < len; i++) {
            callBacks.get(i).throttleResult(msg.what, msg.obj);
        }
}
复制代码

发送的消息被 Handler 接收到了,会遍历所有 CallBack 注册接口,将信息 post 出去。

@Override
 public void throttleResult(int tag, Object obj) {
     switch(tag){//do something}
 }
复制代码

CallBack 根据发送的 tag 进行比较,确定是什么操作,然后取出参数 obj。

结束


整个设计非常简单,仅仅只通过 Handler 就实现了基于消息的框架。

目录
相关文章
|
12天前
|
前端开发
防抖和节流的区别,实现和用处。
防抖和节流是优化高频事件处理的两种技术。防抖确保在一系列连续事件后仅执行最后一次操作,如搜索输入完成后再发送请求;节流则保证在设定时间内仅执行一次操作,适用于滚动加载等场景。两者通过限制回调函数的执行频率,有效提升前端性能。示例代码展示了如何实现这两种技术。
28 2
|
2月前
|
前端开发 JavaScript UED
什么是防抖和节流?有什么区别?如何实现?
防抖和节流是前端优化技术,用于限制函数的执行频率。防抖是在一段时间内只执行一次函数,常用于搜索输入、窗口调整等场景;节流是在固定时间间隔内执行函数,适用于滚动事件、鼠标移动等。实现方式通常使用定时器。
|
7月前
|
消息中间件 存储 设计模式
JavaScript发布订阅模式:实现事件驱动编程!
JavaScript发布订阅模式:实现事件驱动编程!
|
7月前
|
JavaScript 前端开发
揭秘 `nextTick`:解决异步回调的利器(上)
揭秘 `nextTick`:解决异步回调的利器(上)
揭秘 `nextTick`:解决异步回调的利器(上)
|
7月前
|
JavaScript 前端开发
揭秘 `nextTick`:解决异步回调的利器(下)
揭秘 `nextTick`:解决异步回调的利器(下)
揭秘 `nextTick`:解决异步回调的利器(下)
|
JavaScript 前端开发
【高频触发事件优化】封装节流和防抖
【高频触发事件优化】封装节流和防抖
170 0
|
前端开发
前端学习案例1-防抖和节流1
前端学习案例1-防抖和节流1
71 0
前端学习案例1-防抖和节流1
|
前端开发
前端学习案例2-防抖和节流2
前端学习案例2-防抖和节流2
52 0
前端学习案例2-防抖和节流2
|
前端开发
前端学习案例3-防抖和节流3
前端学习案例3-防抖和节流3
71 0
前端学习案例3-防抖和节流3
|
前端开发
前端学习案例4-防抖和节流4
前端学习案例4-防抖和节流4
69 0
前端学习案例4-防抖和节流4