Android: производительность «хиты» в приложении живые обои

Question

Android: производительность «хиты» в приложении живые обои

1

Я испытываю некоторые проблемы с приложением для живых обоев, которое я пишу.

Я использую OpenGL 1.0 для рендеринга. В целом производительность, которую я получаю, довольно приличная. На Samsung Galaxy S2 (2.3.4) я могу получить 60 FPS без ограничения рамки.

Однако время от времени я получаю несколько кадров, которые значительно больше других (пусть говорят, что нормальный кадр равен 33 мс, а рамка шипа составляет около 70-100 мс). Это происходит через регулярные промежутки времени, примерно раз в секунду.

Мой код выполняет точно такую же обработку каждого кадра, что и это поведение является ненормальным. Похоже, что по какой-то причине мой поток поменяется/откладывается ОС, или только VM начинает выполнять медленнее в какой-то момент.

Замедление не связано с обработкой GPU, поскольку eglSwapBuffers никогда не ждет. Я также уверен, что мой процесс не приводит к запуску GC, потому что я уверен, что у меня не будет коротких объектов в моем цикле (проверено в трекере распределения DDMS).

Интересно то, что если я держу палец на экране, то всплески во время кадра, как правило, становятся значительно меньше. Из-за этого ОС повышает приоритет процесса.

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

Кто-нибудь еще испытывал ту же проблему? Любые намеки относительно того, что может вызвать проблему, также будут весьма признательны.

user1000028 10 дек. 2011, в 15:16

Источник

Теги:

java

android

performance

opengl-es

2 ответа

Ещё вопросы

Tom Whittock · Answer 1 · 2011-12-14T07-15-00.000Z

То, что вы описываете, звучит как длинный сбор мусора для меня. [EDIT] Вы упомянули, что урезали свои ассигнования - возможно, есть другое приложение или библиотека, которая вызывает всплеск?

Переключение контекста потока произойдет, но если вы не приблизитесь к пределу с точки зрения использования ЦП (т.е. Вы используете 16 мс мощности процессора за кадр), то это не будет вашей проблемой. В настоящее время вы почти наверняка ограничены частотой переключения буфера кадров GPU (максимум 60 коммутаторов в секунду).

Я бы также сказал, что живые обои обычно должны иметь возможность ограничить частоту обновления до 15 кадров в секунду. Слив батареи - это фактор, который необходимо серьезно рассмотреть для живых обоев.

Alexis Andre · Answer 2 · 2011-12-14T07-06-00.000Z

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

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