2013-04-18 3 views
2

У меня есть часть типа слайд-шоу AIR Mobile для iOS, над которой я работаю. Существует четыре страницы, которые пользователь может прокрутить. Каждая страница содержит PNG (размером 1 МБ, даже после сжатия), загружаемую с использованием класса Bitmap и двух TextField. Когда я прокручиваю их (используя специальную структуру прокрутки, которая работает без каких-либо проблем во всем приложении), приложение кэширует каждый из изображений PNG в виде растрового изображения, когда они выходят на экран, и выгружая их, когда они покидают экран после (скорее всего, следующий GC, хотя он кажется менее случайным, чем GC).Растровые изображения, которые кэшируются как растровые изображения

Акт кеширования PNG невероятно медленный на iOS, особенно когда это происходит, когда происходит другое действие (например, прокрутка). Это приводит к задержке ~ 1 с при прокрутке, что, очевидно, неприемлемо. Есть ли способ: a) предотвратить кеширование или b) хранить кеширование дольше/неопределенно до тех пор, пока сами изображения не будут иметь доступ к GC?

Я проверил тройной код и ничего не установлен в cacheAsBitmap. Кроме того, я использовал Adobe Scout, чтобы точно определить, что вызывало это мгновенное замораживание, и это определенно связано с кэшированием изображений. Я также устранил любые преобразования или шкалы или фильтры или что-нибудь, что может включить cacheAsBitmap для работы, и результаты остаются неизменными.

+0

Поддерживает ли этот механизм прокрутки кэширование своего содержимого в виде растрового изображения? По крайней мере во время прокрутки. – Vesper

+0

@Vesper Это было изначально, но оно было удалено, потому что оно было слишком медленным на мобильных устройствах, если вы сделали это именно так. –

ответ

2

Получается, что растровое кэширование на самом деле не было проблемой. После гораздо большего изучения я обнаружил, что это была декомпрессия PNG. В основном, Flash выполнял декомпрессию PNG, когда они приходили на экран (что еще более дорого, чем кеширование), добавляя их в память и отменяя процесс после того, как они были на экране в течение определенного периода времени, то есть мне пришлось бы распаковывать сначала через этот период времени для каждого изображения.

Чтобы обойти это, вам просто нужно получить доступ к объекту BitmapData. Я использовал getPixel(0, 0) в моих конструкторах, и изображения были распакованы и загружены в BitmapData на постоянной основе после этого. Это добавит немного времени на запуск, но предварительная загрузка таким образом приводит к лучшей производительности.

0

Чтобы избежать этого декомпрессии при запуске (по требованию), вы можете вместо этого запросить вспышку для ее распаковки при загрузке. Это увеличит время загрузки, но улучшит воспринимаемую производительность приложения, так как отдельный поток позаботится о распаковке. Это, конечно, означает отсутствие дрожания или пропуска, когда изображение попадает на экран.

var loaderContext:LoaderContext = new LoaderContext(); 
loaderContext.imageDecodingPolicy = ImageDecodingPolicy.ON_LOAD 
var loader:Loader = new Loader(); 
loader.load(new URLRequest("http://www.adobe.com/myimage.png"), loaderContext); 

См: http://help.adobe.com/en_US/as3/dev/WS52621785137562065a8e668112d98c8c4df-8000.html

И

http://www.bytearray.org/?p=2931

Встроенные изображения (с помощью кода) не должны быть сжаты, так что эта проблема не должна возникать с приложениями, которые делают это. Однако, если вы похожи на меня, и вы используете Flash Pro IDE для импорта PNG или других битмап-активов, Flash Pro сжимает их как JPG по умолчанию, используя настройку, предоставленную самим изображением.

Чтобы устранить эту проблему и избежать этих проблем с декомпрессией, просто зайдите в библиотеку ресурсов Flash Pro, щелкните правой кнопкой мыши по изображению, которое хотите изменить, щелкните по свойствам и выберите «lossless/PNG/GIF» как сжатие. Это в значительной степени увеличит время загрузки, но вы будете иметь гораздо лучшую воспринимаемую производительность, обсуждаемую здесь. Это должно быть сделано в дополнение к реализации вышеприведенного кода, или это не будет иметь никакого значения.

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

Поскольку Flash Player освободит распакованную растровую память BitmapData, вот решение, если декомпрессирование все еще происходит после этого: Keeping Bitmaps Decompressed.

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