EventBus3.0 在高频任务下发送通知使用时遇到的问题

本文探讨了使用EventBus在高并发环境下更新UI时出现的进度不同步问题,并提出了两种解决方案:一是限制通知频率,二是增大缓冲区大小。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

EventBus3.0 在高频任务下发送通知使用时遇到的问题

本人最近接手一个项目的bug修改,遇到一个当时非常有趣的问题。
我们在进行下载一个文件时,经常会使用到进度条,这很常见。但就是这个进度条在搞笑。
我在我的一加3手机上运行app进行下载的时候没有任何问题,但是在一个几百块的手机上下载文件时,进度条可能才到30%,但实际上文件已经下载完了

/**内存缓存**/
byte[] buffer = new byte[1024];
/**保存文件的位置**/
File dFile = new File(....);
/**获取网络文件总大小,(方法名乱写的,实际api方法名可能不长这样)**/
long conLen = response.getContentLength();
/**以下载的大小**/
long dFileLen = 0;
while(../*读数据代码 io.read()*/..){
    ...
    /**累加下载文件总大小**/
    dFileLen += buffer.length() ;
    /**通过EventBus发送进度**/
    EventBus.getDefualt().post(new ProgressEvent(conLen,dFileLen));
    ...
}

可以看到,eventbus是在while里循环发送的通知

但是这个while是在线程中下载文件读数据的循环,循环一次的时间是多少
这的看你的buffer是多大的、网速是多快的,我这里是1K的大小,下载速度是6M一秒。
忽略cpu、磁盘速率,那么一次循环的时间 1/6000*1000≈0.2毫秒…….加上cpu等影响可能在1ms就会循环一次
下载的文件大小是27M,那么总发的通知次数为27*1024 = 27648次 / 5s(时间保守估计)

这么高频的发送通知,并且还需要线程转换(工作线程 -> 主线程),eventbus(cpu)是吃不消的
所以发送在工作线程,处理在主线程,eventbus只能把消息押入队列慢慢搞。
就会导致反应迟钝。

但是在相对较好的手机上没问题,那是因为,CPU牛逼啊!

解决方法:

    int filter = 0;
    while(../*读数据代码 io.read()*/..){
        ...
        if(++filter % 10 == 0)//过滤一下,别发那么频繁
            EventBus.getDefualt().post(new ProgressEvent(conLen,dFileLen));
        ...
    }

    /*======OR======*/

    byte[] buffer = new byte[1024*10]//或者增加buffer大小,也是减少发送次数

以上解决方案只是暂时解决方法,如果文件太小的话,可能进度条走动不平滑

因需要改其他bug,所以此解决方案暂未完善或者说是更适配其他手机。

后面可能会改为通过当前网速和文件大小计算 filter 的过滤数值!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值