15

Can anybody confirm the following regarding the android application lifecycle?

1) When application is in foreground the memory will contain instance of the Application object, instances of all activities (not killed) and all the object references that are referenced from one of the root's (haven't been garbage collected)

2) When application goes to background, at some point the Android Framework can: a) Kill the whole process given to the purpose of the application which will essentialy erase all the objects from the memory b) Kill ONLY (so essentialy no other object reference will be deleted) the activities (by finishing them and in essence any fragments as well) saving their states and creating the Activities Stack and leaving anything else (Application object, any other static objects, references that are reachable from any of the roots).

I'm mostly interested in 2b, but I would appriciate confirmation on all of these points as I'm trying to grasp mentaly the whole concept from start to finish.

Lucas
  • 3,521
  • 3
  • 27
  • 39
  • If you are asking whether statements in 2a & 2b are correct, they mostly are. For 2b the OS can only call appropriate lifecycle methods and null its references to the Activities it want to be freed, and let garbage collector does its thing. However if other part of the process (i.e. user program) still hold references to these Objects then nothing will be GCed and the process may be killed to release the required memory. – Kai Dec 31 '15 at 09:59
  • Thanks for your input. Did you maybe read it somewhere in official channel or it's based on your personal developer expierience? – Lucas Jan 04 '16 at 10:02
  • it's how Java works, Activites are just standard Java objects, and the virtual machine does not deallocate an object while it's still being used. This is why Drawables should not be cached (it has references to the owner context/Activity), and why there's a lint check to make sure a Handler subclass is a static class (to prevent the all too easy Activity leak) – Kai Jan 04 '16 at 20:35
  • 2
    please check this link http://developer.android.com/training/basics/activity-lifecycle/index.html – Krunal Patel Jan 05 '16 at 11:10

6 Answers6

4

If you are looking for official confirmation then better ask Google only :).

but i feel after reading this you will get a better understanding of these concept.

Android memory management

android process lifecycle

Answer for 1st question: yes confirm using DDMS.

answer for 2a question: yes OS can kill process any point of time when needed memory for other process which will result into killing all object related to process.

answer for 2b questiong:

From official documentation

Process Lifecycle 3. A background activity (an activity that is not visible to the user and has been paused) is no longer critical, so the system may safely kill its process to reclaim memory for other foreground or visible processes. If its process needs to be killed, when the user navigates back to the activity (making it visible on the screen again), its onCreate(Bundle) method will be called with the savedInstanceState it had previously supplied in onSaveInstanceState(Bundle) so that it can restart itself in the same state as the user last left it.

Community
  • 1
  • 1
CodingRat
  • 1,934
  • 3
  • 23
  • 43
  • Thanks for the link! It was a nice overview, but the problem is it doesn't really answer for 2b as my question was asking about activities alone (and not the whole process). ps. Thanks for the anser to other points. – Lucas Jan 04 '16 at 10:05
  • Although I didn't get the exact answer to my 2b question (the thing is the system will not kill activities selectively as explained by Dianne Hackborn, but only will kill them all or none), neighter anybody else, I must be fair and so because your answer was the most helpful to me the bounty goes to you. Thanks. – Lucas Jan 08 '16 at 08:46
4

Yes you are mostly correct about 2b).

If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process.

However there are instances where onSaveInstantSate isn't called:

Note that it is important to save persistent data in onPause() instead of onSaveInstanceState(Bundle) because the latter is not part of the lifecycle callbacks, so will not be called in every situation as described in its documentation.

Android Docs Source

You can request android to always destroy activities on background by enabling the following developer option. If you are debugging your app you should be able to step through the life cycle methods and see what is happening.

Settings -> Developer options -> Apps -> Don't keep activities

Jim Baca
  • 6,112
  • 2
  • 24
  • 30
4

There is no typical life-cycle for application exists. Application object lives in memory until it is not being killed either by Android itself or by manually by user.

For the above points, here are your answers:

1) This is true.

2) a) That is also true. 2) b) When application goes background, you can only save the data of the current activity that was in foreground. Also, when you kill the application it self (by removing it from recent list), all the activities in the app stack and their saved data (not persistent data) got killed as application is the base for all the activities.

Geeky Singh
  • 1,003
  • 9
  • 20
4

1) When application is in foreground the memory will contain instance of the Application object, instances of all activities (not killed) and all the object references that are referenced from one of the root's (haven't been garbage collected)

> There will only ever be a few such processes in the system, and these
> will only be killed as a last resort if memory is so low that not even
> these processes can continue to run. Generally, at this point, the
> device has reached a memory paging state, so this action is required
> in order to keep the user interface responsive.

2) When application goes to background, at some point the Android Framework can:

.

a) Kill the whole process given to the purpose of the application which will essentialy erase all the objects from the memory

> These processes have no direct impact on the user experience. Provided
> they implement their Activity life-cycle correctly (see Activity for
> more details), the system can kill such processes at any time to
> reclaim memory for one of the three previous processes types. Usually
> there are many of these processes running, so they are kept in an LRU
> list to ensure the process that was most recently seen by the user is
> the last to be killed when running low on memory.

b) Kill ONLY (so essentialy no other object reference will be deleted) the activities (by finishing them and in essence any fragments as well) saving their states and creating the Activities Stack and leaving anything else (Application object, any other static objects, references that are reachable from any of the roots).

Partially as in point 2.a.'s explanation

> Usually there are many of these processes running, so they are kept in an LRU
> list to ensure the process that was most recently seen by the user is
> the last to be killed when running low on memory.

Source - developer.android.com

Viral Patel
  • 32,418
  • 18
  • 82
  • 110
0

Well this thing depends upon how Android OS operates. Android Device is an embedded System but works almost same as a PC and when I say Android as an OS, it will definetely have all the features of an OS. The thing which you are pointing upon is the Memory Management and Scheduling feature of Android OS. MMU(Memory Management Unit) logically give preference to currently executing task i.e ur launcher or any other Application which u r working upon. Two things I want to answer which can help u bit more:

  1. Views (whether xml generated or Javacode generated, they are dynamically generated.).
  2. Android OS runs all apps as a process with sub processes(Activities) on a Dalvik Virtual Machine.
  3. All your Activities before they are created they are null, when they are created then their instance is generated. Upon opening them again their saved instance is again viewd(Concept of Singleton Design Pattern).

So let me tell you that I don't think that both of the options are right. What I beleive is following: 1. View will always be generated dynamically. 2. Instance will be saved in Memory. 3. On background going of Application the whole process with instances available will be their in Memory.

Developer Hayat
  • 1
0

Ok, during my search quest in recent weeks I was able to get some more information and now I can answer my own (and hopefully for others) questions:

1) Correct

2a) Correct

2b) False. The android framework, if in need of memory or if due to some other reason it has to "kill/reduce" the application it can do so only by killing the whole process that is dedicated to that application. The android framework can neighter kill chosen activity(ies) or kill all activities but leave all other objects alive (like Application object, singletons etc.)

Lucas
  • 3,521
  • 3
  • 27
  • 39