Detailed Android Activity Lifecycle (onattachedtowindow())

I'm interested in android activity lifecycle and I would like to get more detailed description/documentation/reference than widely available basic (onCreate->onStart->onResum

Solution 1:

My guess for why that feels more responsive, off the top of my head: I think that if you start Activity B from activity A's onCreate(), Activity A isn't drawn before activity B starts, which may take another second or two (making the app feel less responsive), where if you start activity B in Activity A's onAttachedToWindow(), A is started and rendered before B is kicked off, so the user doesn't have to sit for a second with a blank screen or the pre-A activity before seeing a reaction to their action.

Solution 2:

1. When the activity is launched, the onCreate() method is called. In the onCreate() method you perform basic startup logic that should happen only once for the entire life of the activity.

2. After onCreate() is executed, the onStart() method is called. This method makes the activity visible as the app prepares the activity to enter the foreground and become interactive.

3. After onStart() is executed, the onResume() method is called. This method is called only when the app is in the foreground because this is the state in which the app interacts with the user. The app stays in the resumed (or running) state until something happens to take focus away from the app.

4. If another activity comes into the foreground, the onPause() method is called. The app is paused if it is still visible. This method only pauses the operations of the activity. It does not destroy. The activity remains in the paused state until either the activity resumes or becomes completely invisible to the user. 4a. If the user returns to the activity, the onResume() method is called again. 4b. the app process can be killed from the paused state if apps with higher priority need memory. If the user needs to return to app after it is killed, the onCreate() method is called again

5. If the activity is no longer visible to the user, the onStop() method is called. When the activity is stopped, the activity object is kept in memory and maintains all state and information but is not attached to the window manager. 5a. if the user returns to the activity, the onRestart() method is called, followed by the onStart() method again. 5b. the app process can be killed from the stopped state if apps with higher priority need memory. If the user needs to return to the app after it is killed, the onCreate() method is called again.

6. If the activity is finishing or being killed by the system, the onDestroy() method is called. The app is not initially shut down. The system either calls this method because the activity is finishing due to someone’s calling finish(), or because the system is temporarily destroying the process containing the activity to save space. The system may also call this method when an orientation change occurs, and then immediately call onCreate() to recreate the process (and the components that it contains) in the new orientation. The onDestroy() method releases all resources that have not yet been released by earlier methods such as onStop().

The entire lifetime of an activity happens between the first call to onCreate() through a single final call to onDestroy().

The visible lifetime of an activity happens between a call to onStart() until a call to onStop().

The foreground lifetime of an activity happens between a call to onResume() until a call to onPause().

The only method we must implement is onCreate(). The others are called automatically. But we can implement them ourselves to tell the app what to do during those processes.

https://developer.android.com/guide/components/activities/activity-lifecycle.html#asem

onAttachedToWindow is called when the view is attached to a window. At this point it has a Surface and will start drawing.

https://developer.android.com/reference/android/view/View.html#onAttachedToWindow()