Самый быстрый способ загрузки растрового изображения, повторного использования растрового изображения после создания

У меня есть приложение, в котором я генерирую много объектов Bitmap. Как только я создам растровое изображение, все остальные растровые изображения будут одинакового размера.Самый быстрый способ загрузки растрового изображения, повторного использования растрового изображения после создания

В настоящее время я могу загрузить/создать новое растровое изображение примерно на 50-80 мс на моем телефоне, которое работает для того, что мне нужно. Однако из-за быстрых темпов их создания я нахожу постоянный GC.

Я хотел бы повторно использовать один и тот же объект растрового изображения, но не уверен, как это сделать через sdk.

Я выполнил сборку libjpeg и загрузил изображения через NDK и повторно использовал мои растровые изображения, однако моя скорость загрузки упала примерно до 200 мс, что слишком медленно. Я отправлю код позже, когда у меня его передо мной.

Вопросы:

Есть ли способ, чтобы повторно использовать свои растровые объекты, чтобы избежать GC? Есть ли более быстрый способ загрузить мои изображения через NDK? Можно ли подключиться к тому, как ОС загружает растровые изображения? Я знаю о libjpegTurbo, но я не могу его компилировать в настоящее время (другая тема для другого дня).

Любые другие мысли о наилучшем способе сделать это.

источник

2012-03-12 broschb

Почему бы не использовать хэш-карту для хранения ваших растровых изображений? Затем, когда вы загружаете растровое изображение, убедитесь, что он первый раз в хэш-карте, и если вы можете его повторно использовать. Если это не в hashmap, сохраните его как обычно, а затем вставьте в хэш-карту.

источник

2012-03-12 15:08:45 onit

Я создаю около 20 битмапов в секунду, поэтому я не могу хранить их в памяти. У меня на самом деле есть фоновый поток, заполняющий очередь, из которой я вынимаю новые растровые изображения. Большая проблема заключается в моем фоновом потоке вместо создания новых объектов растровых изображений, я хотел бы извлечь из пула растровых изображений и просто повторно использовать их, чтобы у меня не было столько GC. – broschb

@broschb Если вы не можете сохранить их в памяти, то как их можно повторно использовать? Вы понимаете, что это не имеет смысла? Если у вас есть ограничения по памяти, лучшим решением для этого является реализация кэша изображений с использованием хэш-карты и очереди, а затем, когда вы достигнете определенного ограничения на количество растровых изображений, загружаемых для удаления старых растровых изображений из очереди и намека на GC, что они должны быть очищены из памяти. Хешмап будет использоваться для определения того, находится ли растровое изображение в очереди и его местоположении. – onit

Я могу повторно использовать растровое изображение, изменив данные пикселя растрового изображения, с новыми данными пикселя из другого растрового изображения. См. Ответ @Samuels, я думаю, что это по треку, о котором я думаю. – broschb

Я бы порекомендовал использовать IntBuffer (ы), которые содержат данные пикселов, которые необходимо заменить. Затем создайте одно растровое изображение необходимого вам размера, и когда вам нужно поменять пиксели, используйте bitmap.copyPixelsFromBuffer(). Я думаю, что это будет намного быстрее, чем распределение/деаллокация растровой памяти каждый раз, когда вам нужно изменить данные пикселя. Возможно, было бы неплохо сохранить буферы в хэш-карте, если вы хотите сохранить их в памяти для быстрого поиска.

Возможно, вы можете использовать setPixels() с массивом int. Хорошая вещь о copyPixelsFromBuffer() заключается в том, что никакое преобразование пикселей не выполняется, и есть меньше вариантов, так что это может быть немного быстрее.

источник

2012-03-12 15:29:18 Samuel

Мне нравится идея встроенного буфера, но единственный существенный выигрыш здесь я вижу, возможно, в пространстве памяти. Самый быстрый способ - сохранить объекты в памяти, и в этом случае это будет только значительным улучшением, если буферы int значительно меньше, чем битмап-объект. Я сомневаюсь в этом, если растровые изображения относительно невелики. – onit

Откуда берутся данные пикселя? В какой-то момент это должен быть массив int, не так ли? Поэтому, если вы выделяете растровое изображение каждый раз, тогда у вас есть память для массива int и памяти для растрового изображения. Предполагая, что вы закончили с массивом int, это один объект, который нужно собрать мусором. Затем, когда вы закончите с растровым изображением, ему также нужно будет собрать мусор. Это два больших объекта, которые нужно собрать мусором. Если вы используете только одно растровое изображение, у вас не будет дополнительного объекта, который должен быть собран в мусор. Bitmap GC занимает больше времени, поскольку он также имеет вызовы JNI. – Samuel

Если вы повторно используете растровые изображения в памяти, GC больше не становится большой проблемой, если у вас нет огромного количества изображений, которые вы не можете кэшировать в памяти (я лично хранил сотни растровых изображений в памяти на новых телефонах). Я полагаю, что по меньшей мере 95% памяти, используемой Bitmap, также является фактическим базовым массивом int, если у вас нет очень маленьких растровых изображений. Если он может просто кэшировать битмапы в памяти (что будет самым большим приростом производительности), я сомневаюсь, что это будет значительное увеличение производительности. Если ему нужно постоянно перерабатывать растровые изображения, я согласен, что это будет улучшение. – onit

Самый быстрый способ загрузки растрового изображения, повторного использования растрового изображения после создания

ответ

Смежные вопросы