Cómo detectar si la carga de una imagen generará una excepción OutOfMemory en .NET?

Question

Tengo una aplicación escrita usando .NET 3.5 SP1 que descarga imágenes de un sitio externo y las muestra a los usuarios finales. En raras ocasiones, mis usuarios están experimentando errores de OutOfMemory porque están descargando imágenes enormes. Algunas veces, los datos brutos asociados con estas imágenes son grandes, pero más a menudo, las dimensiones de las imágenes son enormes. Me doy cuenta de que nunca podré evitar el hecho de que estos errores OOM se producen para imágenes particulares. Sería MUY útil, sin embargo, si de alguna manera pudiera determinar si cargar una imagen en particular daría lugar a un problema OOM antes de intentar cargar la imagen.

Los datos de las imágenes se cargan en un Stream y luego la imagen se convierte en System.Drawing.Image haciendo una llamada a System.Drawing.Image.FromStream (stream). No tengo la opción de almacenar estas imágenes en el disco primero. Deben cargarse a través de la memoria.

Si alguien tiene alguna sugerencia o sugerencia que me permita detectar que cargar una imagen daría lugar a una excepción de OOM, lo agradecería mucho.

Answer 1

OutOfMemory es una de esas excepciones en las que no tiene muchas opciones buenas. Todo lo que pueda predecir de manera concluyente que va a obtener la excepción probablemente solo genere la excepción.

Diría que su mejor opción es hacer un perfil del comportamiento y crear su propio conjunto de reglas predictivas o simplemente codificar tamaños máximos para su aplicación. No es bonito, pero te llevará hasta allí.

Answer 2

lo podría hacer en esta pregunta y ver si ayuda: How do I reliably get an image dimensions in .NET without loading the image?

La idea no sería descargar sólo una parte de la imagen total (la cabecera específicamente) para que pueda leer los metadatos. Luego puede usar la información allí para determinar qué tan grande es la imagen, y negar que se descargue por completo si ve que será demasiado grande.

En el lado negativo, parece que tendría que escribir un método para descomponer el binario de cada tipo de archivo que desea controlar.

Answer 3

Tienes un problema con la gallina y el huevo. Para hacer una especie de suposición, necesitas saber el tamaño de la imagen. No sabes el tamaño hasta que lo cargaste.

No es realmente útil de todos modos. Si obtienes OOM realmente depende de cuán fragmentado ha sido el espacio de direcciones de la memoria virtual. Y eso es no fácil de encontrar en Windows. La función API de HeapWalk() es necesaria y esa es una función no saludable para usar. Consulte la letra pequeña en el artículo de la biblioteca de MSDN. Especialmente malo en un programa administrado, no lo use.

Tenga en cuenta que esta excepción OOM no es el mismo tipo de OOM que obtendría cuando utilizara demasiada memoria administrada. En realidad, es una excepción GDI + y puede recuperarse fácilmente de ella. Simplemente tome la excepción y muestre un mensaje "Lo siento, no pude hacerlo".

Si conoce el tamaño del frente de alguna manera, entonces puede asumir con bastante seguridad que el ancho * alto * 4> 550 MB no funcionará en un programa de 32 bits. Este límite baja rápidamente después de funcionar por un tiempo.

Answer 4

Si está descargando las imágenes de un sitio externo, y el sitio externo configura el encabezado HTTP Content-Length, es posible que pueda estimar si la imagen encajará en la memoria incluso antes de comenzar a descargarla. .

Answer 5

Puede usar la clase MemoryFailPoint para verificar la disponibilidad de la memoria.

Mejor

Answer 6

ya he acordado con la respuesta @Vagaus, pero quería añadir que sólo se debe asignar el almacenamiento intermedio de una vez y tratar de volver a utilizarlo. Si está asignando y liberando constantemente un gran buffer, sin duda llegará a un problema OOM debido a la fragmentación en el montón.