java - smart - NullPointerExceptions solo en algunos dispositivos Samsung Galaxy?

wifi direct samsung

Question

Estoy usando LibGDX. Cuando se inicia mi aplicación, crea una pantalla. Cuando se carga la pantalla, llama a una función estática Module.createStyles() .

Esta función crea un conjunto de estilos que se usarán en el resto de la aplicación (estilos incorporados de LibGDX como WindowStyle, LabelStyle, TextButtonStyle, todos los tipos de elementos utilizados para crear los objetos de la interfaz de usuario).

Cuando la pantalla está lista, llama a Module.disposeStyles() .

De todos modos, de acuerdo con mis informes de fallas de Google Analytics, obtengo al azar una NullPointerException cuando intento, por ejemplo, crear un cuadro de diálogo con Module.dialogStyle :

ExitDialog exitDialog = new ExitDialog("Are you sure?", Module.dialogStyle);

Thread: GLThread 2089, Exception: java.lang.IllegalArgumentException: style cannot be null.
at package.Window.setStyle(Window.java:181)
at package.Window.<init>(Window.java:63)
at package.Dialog.<init>(Dialog.java:65)
at package.ExitDialog$1.<init>(ExitDialog.java:38)

No hay absolutamente ninguna razón para que Module.dialogStyle sea ​​nulo. El único lugar donde Module.disposeStyles() este campo está en Module.disposeStyles() y esta función solo se llama en un lugar específico de la aplicación (al final).

Asumiría que esto era un error en mi código de alguna manera a pesar de que el 95% de los usuarios nunca lo experimentaron. Sin embargo, todos los 5% que sí lo experimentan parecen ser usuarios de Galaxy y no estoy seguro si eso es una coincidencia:

• Galaxy s4
• Galaxy S III
• GALAXY Tab 3 lite

¿Alguien tiene alguna idea? ¿Los dispositivos Galaxy no tienen un administrador de RAM incorporado? ¿Eso tiene algo que ver con esto?

Answer 1

Voy a suponer que:

Module.dialogStyle

es una referencia a una propiedad static en la clase Module .

Probablemente te encuentres con los efectos colaterales de cómo Android administra el ciclo de vida de las JVM. Hay escenarios (especialmente en dispositivos más grandes) en los que se reutilizará una instancia de JVM que puede causar problemas (por ejemplo, los inicializadores estáticos ya se han ejecutado y no volverán a ejecutarse). Alternativamente, static punteros static pueden vivir desde una ejecución previa de su aplicación a la siguiente, y pueden tener un estado no válido o incorrecto en ellos. Depende de los detalles de cómo está organizada su aplicación.

Si incluye más código que muestra cómo y cuándo inicializa los campos estáticos, probablemente podamos resolverlo.

Para obtener más detalles sobre los diferentes ciclos de vida y cómo reproducirlos localmente, consulte: http://bitiotic.com/blog/2013/05/23/libgdx-and-android-application-lifecycle/