Fuga de memoria estática con contexto
He estado haciendo algunas investigaciones y todavía no estoy 100% seguro si esto podría causar una pérdida de memoria basada. Estoy usando una vista de botón (v.context). Creo que estoy bien, ya que el contexto no se almacena como estático, pero me gustaría una reacción si es posible. El problema principal que estoy viendo es con OSMonitor … el valor (M) sube y sube y sube. Con cada apertura / cierre del widget y en la rotación de la pantalla.
32M 43M 61M 77M etc …
- Método estático sin nombre
- ¿Es posible que VM de Android recolecte basura de variables estáticas sin matar a toda la aplicación de Android?
- Activity.runOnUiThread de Android no es estático, así que ¿cómo puedo usarlo?
- Los datos estáticos guardados dentro de singleton son nulos a veces cuando se vuelve a la aplicación desde el fondo
- NDK: enlace estático libm
No estoy seguro si (M) es Megabytes o Megebits. Si esto se basa en la pila, estoy asumiendo Megebits perhpas ya que la mayoría de dispositivos de gama alta están limitados a 32/48 MB en la pila (o algo).
Gracias por la retroalimentación / ojos extra!
Esta es la aplicación Banner en el mercado, por cierto …
public class Globals { public static final String PREF_NAME = "BannerPreferences"; public static final int MAX_TEXT_SIZE = 20; // refresh ALL widgets loaded on the user's screens // this could be for removing or adding 'pendingIntents or during bootup public static void refreshAllWidgets(Context context) { Logger.d("BANNER", "Globals:refreshAllWidgets"); invalidateWidgets(context, BannerWidget.class); // 1x4 invalidateWidgets(context, BannerWidget1x2.class); invalidateWidgets(context, BannerWidget2x2.class); } // there has to be a API way to do this!! Until then, just loop thru all // widget_provider classes.. private static void invalidateWidgets(Context context, Class<?> cls) { ComponentName comp = new ComponentName(context, cls); AppWidgetManager appWidgetManager = AppWidgetManager.getInstance(context); int[] appWidgetIds = appWidgetManager.getAppWidgetIds(comp); for (int i = 0; i < appWidgetIds.length; i++) { BannerWidgetBase.updateAppWidget(context, appWidgetManager, appWidgetIds[i]); } appWidgetIds = null; }
- No se puede hacer referencia estática al método no estático (Android getApplicationContext ())
- Eficiencia de Android: importar métodos estáticos o importar la clase
- Ciclo de vida del objeto estático de Android
- ¿Vive la variable estática incluso después de que la aplicación se cierre?
- ¿Cuál es el ciclo de vida de una variable pública estática en Android?
- Adaptador de matriz estática en fragmento. ¿Buenas o malas prácticas?
- ¿Por qué no puedo usar getFilesDir (); En un contexto estático?
- Métodos estáticos vs. clase extendiendo android.app.Application?
No tiene que haber una fuga. Debido a la naturaleza de la VM de Dalvik, el montón sigue creciendo cuando está en uso hasta que alcanza el tamaño máximo del montón. Sin embargo, puede haber suficiente espacio en el montón para sus objetos. Sugeriría para limitar la memoria del proceso (montón) en una imagen del emulador y ver si usted consigue realmente un OutOfMemoryError. Al crear el emulador, hay una propiedad "Tamaño de montón de aplicaciones VM máximo" que desea establecer, por ejemplo, 32 (medida en megabytes).
Si obtiene un OutOfMemoryError, debería tener una mirada más cercana a Eclipse MAT.
PS: Acabo de darse cuenta de que probablemente debería utilizar un contexto de aplicación en su caso, y nunca una actividad. Si lo activa desde una actividad, considere getApplicationContext en lugar de pasar la actividad como un contexto. Las cosas estáticas pueden sobrevivir a instancias de actividad.
- Optimización del análisis de JSON en Android
- Tenga un escáner de código de barras llamado en lugar del teclado en una vista web