事件总线库机制是否与使用静态变量在活动之间传递数据一样糟糕？
Is event bus library mechanism as bad as the use of static variables to pass data between activities?
我正在学习 Android，据我所知，在 Activity 之间传递数据的标准 Android 机制正在使用 Intents，而 Intents 又在较低级别上作为 IPC 实现（也许我错了).
似乎最近出现了一堆库，使 Android 开发人员的生活更轻松。在它们之间，有著名的 Event Bus（Greenrobot 的，Square 的 Otto）。我一直在尝试这两种方法（几乎精确的接口语义），并且已经看到一些关于如何使用 Greenrobot 事件总线将 post 事件转换为 activity 的 posts using .postSticky 允许在新 activity 准备好获取此数据时使用或拉取事件。
但是从我现在的理解来看，使用 Intents 的主要目的（以及因此在处理复杂对象时使用 serializable/parcelable 对象的繁琐工作）是允许 Android 重新创建这个由于资源限制，系统终止应用程序后的数据，通常是当您切换到另一个应用程序并开始玩游戏时。因此，在这种情况下，当您切换回您的应用程序时，您会在使用事件总线传递的数据上得到 NULL 指针。
我是不是遗漏了什么？或者只是这种方法（将数据传递给活动的事件总线），即使代码非常干净，也是完全错误的？
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的一个特点。我不会将其描述为 "the primary aim of using Intents"。使用 Intents 的主要目的是能够调用功能（例如，启动 activity）而不考虑该功能是否在您当前的进程中执行，您的一些单独的进程，在其他一些 运行 应用程序的进程，或者在一些尚不存在的进程中（因为有问题的应用程序目前不是 运行）。
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.
不，您只是在注册侦听器时没有收到事件。只要你的代码能处理那种情况，这里就没有问题。
Or simply this approach (event bus to pass data to activities), even very clean on code, is completely wrong?
我不推荐这种方法。话虽如此，恕我直言，它也不是 "completely wrong"。 "Completely wrong" 表示无法使用该技术创建功能正常的 Android 应用程序。 Android 应用程序有广泛的用例，因此有些应用程序即使在孤立的情况下也可以使用这种技术生存。并且，在某些情况下，将此技术与其他内容（例如，数据持久性）结合使用可能会非常好。
postSticky() 只是一个绑定到事件总线的内存缓存。缓存是许多 Android 应用程序的重要组成部分，用于最大程度地减少重复磁盘或网络 I/O。只要 postSticky() 仅用作内存缓存，应用程序就不会遇到麻烦。依赖于 postSticky() 幸存进程终止 的应用程序有 麻烦，尽管这不是 postSticky() 独有的，而是内存缓存的普遍问题。依赖 任何 种内存中缓存幸存进程终止的应用程序有麻烦。
我正在学习 Android，据我所知，在 Activity 之间传递数据的标准 Android 机制正在使用 Intents，而 Intents 又在较低级别上作为 IPC 实现（也许我错了).
似乎最近出现了一堆库，使 Android 开发人员的生活更轻松。在它们之间，有著名的 Event Bus（Greenrobot 的，Square 的 Otto）。我一直在尝试这两种方法（几乎精确的接口语义），并且已经看到一些关于如何使用 Greenrobot 事件总线将 post 事件转换为 activity 的 posts using .postSticky 允许在新 activity 准备好获取此数据时使用或拉取事件。
但是从我现在的理解来看，使用 Intents 的主要目的（以及因此在处理复杂对象时使用 serializable/parcelable 对象的繁琐工作）是允许 Android 重新创建这个由于资源限制，系统终止应用程序后的数据，通常是当您切换到另一个应用程序并开始玩游戏时。因此，在这种情况下，当您切换回您的应用程序时，您会在使用事件总线传递的数据上得到 NULL 指针。
我是不是遗漏了什么？或者只是这种方法（将数据传递给活动的事件总线），即使代码非常干净，也是完全错误的？
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的一个特点。我不会将其描述为 "the primary aim of using Intents"。使用 Intents 的主要目的是能够调用功能（例如，启动 activity）而不考虑该功能是否在您当前的进程中执行，您的一些单独的进程，在其他一些 运行 应用程序的进程，或者在一些尚不存在的进程中（因为有问题的应用程序目前不是 运行）。
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.
不，您只是在注册侦听器时没有收到事件。只要你的代码能处理那种情况，这里就没有问题。
Or simply this approach (event bus to pass data to activities), even very clean on code, is completely wrong?
我不推荐这种方法。话虽如此，恕我直言，它也不是 "completely wrong"。 "Completely wrong" 表示无法使用该技术创建功能正常的 Android 应用程序。 Android 应用程序有广泛的用例，因此有些应用程序即使在孤立的情况下也可以使用这种技术生存。并且，在某些情况下，将此技术与其他内容（例如，数据持久性）结合使用可能会非常好。
postSticky() 只是一个绑定到事件总线的内存缓存。缓存是许多 Android 应用程序的重要组成部分，用于最大程度地减少重复磁盘或网络 I/O。只要 postSticky() 仅用作内存缓存，应用程序就不会遇到麻烦。依赖于 postSticky() 幸存进程终止 的应用程序有 麻烦，尽管这不是 postSticky() 独有的，而是内存缓存的普遍问题。依赖 任何 种内存中缓存幸存进程终止的应用程序有麻烦。