android - ¿Por qué llamar a Process.killProcess(Process.myPid()) es una mala idea?
unity3d kill-process (5)
He leído algunas publicaciones que dicen que usar este método "no es bueno", no debería haber sido usado, no es la manera correcta de "cerrar" la aplicación y no es así como funciona Android ...
Entiendo y acepto el hecho de que Android OS sabe mejor que yo cuando es el momento adecuado para finalizar el proceso, pero no escuché aún una buena explicación de por qué está mal usar el método killProcess() . Después de todo, es parte de la API de Android ...
Lo que sí sé es que llamar a este método mientras otros subprocesos realizan un trabajo potencialmente importante (operaciones en archivos, escritura en DB, solicitudes HTTP, servicios en ejecución ...) puede terminarse en el medio, y claramente no es bueno. Además, sé que puedo beneficiarme del hecho de que "volver a abrir" la aplicación será más rápido, porque el sistema todavía puede "retenerse" en el estado de la memoria desde la última vez que se usó, y killProcess() evita eso.
Además de este motivo, suponiendo que no tengo tales operaciones, y no me importa que mi aplicación se cargue desde el principio en cada ejecución, hay otras razones por las que no se utiliza el método killProcess() .
Sé acerca del método finish () para cerrar una Actividad, así que no me escriba sobre eso, por favor .. finish() es solo para Activity . no a todas las aplicaciones, y creo que sé exactamente por qué y cuándo usarlo ...
Y otra cosa: también estoy desarrollando juegos con el framework Unity3D y exportando el proyecto a Android. Cuando descompilé la aplicación generada, me sorprendió mucho descubrir que el código fuente de Java creado a partir de la unidad - implementando el método de Unity - Application.quit() , con Process.killProcess(Process.myPid()) .
Se supone que Application.quit() es la manera correcta de cerrar el juego de acuerdo con las guías de Unity3d (¿es realmente ?, tal vez estoy equivocado, y me perdí algo), entonces ¿cómo es que los desarrolladores de frameworks de Unity están haciendo un muy buen trabajo como parece implementado esto en Android nativo para killProcess() ?
¿Quién dijo que llamar a Process.killProcess (Process.myPid ()) es una mala idea?
Sí, permitir que el sistema operativo administre su propia memoria es la mejor práctica tanto para usted como para el usuario que usa su aplicación (más rápido para abrir nuevamente, menos posibilidades de cerrar la fuerza, etc.).
Sin embargo, suponiendo que esté seguro de que no está interrumpiendo los hilos u otras operaciones en segundo plano y utiliza esta llamada en onDestroy() , no veo ninguna razón por la que no deba usarla. Especialmente cuando se trata de una llamada API y no una solución, y Google no mencionó que es mejor no usarla en la documentación de la API.
Aquí hay dos situaciones en las que killProcess te morderá y no funcionará como desees:
1) Servicios fijos: se reiniciarán automáticamente, aunque hayas matado el proceso
2) Temporizador: si programó los subprocesos para que se ejecuten en un temporizador, continuarán ejecutándose después de matar el proceso.
Por lo tanto, como puede ver, hay situaciones en las que ** killProcess * no es una solución prudente para limpiar su aplicación en ejecución.
Bueno, Unit3d probablemente esté usando código nativo, y están matando el proceso como un seguro: no quieren perder memoria. Podría discutir si esta es una buena idea o no, pero el hecho de que lo hayan usado no significa que usted también deba hacerlo.
Quizás haya algunos casos extremos en los que desearía usar killProcess() , pero generalmente el sistema operativo lo hace por usted, de acuerdo con la carga y el uso actuales. No estoy seguro de qué tipo de respuesta está buscando: sabe que el uso de killProcess() podría romper las cosas, a menos que pueda justificar su uso, no lo use.
es una mala idea por un lado, su actividad no valdrá con la instrumentación, ya que esos marcos se registran en todos los métodos del ciclo de vida y solo después de la ejecución limpia informan un estado de éxito de la prueba. Si mata el proceso desde debajo de la aplicación de prueba, informará una falla y no estará claro si esto está sucediendo.
<rant>
En un mundo perfecto, con códigos y bibliotecas perfectos, no debería necesitar llamar a Process.killProcess(Process.myPid()) y el sistema operativo matará su aplicación correctamente según corresponda. También habrá paz en Oriente Medio, los cerdos volarán y se resolverá el problema de la detención .
Debido a que todas estas cosas no han sucedido aún, hay veces en que necesita ejecutar dicho código ''prohibido''.
Más recientemente, para un juego de Android que hice, la versión gratuita usó una biblioteca de anuncios que mantendría viva la aplicación y también perdería la memoria. La versión paga no tenía este problema ya que no había bibliotecas de anuncios vinculadas. Mi solución fue agregar un botón Salir en el menú principal que ejecutó dicho código. Mi esperanza era que la mayoría de las personas presionarían este botón cuando terminen y no tengo que preocuparme de que se consuma la memoria. La versión de pago que acabo de ejecutar finish() y se terminó. (Esto fue antes de que las compras en la aplicación para Google estuvieran disponibles, así que tuve que hacer una versión paga y gratuita, también pueden haber solucionado el problema por ahora y podría actualizar dicho juego pero realmente no me fue muy bien y dudo que cualquier tiempo gastado en él valdría la pena)
Es como en la escuela primaria / secundaria que te dicen que no puedes tomar la raíz cuadrada de un número negativo. Luego, en una clase de álgebra de nivel superior, dicen ... bueno, puedes tomar la raíz cuadrada de un número negativo pero obtienes resultados extraños, pero es consistente y resuelve el problema.
En otras palabras, no ejecutes el código ''prohibido'' a menos que sepas lo que estás haciendo.
</rant>