事件总线库机制是否与使用静态变量在活动之间传递数据一样糟糕? [英] Is event bus library mechanism as bad as the use of static variables to pass data between activities?

问题描述

我正在学习Android和AFAIK，在Activity之间传递数据的标准Android机制是使用Intent，这些Intent在较低级别上又作为IPC实现(也许我错了).

I'm learning Android, and AFAIK, the standard Android mechanism to pass data between Activities is using Intents which in turn are implemented as IPC on lower level (maybe I'm wrong).

似乎最近出现了许多库，以使Android开发人员的生活更轻松.在它们之间，是著名的Event Bus(Greenrobot的一辆，Square的Otto).我一直在尝试这两种方法(几乎完全是接口语义)，并且看到了一些有关如何使用Greenrobot事件总线使用.postSticky将事件发布到活动的帖子，当该活动被使用时，它可以在新活动中使用或提取事件.准备获取此数据.

It seems that recently have emerged a bunch of libraries to make life easier to Android devs. Between them, the famous Event Bus (Greenrobot's one, Square's Otto). I've been trying both (almost exact interface semantics) and have seen some posts around on how to use Greenrobot event bus to post events to an activity using .postSticky which allows to consume or pull the event on the new activity when this one is ready to fetch this data.

但是根据我的理解，使用Intents的主要目的(以及在处理复杂对象时使用可序列化/可打包对象的繁琐工作)的主要目的是允许Android在系统终止应用程序后重新创建此数据.受资源限制，通常是当您切换到另一个应用程序并开始玩耍时.因此，在这种情况下，当您切换回应用程序时，会在使用事件总线传递的数据上获得 NULL指针.

But from my understanding since now, the primary aim of using Intents (and therefore the tedious work of using serializable/parcelable objects when you deal with complex objects) is to allow Android to recreate this data after the system kills the app due to resources constraints, usually when you switch to another app and start playing around. So when in this situation, when you switch back to yor app, you get NULL pointer on the data that was passed using event bus.

我缺少什么吗?或者只是这种方法(事件总线将数据传递给活动)，甚至在代码上非常干净，也是完全错误的吗?

Do I am missing something? Or simply this approach (event bus to pass data to activities), even very clean on code, is completely wrong?

推荐答案

使用Intents(因此在处理复杂对象时使用可序列化/可打包对象的繁琐工作)的主要目的是允许Android在系统由于资源限制而终止应用程序后重新创建此数据，通常是在您切换到另一个应用并开始试玩

the primary aim of using Intents (and therefore the tedious work of using serializable/parcelable objects when you deal with complex objects) is to allow Android to recreate this data after the system kills the app due to resources constraints, usually when you switch to another app and start playing around

这是Android的功能.我不会将其描述为使用Intent的主要目的".使用Intents的主要目的是能够调用功能(例如，启动活动)，而无需考虑该功能是在您当前的流程，您的某个独立流程，在其他正在运行的应用程序的流程中执行还是在某些流程中执行尚不存在的进程(因为该应用目前未运行).

That is a feature of Android. I would not describe it as "the primary aim of using Intents". The primary aim of using Intents is to be able to invoke functionality (e.g., start an activity) without regards to whether that functionality executes in your current process, some separate process of yours, in some other running app's process, or in some process that does not yet exist (because the app in question is not running at the moment).

因此，在这种情况下，当您切换回应用程序时，将在使用事件总线传递的数据上获得NULL指针.

So when in this situation, when you switch back to yor app, you get NULL pointer on the data that was passed using event bus.

否，注册侦听器时只是没有事件.只要您的代码可以处理这种情况，这里就没有问题.

No, you just do not get an event when you register your listener. So long as your code can handle that situation, there is no problem here.

或者仅仅是这种方法(事件总线将数据传递给活动)，即使代码很干净，也是完全错误的吗?

Or simply this approach (event bus to pass data to activities), even very clean on code, is completely wrong?

我不推荐这种方法.话虽如此，恕我直言，这也不是完全错误的". 完全错误"表示使用该技术无法创建功能正常的Android应用. Android应用程序具有广泛的用例，因此即使单独使用，某些应用程序也可能能够生存.而且，在某些情况下，将该技术与其他内容(例如数据持久性)结合使用可能会很好.

I would not recommend the approach. That being said, IMHO, it is not "completely wrong" either. "Completely wrong" would indicate that it is impossible to create a properly-functioning Android app using the technique. Android apps have a wide range of use cases, and so some might be able to survive using this technique even in isolation. And, using this technique in combination with other stuff (e.g., data persistence) may be perfectly fine in some cases.

postSticky()只是绑定到事件总线的内存中缓存.缓存是许多Android应用程序的重要组成部分，可最大程度地减少重复的磁盘或网络I/O.只要postSticky()仅用作内存缓存，应用程序就不会遇到麻烦.尽管postSticky()并非唯一于postSticky()，但依赖于postSticky()仍在进程终止中生存的应用程序遇到了麻烦.是内存缓存的一个普遍问题.依赖任何种类的内存缓存并在进程终止后继续运行的应用程序会遇到麻烦.

postSticky() is simply an in-memory cache tied into an event bus. Caching is an important part of many Android apps, to minimize repetitious disk or network I/O. So long as postSticky() is only used as an in-memory cache, apps should not get into trouble. Apps that rely upon postSticky() surviving process termination are in trouble, though that is not unique to postSticky(), but rather is a general issue with in-memory caches. Apps that rely upon any sort of in-memory cache surviving process termination are in trouble.

这篇关于事件总线库机制是否与使用静态变量在活动之间传递数据一样糟糕?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！