Procesos y el ciclo de vida de la app
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En la mayoría de los casos, cada aplicación para Android ejecuta su propio proceso de Linux.
Este proceso se crea para la aplicación cuando es necesario ejecutar parte de su código, y seguirá ejecutándose hasta que el sistema necesite recuperar su memoria para que la usen otras aplicaciones y ya no sea necesario.
Una característica poco común y fundamental de Android es que la duración del proceso de una aplicación no se controla directamente desde la aplicación.
En su lugar, el sistema la determina mediante una combinación de las partes de la aplicación que el sistema sabe que se están ejecutando, la importancia de estas para el usuario y la cantidad total de memoria disponible en el sistema.
Es importante que los desarrolladores de aplicaciones comprendan cómo los diferentes componentes de la aplicación (en especial Activity, Service y BroadcastReceiver) afectan la duración del proceso de la aplicación. Si estos componentes no se usan correctamente, el sistema puede eliminar el proceso de la aplicación mientras realiza una tarea importante.
Un ejemplo común de un error del ciclo de vida del proceso es un BroadcastReceiver que inicia un subproceso cuando recibe un Intent en su método BroadcastReceiver.onReceive() y, luego, regresa de la función. Una vez que regresa, el sistema considera que el BroadcastReceiver ya no está activo y que su proceso de hosting ya no es necesario, a menos que otros componentes de la aplicación estén activos en él.
Por lo tanto, el sistema puede eliminar el proceso en cualquier momento para recuperar memoria y, al hacerlo, finaliza el subproceso generado que se está ejecutando en el proceso. Una solución común a este problema es programar un JobService desde el BroadcastReceiver para que el sistema sepa que hay trabajo activo en el proceso.
Para determinar qué procesos finalizar cuando hay poca memoria, Android coloca cada proceso en una jerarquía de importancia basada en los componentes que se ejecutan en ellos y el estado de esos componentes. En orden de importancia, estos son los tipos de procesos:
- Un proceso en primer plano es uno que se requiere para lo que el usuario está haciendo actualmente. Varios componentes de la aplicación pueden hacer que el proceso que los contiene se considere en primer plano de diferentes maneras. Un proceso se considera en primer plano si se cumple alguna de las siguientes condiciones:
Solo hay unos pocos procesos de este tipo en el sistema, y solo se eliminan como último recurso si la memoria es tan baja que ni siquiera estos pueden continuar ejecutándose. Por lo general, si esto sucede, el dispositivo alcanzó un estado de paginación de memoria, por lo que esta acción es necesaria para que la interfaz de usuario responda.
- Un proceso visible realiza una tarea sobre la que el usuario tiene conocimiento, por lo que su eliminación tiene un impacto negativo notable en la experiencia del usuario. Un proceso se considera visible en las siguientes condiciones:
- Ejecuta una
Activity que es visible para el usuario en pantalla, pero no en primer plano (se llamó a su método onPause()). Esto puede ocurrir, por ejemplo, si el Activity en primer plano se muestra como un diálogo que permite ver el Activity anterior detrás de él.
- Tiene un
Service que se ejecuta como servicio en primer plano por medio de Service.startForeground() (que le pide al sistema que trate el servicio como algo que el usuario conoce o que es esencialmente visible para este).
- Aloja un servicio que el sistema usa para una función que el usuario conoce, como un fondo animado o un servicio de método de entrada.
La cantidad de procesos que se ejecutan en el sistema es menos limitada que los procesos en primer plano, pero aún está relativamente controlada. Estos procesos se consideran sumamente importantes y no se eliminan a menos que sea necesario para mantener en ejecución todos los procesos en primer plano.
- Un proceso de servicio es aquel que contiene un
Service que se inició con el método startService(). Aunque el usuario no puede ver estos procesos directamente, por lo general, realizan acciones que le interesan (como la carga o descarga de datos de red en segundo plano), por lo que el sistema siempre mantiene estos procesos en ejecución, a menos que no haya suficiente memoria para retener todos los procesos en primer plano y visibles.
Es posible que se descienda el nivel de importancia de los servicios que han estado ejecutándose por un tiempo prolongado (como 30 minutos o más) para permitir que sus procesos se incluyan en la lista almacenada en caché.
Los procesos que sí deben ejecutarse durante un período prolongado se pueden crear con setForeground.
Si se trata de un proceso periódico que requiere un tiempo de ejecución estricto, se puede programar a través de AlarmManager.
Para obtener más información, consulta Compatibilidad con trabajadores de larga duración.
De esta manera, se evitan situaciones en las que los servicios de larga duración que usan recursos excesivos, por ejemplo, a través de pérdidas de memoria, impiden que el sistema proporcione una buena experiencia del usuario.
- Un proceso almacenado en caché es uno que no se necesita actualmente, por lo que el sistema puede eliminarlo cuando lo desee si se necesitan recursos como la memoria en otra parte. En un sistema con comportamiento normal, estos son los únicos procesos involucrados en la administración de recursos.
Un sistema que funciona bien tiene varios procesos almacenados en caché siempre disponibles, para que la alternancia entre aplicaciones sea eficiente, y finaliza las apps almacenadas en caché con regularidad según sea necesario.
Solo en situaciones muy críticas el sistema llega a un punto en el que todos los procesos almacenados en caché se eliminan y debe comenzar a eliminar los procesos del servicio.
Dado que el sistema puede finalizar los procesos almacenados en caché en cualquier momento, las apps deben dejar de funcionar mientras se encuentran en ese estado. Si la app debe realizar un trabajo fundamental para el usuario, debe usar una de las APIs anteriores para ejecutar el trabajo desde un estado de proceso activo.
Los procesos almacenados en caché suelen contener una o más instancias de una Activity que el usuario no puede ver en este momento (se llamó y se mostró su método onStop()).
Siempre que implementen su ciclo de vida de Activity correctamente cuando el sistema mate esos procesos, no afectará la experiencia del usuario cuando vuelva a esa app. Puede restablecer el estado guardado anteriormente cuando la actividad asociada se vuelva a crear en un proceso nuevo. Ten en cuenta que no se garantiza que se llame a onDestroy() en el caso de que el sistema cierre un proceso.
Para obtener más información, consulta Activity.
A partir de Android 13, un proceso de la app puede recibir un tiempo de ejecución limitado o no hasta que ingrese a uno de los estados de ciclo de vida activo anteriores.
Los procesos almacenados en caché se mantienen en una lista. La política de orden exacta de esta lista es un detalle de implementación de la plataforma. Por lo general, intenta mantener los procesos más útiles, como los que alojan la aplicación principal del usuario o la última actividad que vio, antes de otros tipos de procesos. También se pueden aplicar otras políticas para eliminar procesos, como establecer límites más restrictivos en la cantidad de procesos permitidos o limitar la cantidad de tiempo que un proceso puede permanecer almacenado en caché de manera continua.
Cuando se decide cómo clasificar un proceso, el sistema basa su decisión en el nivel más importante que se encuentra entre todos los componentes actualmente activos en el proceso.
Consulta la documentación de Activity, Service y BroadcastReceiver para obtener más detalles sobre cómo cada uno de estos componentes contribuye al ciclo de vida general de un proceso y de la aplicación.
La prioridad de un proceso también puede aumentar en función de otras dependencias que tenga un proceso. Por ejemplo, si el proceso A está vinculado a un Service con la marca Context.BIND_AUTO_CREATE o usa un ContentProvider en el proceso B, la clasificación del proceso B siempre será al menos tan importante como la del proceso A.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-07-27 (UTC)"],[],[],null,["# Processes and app lifecycle\n\nIn most cases, every Android application runs in its own Linux process.\nThis process is created for the application when some of its code needs to\nrun and remains running until the system needs to reclaim its memory for use\nby other applications and it is no longer needed.\n\nAn unusual and fundamental feature of Android is that an application process's\nlifetime *isn't* directly controlled by the application itself.\nInstead, it is determined by the system through a combination of the parts of the application\nthat the system knows are running, how important these things are to the user,\nand how much overall memory is available in the system.\n\nIt is important that\napplication developers understand how different application components\n(in particular [Activity](/reference/android/app/Activity), [Service](/reference/android/app/Service),\nand [BroadcastReceiver](/reference/android/content/BroadcastReceiver)) impact the lifetime\nof the application's process. **Not using these components correctly can\nresult in the system killing the application's process while it is doing\nimportant work.**\n\nA common example of a process lifecycle bug is a\n`BroadcastReceiver` that starts a thread when it\nreceives an `Intent` in its [BroadcastReceiver.onReceive()](/reference/android/content/BroadcastReceiver#onReceive(android.content.Context, android.content.Intent))\nmethod and then returns from the function. Once it returns, the system\nconsiders the `BroadcastReceiver` to no longer be active, and its hosting\nprocess to no longer be needed, unless other application components are active in\nit.\n\n\nSo, the system can kill the process at any time to reclaim memory, and in doing so,\nit terminates the spawned thread running in the process. The solution to this problem\nis typically to schedule a [JobService](/reference/android/app/job/JobService)\nfrom the `BroadcastReceiver` so the\nsystem knows that there is active work occurring in the process.\n\nTo determine which processes to kill when low on memory, Android\nplaces each process into an importance hierarchy based on the components running in\nthem and the state of those components. In order of importance, these process types are:\n\n1. A **foreground process** is one that is required for what the user is currently doing. Various application components can cause its containing process to be considered foreground in different ways. A process is considered to be in the foreground if any of the following conditions hold:\n - It is running an [Activity](/reference/android/app/Activity) at the top of the screen that the user is interacting with (its [onResume()](/reference/android/app/Activity#onResume()) method has been called).\n - It has a [BroadcastReceiver](/reference/android/content/BroadcastReceiver) that is currently running (its [BroadcastReceiver.onReceive()](/reference/android/content/BroadcastReceiver#onReceive(android.content.Context, android.content.Intent)) method is executing).\n - It has a [Service](/reference/android/app/Service) that is currently executing code in one of its callbacks ([Service.onCreate()](/reference/android/app/Service#onCreate()), [Service.onStart()](/reference/android/app/Service#onStart(android.content.Intent, int)), or [Service.onDestroy()](/reference/android/app/Service#onDestroy())).\n2. There are only ever a few such processes in the system, and these are only killed as a last resort if memory is so low that not even these processes can continue to run. Generally, if this happens the device has reached a memory paging state, so this action is required to keep the user interface responsive.\n3. A **visible process** is doing work that the user is currently aware of, so killing it has a noticeable negative impact on the user experience. A process is considered visible in the following conditions:\n - It is running an [Activity](/reference/android/app/Activity) that is visible to the user on-screen but not in the foreground (its [onPause()](/reference/android/app/Activity#onPause()) method has been called). This might occur, for example, if the foreground `Activity` is displayed as a dialog that lets the previous `Activity` be seen behind it.\n - It has a [Service](/reference/android/app/Service) that is running as a foreground service, through [Service.startForeground()](/reference/android/app/Service#startForeground(int, android.app.Notification)) (which asks the system to treat the service as something the user is aware of, or essentially as if it were visible).\n - It is hosting a service that the system is using for a particular feature that the user is aware of, such as a live wallpaper or an input method service.\n\n The number of these processes running in the system is less bounded than foreground\n processes, but still relatively controlled. These processes are\n considered extremely important and aren't killed unless doing so is\n required to keep all foreground processes running.\n4. A **service process** is one holding a [Service](/reference/android/app/Service) that has been started with the [startService()](/reference/android/content/Context#startService(android.content.Intent)) method. Though these processes are not directly visible to the user, they are generally doing things that the user cares about (such as background network data upload or download), so the system always keeps such processes running unless there is not enough memory to retain all foreground and visible processes.\n\n Services that have been running for a long time (such as 30 minutes or more) might be\n demoted in importance to let their process drop to the cached list.\n\n Processes that do need to be run over a long period can be created with\n [setForeground](/reference/kotlin/androidx/work/CoroutineWorker#setForeground(androidx.work.ForegroundInfo)).\n If it is a periodic process that requires strict time of execution, it can be\n scheduled through the [AlarmManager](/reference/android/app/AlarmManager).\n For more information, refer to [Support for long-running workers](/topic/libraries/architecture/workmanager/advanced/long-running).\n This helps avoid situations where long-running services that use excessive resources, for\n example, by leaking memory, prevent the system from delivering a good user experience.\n5. A **cached process** is one that is not currently needed, so the system is free to kill it as needed when resources like memory are needed elsewhere. In a normally behaving system, these are the only processes involved in resource management.\n\n \u003cbr /\u003e\n\n A well-running system has multiple cached processes always available, for efficient\n switching between applications, and regularly kills the cached apps as needed.\n Only in very critical situations does the system get to a point where\n all cached processes are killed and it must start killing service processes.\n\n Since cached processes can be killed by the system at any time, apps should cease all work while\n in the cached state. If user-critical work must be performed by the app,\n it should use one of the above APIs to run work from an active process state.\n\n Cached processes often hold one or more [Activity](/reference/android/app/Activity) instances\n that are not currently visible to the user (their\n [onStop()](/reference/android/app/Activity#onStop()) method has been called and has returned).\n Provided they implement their `Activity` lifecycle correctly when the system\n kills such processes, it doesn't impact the user's experience when returning to that app.\n It can restore the previously saved state when the associated activity recreates in\n a new process. Be aware that [onDestroy()](/guide/components/activities/activity-lifecycle#ondestroy)\n is not guaranteed to be called in the case that a process is killed by the system.\n For more details, see [Activity](/reference/android/app/Activity).\n\n Starting in Android 13, an app process may receive limited or no execution time until it enters\n one of the above active lifecycle states.\n\n Cached processes are kept in a list. The exact ordering policy for this list\n is an implementation detail of the platform. Generally, it tries to keep more\n useful processes, such as those hosting the user's home application or the last activity the user saw,\n before other types of processes. Other policies for killing processes can also\n be applied, like setting hard limits on the number of processes allowed or limiting the amount of\n time a process can stay continually cached.\n\nWhen deciding how to classify a process, the system bases its decision on the most\nimportant level found among all the components currently active in the process.\nSee the [Activity](/reference/android/app/Activity), [Service](/reference/android/app/Service), and\n[BroadcastReceiver](/reference/android/content/BroadcastReceiver) documentation for more detail on how\neach of these components contributes to the overall lifecycle of a process and of\nthe application.\n\nA process's priority might also be increased based on other dependencies\na process has to it. For example, if process A has bound to a\n[Service](/reference/android/app/Service) with\nthe [Context.BIND_AUTO_CREATE](/reference/android/content/Context#BIND_AUTO_CREATE)\nflag or is using a\n[ContentProvider](/reference/android/content/ContentProvider) in process B, then process B's\nclassification is always at least as important as process A's."]]
