Проблемы с загрузкой изображений в приложениях J2ME на телефонах Motorola

Question

Стандартный способ загрузки изображения в приложение J2ME использует метод Image.createImage, а рекомендованный формат изображения - PNG.

Теперь спецификации J2ME не устанавливают никаких ограничений на реализацию этого метода или представление изображения в памяти, поэтому каждый поставщик имеет другую реализацию.

Motorola, в частности, имеет эту действительно дрянную реализацию, где в PNG полностью декодируется в массив байтов ARGB во время создания изображения. Это означает, что 8K png с размерами 176x208 занимает максимальную память около 170K для загрузки, а память, используемая самим объектом Image, составляет около 145K! На других телефонах, таких как Nokia, Sony Ericsson и т. Д., Одно и то же изображение занимает около 16 тыс., Чтобы загрузить и сохранить в памяти. Я не знаю, какие умные оптимизации они используют, но по какой-то непонятной причине в JVM от Motorola нет.

Это разрушает хаос в моем приложении J2ME, поэтому почти невозможно запустить достойную версию его на телефонах Motorola. Я пробовал различные обходные пути, например, используя массив gzip'd ARGB-байтов изображения и дефляцию его во время краски, но это заставляет краску замедляться в 10 раз!

Кто-нибудь знает об обходном пути к этой проблеме? Декодер изображений PNG с открытым исходным кодом для J2ME с умственными способностями, которых не хватает Motorola? Или есть что-то, что можно сделать с изображением PNG, чтобы уменьшить его объем памяти? (Я в настоящее время используется индексированный режим PNG) Любые указатели на всех будет приветствоваться ..

Gowri

Answer 1

PNG имеют тенденцию быть bloaty.

Почему бы не использовать gif вместо этого.

http://www.ddj.com/mobile/184406435;jsessionid=SBUQN2ECITM5OQSNDLOSKHSCJUNN2JVN?_requestid=76071

Answer 2

Ну, как я понимаю, если все форматы изображения немедленно декодируется в массив ARGB при создании изображения, единственное, что вы действительно можете сделать, это создать верхнюю границу количества память, которую вы будете использовать для отображения на экране.

Вы можете создать кеш изображения, который будет знать, сколько памяти кучи использует каждое изображение для этого конкретного устройства, загрузка и выгрузка. Изображения необходимы. Конечно, это означает, что полагаться на Grabage Collector может быть слишком много, чтобы ваше приложение реагировало.

Управление кэшем, вероятно, должно произойти в отдельной теме.

Сохранение только одного снимка экрана, загруженного в любой момент времени, может работать, если ваши экраны приложений достаточно статичны, чтобы не требовать слишком много анимации.

Также помните, что холст MIDP обычно не сбрасывается. Если вы используете 2 разных вызова в Canvas.paint(), чтобы нарисовать 2 разных изображения в двух разных областях экрана, вы должны иметь возможность отображать оба изображения долго после того, как фактические объекты изображения были собраны в мусор, как вы, t красят что-нибудь поверх них.

С чисто коммерческой точки зрения, вам нужно сообщить своим клиентам, что на некоторых телефонах есть такая реализация Java настолько плохо, что вы не собираетесь их поддерживать.

Answer 3

Форум разработчиков Motorola предлагает вам разрезать большие изображения на меньшие полосы и загружать эти небольшие полосы вместо всего большого изображения за один снимок.Обратите внимание, что это не уменьшает площадь изображения в памяти. Это все еще нуждается в сумме (ширина * высота * байты на пиксель) всех полос. Но это уменьшает память, необходимую для декодирования png-изображения и загрузки. Вот что я делаю сейчас. Это помогло некоторым. Но общее использование памяти по-прежнему является проблемой.

Answer 4

Одна вещь на Sony Ericsson. Не давайте им столько кредитов. Они берут (image_width x image_height x bytes_per_pixel) памяти, а также при загрузке изображений.

от разработчика Doc SE J2ME, «Всех изображения сохраняются в памяти телефона в 16-бит на пиксель формате RGB, возможно, с 1-битовым или 8 бит на пиксель альфа-канал.» Таким образом, в менее 2 байтов. Разница в том, что телефоны Sony Ericsson (я не могу говорить для Nokia) имеют отдельный блок памяти для изображений, которые сначала заполняются перед загрузкой изображений в кучу (вы можете увидеть это, обернув загрузку с помощью Runtime.getRuntime(). FreeMemory() ... размер кучи будет увеличиваться всего на пару байтов, что является размером нового объекта).

Это не защищает Motorola, поскольку у меня наверняка были проблемы с переносом телефонов SE на Motorola, но это не потому, что SE удалось выяснить способ хранения изображений в куче гораздо более оптимизированным способом. Motorola просто хранит все в куче, и поэтому вы выбегаете быстрее.

Меньшие изображения - это хорошая идея не только во время декодирования, но и с точки фрагментации кучи. Это позволит изображениям помещаться в меньшие блоки памяти вместо большого непрерывного блока.

Answer 5

Лучшим решением будет хранить ARGB в качестве данных (используйте некоторую индексацию для сжатия) с помощью улучшений палитры и т. Д./No PNG Header /. вместо сохранения различных изображений PNG и использовать функцию createImage для создания изображения.

Answer 6

Одним из способов уменьшить изображение png было бы запустить их через программу, например png gauntlet , чтобы уменьшить ее размер.