¿Solo usas XHDPI en la aplicación Android?

Question

Si planea admitir LDPI, MDPI, HPDI y tal vez XHDPI en un futuro próximo, ¿está bien incluir solo XHDPI en el proyecto y dejar que los dispositivos los escalen a la resolución deseada?

He probado para cambiar el tamaño de los dibujables en MDPI y HDPI en Photoshop y luego comparé el resultado con XHDPI solo redimensionado por Android, y no puedo ver ninguna diferencia en absoluto. ¿Es mal diseño tomar este atajo? Sería bueno no tener que cambiar el tamaño de cada dibujable en 3 resoluciones diferentes.

Planear el uso del SDK de destino es 2.1 o 2.2.

BR Emil

Answer 1

supongo que es una buena manera de ir. El único inconveniente que se me ocurre es la sobrecarga de recursos en dispositivos de pequeña escala y posibles artefactos debido a la reducción de escala. En realidad, en el Google IO de este año, Chris Pruett recomendó incrustar solo activos de alta resolución y dejar que opengl maneje la escala.

Answer 2

XHDPI solo se introdujo en Android SDK API Level 9 (Gingerbread) (consulte http://developer.android.com/reference/android/util/DisplayMetrics.html#DENSITY_XHIGH), por lo que si planea tener un SDK mínimo de menos de 9 también deberá proporcionar, al menos, HDPI imprimibles. los dispositivos con Froyo o inferior no mostrarán nada.

Actualización: En realidad, parece que las versiones anteriores a pan de jengibre mostrará xhdpi imágenes: https://groups.google.com/d/msg/android-developers/yjYO91OmoJ4/v3he0ZbKo-UJ

Answer 3

Está bien tener sólo los recursos xhdpi. Pero tenga en cuenta que xhdpi se introdujo con api nivel 9 (pan de jengibre). Es decir, si apuntas a los niveles de api < = 8, necesitas al menos también recursos de hdpi.

Answer 4

A partir de Android 1.6, se manejan diferentes densidades, incluyendo XHDPI (que no se agregó oficialmente hasta 2.2). Su aplicación primero buscará una imagen que coincida con su densidad, pero puede buscar en "cubos" más grandes como XHDPI y luego realizar la escala por usted.

Lo mejor es incluir activos específicos para las densidades que desea admitir. Una imagen de 100x100 toma 40kb; e imagen que es 200x200 toma 160k (sin comprimir). Por lo tanto, todos los recursos XHDPI utilizados en dispositivos MDPI tienen cuatro veces la cantidad de datos que necesita, que deben manejarse cuando se inicia la aplicación y se preparan sus recursos. Un menor uso de la memoria significa una mayor eficiencia, menos posibilidades de una OutOfMemoryException.

Además, los tipos específicos de imágenes se verán mal al escalar automáticamente. En particular, las imágenes con líneas finas o patrones finos tendrán sus detalles embarrados. Cuando reduce las imágenes a mano, puede elegir el algoritmo que mejor se adapte a sus necesidades (lineal, bicúbico, lanczos, etc.).

Si usted está preocupado por el tiempo que se necesita para hacer el cambio de tamaño a sí mismo, se puede incorporar un proceso por lotes o utilizar herramientas tales como composición de nueve Resizer: http://code.google.com/p/9patch-resizer/

Answer 5

he probado en una aplicación sencilla (desarrollar para Android 2.1) usando solo imágenes xhdpi y funciona bien en resoluciones pequeñas, medianas y altas ... incluso probé en un Android 2.1 (resolución pequeña) y abre la imagen sin problemas.

Tal vez la cosa con la memoria es verdadera, por lo que es necesario que alguien pruebe esto.

Answer 6

Personalmente encontré que usar solo la carpeta xhdpi funciona bastante bien en muchas aplicaciones y soy un gran partidario de este enfoque. En la sobrecarga de la memoria es cierto, pero con los dispositivos de hoy lo consideraría insignificante.También creo que hay algo de almacenamiento en caché después de la reducción de escala ya que nunca noté ninguna ralentización debido a esto. Incluir solo una carpeta puede reducir drásticamente el tamaño de su APK que los usuarios finales apreciarán bastante. Debes tener en cuenta que algunas imágenes obtendrán artefactos de escalado (patrones finos y demás) pero personalmente nunca me encontré con nada crítico en mis aplicaciones. También para botones y cosas, asegúrese de usar 9 parches para reducir los artefactos en las esquinas redondeadas, incluso puede reducir ligeramente el tamaño de la imagen utilizando este enfoque. El nivel de API no será un problema en versiones anteriores, ya que creo que drawable-xhdpi se considera simplemente dibujable en versiones que no lo admiten. No ignore las posibilidades de definir algunos dibujos simples en xml, por ejemplo, es muy fácil crear un fondo degradado con formas simples y con esto ahorra espacio y no se arriesga a escalar artefactos.

Answer 7

Esta afirmación sobre el uso de memoria adicional es incorrecta.

Si coloca XHDPI tamaños dibujables dentro de la carpeta MDPI, entonces tendrá problemas de memoria.

Pero si proporciona XHDPI carpeta arrastrable dentro de la carpeta XHDPI, no se utilizará ninguna memoria adicional ya que Android reduce las imágenes omitiendo partes de la misma.

Este skipping es la razón por la cual debe proporcionar productos aptos para todas las densidades que planea admitir para que se vean bien.

Por otro lado, solo ciertas imágenes se verán mal cuando se muestrean de forma descendente (principalmente íconos pequeños) de forma que, siempre que la imagen tenga suficientes datos para descartar, se verá bien. O imagine si tiene una cuadrícula como dibujable, de modo que algunas líneas de la cuadrícula se pueden descartar y la imagen se verá mal.

Al final, es mejor para usted experimentar con diferentes dispositivos, entonces puede ver qué drawales necesitan recursos alternativos para su densidad.