2

I have a Service, which is foreground. It is locally bound to one (or more) activity, so the activity and the service runs in the same process. There might be some time during which the activity is not displayed (typical music player use case).

If service and activity are in the same process, the memory for the activity can't be repossessed by operating system, unless the service too is terminated? The answer seems yes to me, according to this article

If the last is true, should I create two separate process:

  • To be nice to the system/other apps?
  • to be more confident my service will not be killed?

Or, it is not a big deal to have the activity sticking around together with the service?

DevelopingChris
  • 39,797
  • 30
  • 87
  • 118
Paolo
  • 2,461
  • 5
  • 31
  • 45

1 Answers1

3

I have a Service, which is foreground. It is locally bound to one (or more) activity, so the activity and the service runs in the same process. There might be some time during which the activity is not displayed (typical music player use case).

A "typical music player use case" would not use bindService() IMHO. A foreground service would not use bindService() IMHO. At minimum, in addition to bindService() for activity->service communication, you would need startService(), so that after you unbindService() (e.g., user presses BACK), the service can stay running.

If service and activity are in the same process, the memory for the activity can't be repossessed by operating system, unless the service too is terminated?

The memory for the activity is never "repossessed by the operating system", except by terminating your entire process. Unfortunately, this is not entirely clear from the documentation.

If the user pressed BACK to exit the activity, or you otherwise call finish() on the activity, the activity should be garbage-collected, assuming nothing is causing it to hang around (e.g., referred to by a static data member).

should I create two separate process

Absolutely not.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thanks for your reply. I'm still a bit confused on one point. If the activity is garbage collected I suppose the `free()` will be called the memory block(s) it occupied. If so the memory is indeed "repossessed" by the os (or maybe given back by the application, I may have chosen a wrong word, I am not a native English speaker) to the os. While you wrote "The memory for the activity is never repossessed by the operating system, except by terminating your entire process." – Paolo Nov 28 '11 at 15:33
  • @Paolo: "If the activity is garbage collected I suppose the free() will be called the memory block(s) it occupied." -- unlikely. That is not how most garbage collected environments work. The memory is available for future allocations within the virtual machine. – CommonsWare Nov 28 '11 at 15:37
  • Does this mean that without special precautions, a background service will always cause "unused" activities to be kept in memory if the uses presses "home" instead of "back" to leave an application? Is it a good idea to manually call finish() on activities that haven't been used for a while when the app is not visible? – lxgr Mar 05 '14 at 11:54
  • @lxgr: "Does this mean that without special precautions, a background service will always cause "unused" activities to be kept in memory if the uses presses "home" instead of "back" to leave an application?" -- yes. This is by design. "Is it a good idea to manually call finish() on activities that haven't been used for a while when the app is not visible?" -- you are welcome to listen for `onTrimMemory()` and try to "tighten your belt" then. However, don't screw up the user nagivation for if they *do* return to your app. – CommonsWare Mar 05 '14 at 12:25
  • 1
    Is there a way to "make Android destroy" an activity, so that the next time it is created, Android hands us its state in the onCreate method? – lxgr Mar 05 '14 at 18:03
  • 1
    @lxgr: Not that I can think of, sorry. – CommonsWare Mar 06 '14 at 00:27