Это зависит.Если ваш экран (и, следовательно, нарисованные на нем поверхности) 16-битный, он может быть быстрее;однако, если они 32-битные, 32-битная битовая карта может быть быстрее.
Однако, если вы смотрите на это с точки зрения ресурсов - что означает изображения в формате JPEG или PNG - говоря, что они "16-битные"или «32 бита» довольно бессмысленно.JPEG - это цветное представление, которое вы обычно расширяете до 32-битного, хотя вы также можете распаковать до 16-битного (и, возможно, захотите сглаживать при этом, чтобы оно выглядело прилично).PNG может хранить множество представлений, в зависимости от изображения, и обычно выбирает, что лучше.Кроме того, во время упаковки aapt просматривает все изображения PNG и повторно сжимает их в конечное изображение, которое является как можно меньшим, поэтому он может даже использовать палитровое представление, если это возможно.
Так как вы храните изображенияне имеет большого значения;имеет значение растровое изображение, которое создается при распаковке во время выполнения.Здесь есть несколько общих правил:
- Если изображение имеет альфа-формат, его необходимо распаковать до полного 32-битного.
- Если буфер кадра и поверхности 32-битные,изображение должно быть распаковано до 32 бит.
- Если изображение не имеет альфа-канала, оно может быть 888 (32 бит) или 565 (16 бит).Выбор того, что использовать, ... сложен.
Исторически устройства, с которыми мы работали на платформе, имели 16-битные экраны, поэтому нам приходилось сталкиваться с его сложностями.Основная проблема - это баланс между использованием памяти и производительностью рендеринга и качеством.Для использования памяти и производительности рендеринга лучше всего использовать 16-битную ... однако для многих изображений будет присутствовать цветовая полоса, если нет размытия изображения.
Где сделать это размытие также сложно: в идеале высделал бы это как часть создания исходного изображения, но это ограничивает то, что вы можете с ним сделать (без масштабирования, что означает, что не нужно использовать 9-патчи).С другой стороны, вы можете сделать это при рендеринге, но это означает, что вам нужно загружать изображение как 32-битное и сглаживать каждый раз, когда оно выводится на экран.Это дает наибольшую гибкость, но оказывает большее влияние на память и производительность.
На практике это фактически становится редкой проблемой для платформы - потому что почти все образы, которые используются в качестве 9-патчей или тому подобноетакже имеют прозрачность, они должны быть загружены как 32-битные в любом случае, так что при рендеринге не так уж и много проблем с дизерингом.
Что все это кипит:
- Если у вашего изображения прозрачность, не беспокойтесь, оно все равно будет загружено 32 бита.
- Если у вашего изображения нет прозрачности, вам необходимо:
- Решить, следует лидизеринг исходного изображения.Это обеспечит лучшее качество на 16-битных экранах (вы будете делать лучше сглаживание, чем код рендеринга, критичного к производительности), но не будет в полной мере использовать 32-битные экраны.
- Пусть платформа решит, что делать.Это даст хорошие результаты как для 16-битных, так и для 32-битных экранов, но вы не хотите масштабировать изображение.
- Загрузите изображение самостоятельно и явно управляйте API, чтобы решить, какой формат использовать и когда (или если) для дизеринга.