Производительность Android drawBitmap для множества растровых изображений?

Question

Я нахожусь в процессе написания игры для Android и, похоже, у меня возникают проблемы с производительностью при рисовании на Canvas.Моя игра имеет несколько уровней, и на каждом из них (очевидно) находится разное количество объектов.

Странно то, что на одном уровне, который содержит 45 изображений, работает безупречно (почти 60 кадров в секунду).Однако другой уровень, содержащий 81 изображение, практически не работает (11 кадров в секунду);это в значительной степени неиграбельно.Это кажется кому-то странным, кроме меня?

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

Что здесь происходит?Может ли Canvas просто не рисовать столько изображений в каждом игровом цикле?Как вы, ребята, порекомендовали бы мне улучшить эту производительность?

Заранее спасибо.

Answer 1

Мне тоже кажется странным.Я также разрабатываю игру, много уровней, у меня легко может быть 100 игровых объектов на экране, я не видел подобной проблемы.

При правильном использовании drawbitmap действительно должен быть очень быстрым;это немного больше, чем команда копирования.Я даже не рисую круги изначально;У меня есть растровые изображения предварительно отрисованных кругов.

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

Я подозреваю, что вы смотрите не в том месте.Если вы создаете и используете изображения одинакового типа одним и тем же способом, то удвоение количества изображений на экране не должно снижать производительность более чем в 4 раза. Максимально оно должно быть линейным (в 2 раза).

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

В то же время я бы провел базовое тестирование.Что происходит, если вы на самом деле не рисуете половину объектов?Игра работает намного быстрее?Если нет, то это не имеет ничего общего с рисованием.

Answer 2

Я думаю эта лекция поможет вам. Перейти к 45 минуте. Существует график, сравнивающий метод Canvas и метод OpenGl. Я думаю, что это ответ.

Answer 3

Я столкнулся с похожей проблемой с производительностью - т.е. уровень 1 работал отлично, а уровень 2 не

Оказалось, что не рендеринг был ошибкой (по крайней мере, не специально). Это было что-то еще специфическое для логики уровня, которая вызывала узкое место.

Дело в том ... Traceview - твой лучший друг.

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