2011-10-12 34 views
14

Estoy haciendo una interfaz html para cargar imágenes en un servidor con Arrastrar & Soltar y múltiples archivos de selección. Quiero mostrar las imágenes antes de enviarlas al servidor. Así que primero trato de usar FileReader pero he tenido algunos problemas como en this post. así que cambié mi camino y decidí usar blob: url como recomendaciones de ebidel en la publicación, con window.URL.createObjectURL() y window.URL.revokeObjectURL() para liberar memoria.window.URL.revokeObjectURL() no libera memoria inmediatamente (o no lo hace)?

Pero ahora, tengo otro problema, que es similar a this one. Quiero que un cliente pueda subir 200 imágenes a la vez si así lo desea. ¡Pero el navegador se bloqueó y el ariete utilizado era muy alto! Así que pensé que tal vez se mostraban demasiadas imágenes al mismo tiempo, y configuré un sistema con una lista de espera de archivos usando una matriz, para tratar solo 10 archivos a la vez. Pero el problema todavía ocurre.

En Google Chrome, si marque chrome://blob-internals/, los archivos (que normalmente ya se han publicado por window.URL.revokeObjectURL()) se liberan de forma aproximada después de un retraso de 8 segundos. En Firefox no estoy seguro, pero parece que los archivos no se lanzaron (reviso about:memory -> imágenes para eso)

¿Mi código es malo o es un problema independiente de mí? ¿Hay alguna solución para forzar a los navegadores a liberar inmediatamente la memoria? Si puede ayudar, esta es la parte de JavaScripton en la que se producen los problemas: (Lo siento, pero doy aquí un enlace debido al mecanismo de spam de imagen para los nuevos miembros) http://www26.zippyshare.com/v/14195278/file.html.

EDITAR

Se trata de un tipo de respuesta propia + una respuesta a bennlich (texto demasiado largo para un comentario)

que entendí de la respuesta de user1835582 que, efectivamente, pude eliminar el Blob/File, aunque el navegador necesita imágenes, las mantiene en algún lugar de la memoria (lo cual es lógico). Así que es el hecho de mostrar imágenes (muchas & pesadas) que me dieron bloqueos & ralentizaciones, no el método revokeObjectURL. Además, cada navegador maneja la memoria por su propia cuenta, lo que lleva a comportamientos diferentes. Aquí es cómo llegué a esta conclusión.

En primer lugar, probemos que revokeObjectURL funciona bien, con un ejemplo simple usando el código fuente https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example.3A_Using_object_URLs_to_display_images. Al usar Chrome, puede verificar que Blob esté revocado, marcando chrome://blob-internals/ o tratando de abrir las imágenes mostradas en una nueva pestaña que estará en blanco. Nota: para liberar completamente las referencias de Blob, agregue document.getElementById("fileElem").value = "". Cuando publiqué mi pregunta hace algunos años, fue aproximadamente 8 segundos para liberar blob, ahora es casi inmediata (probablemente debido a las mejoras en Chrome &/oa una computadora mejor)

Entonces, es hora de una prueba de carga. Lo hice con un centenar de jpg de ~ 2.5 Mo cada uno. Después de que se hayan mostrado las imágenes, desplacé la página. Chrome se bloqueó y Firefox fue lento (no probado en otros navegadores). Sin embargo, cuando comencé a comentar li.appendChild(img) todo fue bien, incluso con un enorme grupo de imágenes. Esto muestra que los problemas no provienen del método revokeObjectURL, que de hecho funciona correctamente, pero muestra muchas imágenes pesadas. También puede probar para crear una página html simple con cientos de imágenes pesadas y desplazarla => mismo resultado (bloqueo/ralentización).

Finalmente, para profundizar en la administración de la memoria de imágenes, es interesante que Firefox investigue sobre: ​​la memoria.Por ejemplo, vi que cuando la ventana está activa, Firefox descomprime las imágenes (las imágenes -> sin comprimir-el montón sube), mientras que las primas (imágenes -> sin procesar) siempre son estables (en relación con la cantidad de imágenes cargadas). Hay una buena discusión sobre la gestión de memoria aquí: http://jeff.ecchi.ca/blog/2010/09/19/free-my-memory.

+0

Super, tengo exactamente el mismo problema que tú, pero 5 años después :) Gracias por tu esfuerzo para comentar todo lo detallado. Voy a decidir mejor no obtener una vista previa de forma automática todas las imágenes, sólo en la demanda. ¡Gracias! –

Respuesta

7

Con window.URL.revokeObjectURL() sólo se puede obtener [Blob] o [Archivo] objeto. No puedes forzar eliminar de la memoria.

Nota. Los navegadores no están finalizados y pueden filtrarse desde estas instalaciones. Si implementa la animación, usted tiene que entender que a su propio riesgo.

+7

Sería genial si alguien que entiende esta respuesta la reescribiera. Parece bastante confuso. – bennlich

+0

@bennlich He editado mi pregunta, dando mi comprensión de esta respuesta + algunos detalles adicionales. – Seb

2

Esto no es una respuesta, pero solo quiero decir que, por lo que puedo decir, este sigue siendo un problema en la última versión de Chrome (35). Hice una página de prueba que expone el problema:

http://ecobyte.com/tmp/chromecrash-1a.html

Si selecciona un gran número (por ejemplo, 600) de fotos de alta resolución en su ordenador y soltarlos en el cuadro de esa página, que se colgará Chrome (probado en Windows 7 y Mac OS X 10.8.5).

Si nos fijamos en la fuente se puede ver que la secuencia de operaciones es:

  1. createObjectURL
  2. carga de la img (! No agregue a DOM)
  3. revokeObjectURL para liberar el árbitro
  4. pierde la img ref
  5. repita todos los pasos para el próximo cayeron imagen

Parece que solo una sola imagen debe estar en la memoria/referenciada en un momento dado, pero finalmente esto bloquea Chrome.

Cuestiones relacionadas