Comparación de un servicio local, en proceso, de clase base ✱ con un AsyncTask
:
✱ (Esta respuesta no aborda los servicios exportados, o cualquier servicio que se ejecute en un proceso diferente al del cliente, ya que los casos de uso esperados difieren sustancialmente de los de un AsyncTask
. Además, en aras de la brevedad, la naturaleza de ciertos servicios especializados Service
las subclases (p. ej. IntentService
, JobService
) se ignorarán aquí).
Proceso de por vida
A Service
representa, para el sistema operativo, "el deseo de una aplicación de realizar una operación de ejecución más larga sin interactuar con el usuario" [ ref ].
Mientras tiene una Service
ejecución, Android comprende que no desea que se elimine su proceso. Esto también es cierto cuando tiene un en Activity
pantalla, y es especialmente cierto cuando ejecuta un servicio en primer plano . (Cuando todos los componentes de su aplicación desaparecen, Android piensa: "Oh, ahora es un buen momento para eliminar esta aplicación, así puedo liberar recursos").
Además, dependiendo del último valor de retorno de Service.onCreate()
, Android puede intentar "revivir" aplicaciones / servicios que fueron eliminados debido a la presión de recursos [ ref ].
AsyncTasks
no hagas nada de eso. No importa cuántos subprocesos de fondo ejecute o qué tan duro estén trabajando: Android no mantendrá su aplicación activa solo porque su aplicación esté utilizando la CPU. Tiene que tener alguna forma de saber que su aplicación todavía tiene trabajo que hacer; es por eso que Services
están registrados con el sistema operativo y AsyncTasks
no lo están.
Multithreading
AsyncTasks
se trata de crear un subproceso en segundo plano en el que hacer el trabajo y luego presentar el resultado de ese trabajo al subproceso de la interfaz de usuario de una manera segura.
Cada nueva AsyncTask
ejecución generalmente genera más concurrencia (más subprocesos), sujeto a las limitaciones del conjunto de AsyncTasks's
subprocesos [ ref ].
Service
los métodos, por otro lado, siempre se invocan en el hilo de la interfaz de usuario [ ref ]. Esto se aplica a onCreate()
, onStartCommand()
, onDestroy()
, onServiceConnected()
, etc Por lo tanto, en cierto sentido, Services
no "correr" en el fondo. Una vez que comienzan ( onCreate()
), simplemente se "sientan" allí, hasta que es hora de limpiar, ejecutar un onStartCommand()
, etc.
En otras palabras, agregar más Services
no resulta en más concurrencia. Los métodos de servicio no son un buen lugar para realizar grandes cantidades de trabajo, ya que se ejecutan en el hilo de la interfaz de usuario .
Por supuesto, puede ampliar Service
, agregar sus propios métodos y llamarlos desde cualquier hilo que desee. Pero si hace eso, la responsabilidad de la seguridad del hilo recae en usted, no en el marco.
Si desea agregar un hilo de fondo (o algún otro tipo de trabajador) a su Service
, puede hacerlo. Se podría iniciar un hilo de fondo / AsyncTask
en Service.onCreate()
, por ejemplo. Pero no todos los casos de uso requieren esto. Por ejemplo:
- Es posible que desee seguir
Service
ejecutándose para poder seguir recibiendo actualizaciones de ubicación en el "fondo" (es decir, sin necesariamente tener ninguna en Activities
pantalla).
- O bien, es posible que desee mantener viva su aplicación para que pueda mantener un
BroadcastReceiver
registro "implícito" a largo plazo (después de API 26, no siempre puede hacer esto a través del manifiesto, por lo que debe registrarse en tiempo de ejecución [ ref ]).
Ninguno de estos casos de uso requiere una gran cantidad de actividad de la CPU; solo requieren que la aplicación no sea eliminada .
Como trabajadores
Services
no están orientados a tareas. No están configurados para "realizar una tarea" y "entregar un resultado", como AsyncTasks
son. Services
no resuelva ningún problema de seguridad de subprocesos (a pesar del hecho de que todos los métodos se ejecutan en un solo subproceso). AsyncTasks
, por otro lado, maneja esa complejidad por ti.
Tenga en cuenta que AsyncTask
está programado para desuso . ¡Pero eso no significa que deba reemplazarlo AsyncTasks
por Services
! (Si ha aprendido algo de esta respuesta, eso debería quedar claro).
TL; DR
Services
están principalmente allí para "existir". Son como fuera de la pantalla Activity
, lo que proporciona una razón para que la aplicación se mantenga viva, mientras que otros componentes se encargan de hacer el "trabajo". AsyncTasks
"trabajan", pero no mantendrán vivo un proceso en sí mismos.