Стратегии кучи Android VM для больших изображений

Question

Я манипулирую относительно большими изображениями, около 5MP, а иногда и больше.Мне нужно две копии изображений в памяти для манипуляции.Теперь загруженные изображения занимают много памяти, больше, чем доступно в куче Android по умолчанию, которая составляет 16 МБ или 24 МБ, что приводит к следующей ошибке:

11-20 18: 02: 28,984: E/ AndroidRuntime (7334): java.lang.OutOfMemoryError: размер растрового изображения превышает бюджет виртуальной машины

Мне нужно полное разрешение, поэтому уменьшение масштаба при загрузке изображений не помогает.Как лучше всего решить эту проблему?Существуют ли встроенные методы для динамической загрузки только кусков растровых изображений из хранилища?И может ли кто-нибудь дать мне несколько советов, как я могу преодолеть проблему с памятью, например, с помощью определенных стратегий кэширования?

С уважением,

Answer 1

Вы должны посмотреть это видео об управлении памятью: http://www.youtube.com/watch?v=_CruQY55HOk Примерно через 6 минут он охватывает опцию манифеста LargeHeap, добавленную в HoneyComb.

Answer 2

Вы можете выделить больше памяти в ndk. Вам придется написать собственный код для работы с изображениями или придумать способ выделить память изображений в native, а затем передать ее обратно в Java.

Использование растрового изображения / холста и NDK

Другой вариант может состоять в том, чтобы загрузить одно изображение в память и разбить его на куски для обработки. Сохраните эти фрагменты в файловую систему. Итак, скажем вам 2 больших изображения. Вы загружаете первое изображение, разбиваете его на 4 части, сохраняете их, загружаете второе, разбиваете его на 4 части, сохраняете их, затем загружаете часть # 1 для каждого изображения и делаете свое дело. Это означает, что вы знаете, что ни одно отдельное изображение не превышает максимальный размер кучи, и что вам нужно (в основном) уровень пикселей, и вам не нужен доступ к данным окружающих пикселей (у вас возникнут проблемы на краях, если нужна информация о соседних пикселях).

Без понижающей дискретизации, разделения или ndk, я не знаю, как вы могли бы получить больше данных изображения в память. Возможно понижение цветовой информации. Мы делаем это в продукте. Представьте каждый пиксель как 16 бит, а не 24 или 32. Наш продукт скорее функциональный, чем «симпатичный», поэтому потеря информации о цвете не имела большого значения.