Descripción de URL de objetos para archivos del lado del cliente y cómo liberar la memoria

Question

Estoy usando createObjectURL para obtener una URL de referencia para un archivo de imagen local. Cuando termine con el archivo/imagen, llamo al revokeObjectURL para liberar esa memoria. Todo funciona bien para mí, pero solo quiero estar seguro de que estoy liberando todo el recuerdo que puedo.

Mi preocupación surgió después de que inspeccioné la página chrome://blob-internals. Al llamar al createObjectURL y al usar la imagen, noté que se crearon dos entradas. Uno con url blob:blobinternal:///d17c4eef-28e7-42bd-bafa-78d5cb86e761

y el otro

blob:http://localhost/dbfe7b09-81b1-48a4-87cd-d579b96adaf8

ambos referidos a la misma ruta de archivo local, sin embargo. Al llamar al revokeObjectURL, solo se eliminó la segunda entrada del chrome://blob-internals. ¿Por qué ocurre esto, cómo me deshago de la otra entrada y cuál es la diferencia entre los dos tipos?

Además, he visto ejemplos de personas que revocan la URL incluso antes de usar la imagen. ¿Qué efecto tiene esto?

¡Alguna idea del tema sería muy apreciada! :)

EDITAR: he creado un ejemplo en jsfiddle. Así que primero abra blobinternals y elimine cualquier blobs existente. Luego ejecute el ejemplo jsfiddle y elija un archivo de imagen en su máquina. A continuación, actualice blobinternals para ver qué se agregó. Luego haga clic en "revocar URL" en mi ejemplo. Finalmente actualice blobinternals para ver qué blobs permanecen.

Answer 1

La otra referencia (la que comienza con blob:blobinternal) parece estar en el elemento input type="file". He modificado su función para reiniciar el valor de la entrada, y al hacer clic en el botón URL de revocación, todas las referencias se borran:

killBut.onclick = function() { 
    URL.revokeObjectURL(ourURL); 
    fileBut.value = ''; 
}; 

Probado en Chrome Canary.