问题
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).
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.
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?
回答1:
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
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).
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?
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() 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.
来源：https://stackoverflow.com/questions/36936993/is-event-bus-library-mechanism-as-bad-as-the-use-of-static-variables-to-pass-dat