По производительности: много маленьких PNG или один большой PNG?

Question

Разработка простой игры для iPhone, что дает лучшую производительность?

1. Использование множества небольших (от 10x10 до 30x30 пикселей) PNG для фонов моих UIViews.
2. Использование одного большого PNG и обрезка до границ моих UIViews.

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

Второй метод, с другой стороны, дает iPhone возможность обрабатывать только один большой PNG, но неумышленно увеличивает вес изображения, которое должен нести каждый UIView.

• Я прав насчет попыток iPhone, обработки изображений так, как я это описал?
• Итак, как идти?

Видя ответы до сих пор, все еще есть сомнения. Похоже, что есть компромисс с двумя параметрами: сложность и интенсивное использование процессора. Каким будет мой переломный момент при принятии решения, какую технику использовать?

Answer 1

Если вы в конечном итоге ссылаетесь на один и тот же CGImageRef (например, путем совместного использования UIImage *), изображение не будет загружаться несколько раз различными видами. Именно этот метод используется в демонстрационной программе Core Animation videowall на основной конференции WWDC 07 . Это код OSX, но UIViews очень похожи на CALayers.

То, как Core Graphics обрабатывает изображения (по моим наблюдениям, так или иначе), сильно подправлено для своевременной загрузки и агрессивного высвобождения при нехватке памяти.

Используя большое изображение, вы можете в конечном итоге загрузить его во время отрисовки, если память для декодированного изображения, на которое указывает CGImageRef, была возвращена системой.

Разница не в том, сколько изображений у вас есть, а в том, как часто UIKit пересекает ваш код.

Как UIViews, так и Core Animation CALayers будут перекрашиваться только в том случае, если вы попросите их (-setNeedsDisplay), а узким местом обычно является ваш код плюс перенос визуализированного содержимого в текстуру для графического чипа.

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

Answer 2

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

Глядя на содержимое пакетов .app на обычной Mac OS, кажется, что общепринятым способом хранения является один файл / ресурс на изображение.

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

Answer 3

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

Answer 4

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

Answer 5

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

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