Я делаю html-интерфейс для загрузки изображений на сервер с помощью Drag & Drop и нескольких файлов выбора.Я хочу отобразить картинки перед их отправкой на сервер.Поэтому я сначала пытаюсь использовать FileReader, но у меня были некоторые проблемы, такие как в этом посте .поэтому я изменил свой путь и решил использовать blob: url как рекомендации ebidel в посте, с window.URL.createObjectURL() и window.URL.revokeObjectURL() для освобождения памяти.
Но теперь у меня есть другая проблема, которая заключается в том, чтопохож на этот .Я хочу, чтобы клиент мог загрузить 200 изображений одновременно, если он хочет.Но браузер вышел из строя, а оперативная память была очень высокой!Поэтому я подумал, что, возможно, одновременно показывалось слишком много изображений, и я настроил систему с ожидающей очередью файлов, используя массив, чтобы обрабатывать только 10 файлов одновременно.Но проблема все еще возникает.
В Google Chrome, если я отмечу chrome://blob-internals/, файлы (которые обычно уже высвобождаются window.URL.revokeObjectURL()) освобождаются приблизительно с 8-секундной задержкой.В Firefox я не уверен, но похоже, что файлы не были выпущены (я проверяю about:memory -> images для этого)
Мой код плохой, или это проблема, независимая отмне?Есть ли решение, чтобы заставить навигаторы немедленно освободить память?Если это может помочь, это часть JavaScript, в которой возникают проблемы: (Извините, но я привожу здесь ссылку из-за механизма спама для новых участников) http://www26.zippyshare.com/v/14195278/file.html.
РЕДАКТИРОВАТЬ
Это своего рода собственный ответ + ответ на bennlich (слишком длинный текст для комментария)
Я понял из ответа пользователя 1835582, что действительно могу удалитьBlob / File, но пока браузеру нужны изображения, он хранит их где-то в памяти (что логично).Так что именно факт отображения изображений (многих и тяжелых) дал мне сбои и замедления, а не метод revokeObjectURL.Более того, каждый браузер управляет памятью по-своему, что ведет к разному поведению.Вот как я пришел к такому выводу.
Во-первых, давайте попробуем, что revokeObjectURL работает хорошо, на простом примере, используя исходный код https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example.3A_Using_object_URLs_to_display_images. Используя Chrome, вы можете убедиться, что Blob исправныотменили, отметив chrome://blob-internals/ или попытавшись открыть отображаемые изображения в новой вкладке, которая будет пустой.Примечание: чтобы полностью освободить ссылки Blob, добавьте document.getElementById("fileElem").value = "".Когда я опубликовал свой вопрос несколько лет назад, выпуск блоба занимал около 8 секунд, а теперь он почти мгновенный (вероятно, из-за улучшений в Chrome и / или на более качественном компьютере)
Затем пришло время для проверки заряда.,Я сделал это с сотней JPG ~ 2,5 Мо каждый.После того, как эти изображения были показаны, я прокрутил страницу.Chrome завис и Firefox работал медленно (не тестировался в других браузерах).Однако, когда я прокомментировал li.appendChild(img), все прошло хорошо, даже с огромной кучей изображений.Это показывает, что проблемы не в методе revokeObjectURL, который на самом деле работает должным образом, а в отображении большого количества тяжелых изображений.Вы также можете протестировать, чтобы создать простую HTML-страницу с сотнями тяжелых изображений и прокрутить ее => тот же результат (сбой / замедление).
Наконец, чтобы глубже изучить управление памятью изображений, интересно взглянуть на Firefoxв о: память.Например, я видел, что когда окно активно, Firefox распаковывает изображения (images -> uncompressed-heap увеличивается), тогда как raw (images -> raw) всегда стабилен (относительно количества загруженных изображений).Здесь хорошее обсуждение управления памятью: http://jeff.ecchi.ca/blog/2010/09/19/free-my-memory.