LiveEventBus:Android消息总线的未来

LiveEventBus:Android消息总线的未来

LiveEventBus:mailbox_with_mail:EventBus for Android,消息总线,基于LiveData,具有生命周期感知能力,支持Sticky,支持AndroidX,支持跨进程,支持跨APP项目地址:https://gitcode.com/gh_mirrors/li/LiveEventBus

在Android开发的世界中,消息总线是连接不同组件的桥梁,确保数据和事件的高效传递。今天,我们要介绍的是一款革命性的消息总线框架——LiveEventBus。它基于LiveData构建,不仅具备生命周期感知能力,还支持Sticky消息、AndroidX、跨进程通信以及跨APP通信。让我们深入了解这个强大的工具。

项目介绍

LiveEventBus是一款专为Android设计的消息总线框架,它利用LiveData的强大功能,提供了生命周期感知的消息传递机制。这意味着开发者可以放心地在任何生命周期状态下订阅和发送消息,而无需担心内存泄漏或崩溃问题。此外,LiveEventBus支持多种消息传递模式,包括进程内、跨进程以及跨APP通信,满足了复杂应用场景的需求。

项目技术分析

LiveEventBus的核心优势在于其基于LiveData的设计。LiveData是一种可观察的数据持有者类,与传统的观察者模式相比,它具有生命周期感知能力,能够在Activity、Fragment等组件的生命周期变化时自动管理数据订阅。LiveEventBus在此基础上进行了扩展,增加了Sticky消息支持、跨进程通信等功能,使其成为一个全面的消息总线解决方案。

项目及技术应用场景

LiveEventBus适用于多种Android开发场景:

  • 生命周期感知的消息传递:在Activity、Fragment等组件间传递消息,确保消息的及时性和安全性。
  • 跨进程通信:在需要跨进程或跨APP通信的复杂应用中,LiveEventBus提供了稳定可靠的解决方案。
  • 组件化开发:在组件化架构中,LiveEventBus可以帮助不同模块间高效通信,提升开发效率。
  • 事件驱动架构:在事件驱动的应用中,LiveEventBus可以作为事件总线,管理所有事件的发布和订阅。

项目特点

LiveEventBus的独特之处在于:

  • 生命周期感知:自动管理消息订阅,避免内存泄漏和崩溃。
  • Sticky消息支持:允许新订阅者接收之前发布的消息。
  • 跨进程通信:支持进程内、跨进程以及跨APP的消息传递。
  • 简单易用:无需复杂配置,开箱即用。
  • 支持AndroidX:与最新的Android开发环境完美兼容。
  • 延迟发送:支持消息的延迟发送,满足特定需求。
  • 多种接收模式:提供全生命周期和激活状态两种消息接收模式。

结语

LiveEventBus不仅是一个消息总线框架,它是Android开发者手中的利器,能够极大地提升开发效率和应用稳定性。无论你是初学者还是资深开发者,LiveEventBus都值得你一试。立即访问GitHub项目页面,开始你的高效开发之旅吧!


通过以上介绍,相信你已经对LiveEventBus有了全面的了解。它不仅解决了传统消息总线框架的痛点,还提供了更多强大的功能。现在就加入LiveEventBus的行列,让你的Android开发更加高效和愉快!

LiveEventBus:mailbox_with_mail:EventBus for Android,消息总线,基于LiveData,具有生命周期感知能力,支持Sticky,支持AndroidX,支持跨进程,支持跨APP项目地址:https://gitcode.com/gh_mirrors/li/LiveEventBus

作者codyer,源码ElegantBus,ElegantBus 是一款 Android 平台,基于 LivaData 的消息总线框架,这是一款非常 优雅 的消息总线框架。如果对 ElegantBus 的实现过程,以及考虑点感兴趣的可以看看前几节自吹如果只是想先使用的,可以跳过,直接到跳到使用说明和常见 LivaData 实现的 EventBus 比较消息总线使用反射入侵系统包名进程内 Sticky跨进程 Sticky跨 APP Sticky事件可配置化线程分发消息分组跨 App 安全考虑常驻事件 StickyLiveEventBus:white_check_mark::white_check_mark::white_check_mark::x::x::x::x::x::x::x:ElegantBus:x::x::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark:来龙去脉自吹ElegantBus 支持跨进程,且支持跨应用的多进程,甚至是支持跨进程间的粘性事件,支持事件管理,支持事件分组,支持自定义事件,支持同名事件等。之所以称之为最优雅的总线,是因为她不仅实现了该有的功能,而且尽量选用最合适,最轻量,最安全的方式去实现所有的细节。 更值得夸赞的是使用方式的优雅!前言随着 LifeCycle 的越来越成熟,基于 LifeCycle 的 LiveData 也随之兴起,业内基于 LiveData 实现的 EventBus 也如雨后春笋一般拔地而起。出于对技术的追求,看过了无数大牛们的实现,各位大神们思路也是出奇的神通,最基础的 LiveData 版 EventBus 其实大同小异,一个单例类管理所有的事件 LivaData 集合。如果不清楚的可以随便网上找找反正基本功能 LivaData 都支持了,实现 EventBus 只需要把所有事件管理起来就完事了。业内基于 LiveData 实现的 EventBus,其实考虑的无非就是下面提到的五个挑战,有的人考虑的少,有的人考虑的多,于是各种方案都有。ElegantBus 主要是集合各家之优势,进行全方面的考虑而产生的。五个挑战 之 路途险阻挑战一 : 粘性事件背景 LivaData 的设计之初是为了数据的获取,因此无论是观察开始之前产生的数据,还是观察开始之后产生的数据,都是用户需要的数据,只要是有数据,当 LifeCycle 处于激活状态,数据就会传递给观察者。这个我们称之为 粘性数据。 这种设计对于事件来说有时候就不那么友好了,之前的事件用户可能并不关心,只希望收到注册之后发生的事件。挑战二 : 多线程发送事件可能丢失背景 同样是因为使用场景的原因,LivaData 设计在跨线程时,使用 post 提交数据,只会保留最后一次数据提交的值,因为作为数据来说,用户只需要关心现在有的数据是什么。挑战三 : 跨进程事件总线背景 有时候我们应用需要设置多进程,不同模块可能允许在不同进程中,因为单例模式每个进程都有一份实体,所有无法达到跨进程,这时候设计 IP 方案选择。说明 这里提一下为什么不选用广播方式,对广播有一定了解的都知道,全局广播会有信息泄露,信息干扰等问题,而且开销也比较大,因此全局广播并不适合这种情况。 也许有人会说可以用本地广播,然而,本地广播目前来说并不是很好的选择。Google 官方也在 LocalBroadcastManager 的说明里面建议使用 LiveData 替代: 原文地址原文如下:2018 年 12 月 17 日版本 1.1.0-alpha01 中将弃用 androidx.localbroadcastmanager。原因LocalBroadcastManager 是应用级事件总线,在您的应用中使用了层违规行为;任何组件都可以监听来自其他任何组件的事件。 它继承了系统 BroadcastManager 不必要的用例限制;开发者必须使用 Intent,即使对象只存在且始终存在于一个进程中。由于同一原因,它未遵循功能级 BroadcastManager。 这些问题同时出现,会对开发者造成困扰。替换您可以将 LocalBroadcastManager 替换为可观察模式的其他实现。合适的选项可能是 LiveData 或被动流,具体取决于您的用例。更明显的原因是,本地广播好像并不支持跨进程~挑战四 : 跨应用(权限问题以及粘性问题)背景 跨进程相对来说还比较好实现,但是有的时候用户会有跨应用的需求,其实这个也是 IPC 范畴,为什么单独提出
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

卫颂耀Armed

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值