Ciclo de vida de actividad de Android y ciclo de código nativo de JNI

Tengo una aplicación sencilla con código nativo. Es decir, una actividad más código nativo.

Cuando la actividad está entrando en el fondo, mantengo el código nativo en ejecución para realizar algún procesamiento. El problema es cuando la actividad es asesinada por el sistema operativo (debido a la baja de recursos), el código JNI parece no tener conocimiento de lo que pasó en Java y seguir haciendo su trabajo, por lo tanto desperdiciar recursos. ¿Por qué Android mata sólo la actividad en lugar de todo el proceso? Y en este caso, ¿cómo sabe el código nativo que se mató la actividad? OnDestroy () no se puede llamar.

Una actividad en una aplicación de Android se describe en la documentación como

Una actividad es una cosa única y enfocada que el usuario puede hacer.

Por lo general es algo que es visible en la pantalla y tiene la atención del usuario. Se ha asociado con él una máquina de estado que describe el ciclo de vida de ser mostrado y oculto cuando otra actividad se activa. El sistema operativo tiene libertad para iniciar y detener las actividades según elija – y la memoria lo permite.

Además, un punto clave de la arquitectura de Android es que las actividades y servicios son componentes de software reutilizables y no necesariamente tienen una relación de uno a uno con los procesos. Dentro del mismo proceso que su actividad puede ser un servicio en uso por otro proceso en el sistema.

Si la parte JNI de su código sigue activa en segundo plano cuando una actividad ha recibido onPause() , onStop() , onDestroy() , sólo puede ser porque no ha reenviado estos mensajes. El sistema ciertamente no sabe cómo limpiar la utilización de recursos del código nativo – en particular la memoria asignada con new() o malloc() . A menos que lo liberen, sólo se recuperará una vez terminado el proceso.

Si su preocupación es que su actividad no está siendo asesinada con la suficiente rapidez por el sistema y como resultado la celebración de referencias a los recursos en tierras nativas, es una buena señal de que el sistema no es limitado en recursos.

Es posible que considere la posibilidad de implementar la parte nativa de su aplicación como un servicio y que se autodestruya después de cortos períodos de uso.

Podrías tener varias actividades en una aplicación de Android. A medida que sus Actividades pasan al fondo, pueden ser asesinadas para recuperar recursos. La aplicación se mantiene típicamente alrededor hasta que el teléfono funciona realmente bajo en memoria, o el usuario va y mata su app manualmente. El proceso se pega hasta que la aplicación es asesinada, en términos generales.

Debido a que puede continuar procesando en segundo plano, cuando su actividad se vuelve a crear, puede comprobar el estado de sus variables globales y tal vez recoger donde lo dejó.

Tenga en cuenta que las actividades se matan con bastante frecuencia, por lo que no hay mucho punto de hacer el procesamiento en el fondo, pero detenerse cuando se cancela la actividad. Usted también podría detener cuando onStop() se llama en este caso.