3.2. Knowing the Activity lifecycle

Much like processes, activities don’t get to hang around forever and suck up memory and CPU cycles. Even within a process, with multiple activities associated to the same application, some activities will be in the foreground and others won’t. Those in the foreground, the ones the user is working with, get the priority. Other activities may be stopped when the platform needs to reclaim resources (or killed if the process hosting them is itself killed, based on the hierarchy we discussed in the previous section).

Users aren’t supposed to notice any of the process and activity swapping that the platform does. To them the entire workflow of any task they want to perform should be seamless. If some activities are created new, and some are restored from an inactive state, the user doesn’t care and shouldn’t notice.