WQthrottle?是一款消息防抖框架，在一定的時間延時中做到只觸發(fā)一次結果的回調(diào)。

使用

使用的話，還是看 github 的 README 吧。

開發(fā)目的

開發(fā)這款框架的初衷是為了解決以下的幾個痛點:

多余的操作請求

多頁面消息傳遞

痛點一(多余的操作請求)

這個痛點在我們的業(yè)務中經(jīng)常出現(xiàn)，下面列出兩個比較常見的業(yè)務操作：

點贊

在我們設計點贊的時候，每點擊一次 贊?操作都會請求服務器，以告知服務器當前是 點贊?操作還是 取消贊?操作，如果用戶這時頻繁去點贊，就會導致過多的網(wǎng)絡請求，產(chǎn)生了不必要的浪費。對于設計層面來說，點贊功能無非就是兩種狀態(tài)，贊或是沒贊?，我們完全可以等待用戶停止操作后再去請求服務器。

搜索

實時搜索展示搜索內(nèi)容也是我們平時業(yè)務中比較常見的功能，我們給 EditText 注冊?TextWatcher 監(jiān)聽，在?onTextChanged?中實時拿到用戶輸入的內(nèi)容然后請求網(wǎng)絡，看似一段沒有任何問題的操作，就敗在不同用戶的輸入習慣，有的人打字非常慢，打入一些詞組，onTextChanged 收到消息立馬請求服務器顯示結果，而有的人打字非?？?#xff0c;而且每打一個詞組就回車到 EditText 上，這就會導致頻繁的網(wǎng)絡請求，更糟糕的情況就是頻繁的頁面渲染，100次請求就會導致100次的頁面渲染。

痛點二(多頁面消息傳遞)

在剛接觸 Android 開發(fā)時，頁面的消息傳遞一般都是 Intent ，回傳通過 setResult 將結果帶回上一個頁面，非常蛋疼的操作，直到后來出現(xiàn) EventBus?，在業(yè)內(nèi)非常流行，一款非常解耦的框架，可以做到在任何地方發(fā)送消息和接收消息，但對于我來說，缺點還是蠻多的：

Subcribe?太隨意，導致后面項目亂，不好維護

Eventbus 的內(nèi)部實現(xiàn)原理是反射，性能問題需要斟酌

每次 post 一個消息過去都要想，我這個 bean 會不會影響到其他的消息接收，算了，還是創(chuàng)建一個 bean 類吧

原理剖析

實現(xiàn)原理非常簡單， 就一個核心東西——《Handler》

初始化

初始化操作使用的單例，他會默認構造一個 handler 處理類：

handler = HandlerFactory.create(HandlerType.MAIN_THREAD, callBacks);

HandlerType 是一個枚舉類，該枚舉主要為了告知接收器是在主線程還是子線程，具體可看?HandlerFactory 類。

注冊

注冊非常簡單，就是注冊一個 CallBack 接口，等 post 消息時，會一一回調(diào)注冊的 callback

private List callBacks = new ArrayList<>();

public void register(CallBack callBack) {

callBacks.add(callBack);

}

發(fā)送消息

發(fā)送消息整個框架的核心部分：

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 時間內(nèi)，移除之前觸發(fā)的消息，然后重新發(fā)送消息，直到用戶不觸發(fā)了，等 delay 時間到了，消息就會發(fā)送出去了。

消息接收

消息的接收需要先看看回調(diào)部分的代碼：

new Handler(Looper.getMainLooper()) {

@Override

public void handleMessage(Message msg) {

super.handleMessage(msg);

sendMessages(msg, callBacks);

}

};

private static void sendMessages(Message msg, List callBacks) {

for (int i = 0, len = callBacks.size(); i < len; i++) {

callBacks.get(i).throttleResult(msg.what, msg.obj);

}

}

發(fā)送的消息被 Handler 接收到了，會遍歷所有 CallBack 注冊接口，將信息 post 出去。

@Override

public void throttleResult(int tag, Object obj) {

switch(tag){//do something}

}

CallBack 根據(jù)發(fā)送的 tag 進行比較，確定是什么操作，然后取出參數(shù) obj。

結束

整個設計非常簡單，僅僅只通過 Handler 就實現(xiàn)了基于消息的框架。

話不多，就這樣吧

總結

以上是生活随笔為你收集整理的android 功能防抖,一款简单的消息防抖框架的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。