2011-11-21 15 views
11

Una de nuestras aplicaciones tiene varios miles de pequeños archivos de datos que actualmente empaquetamos como activos. Ayudaría a nuestro código si pudiéramos empaquetarlos como recursos sin procesar. He tratado de rastrear cuáles son los límites para la cantidad de recursos que una aplicación puede tener de cada tipo, pero no he encontrado ninguna documentación al respecto. ¿Alguien sabe cuáles son los límites en la cantidad de recursos de Android?¿Qué límites existen en la cantidad de recursos de Android?

Respuesta

10

Después de una gran cantidad de experimentos, parece que puede tener hasta 16 bits en recursos (65,536 recursos) para cada tipo de recurso. (Puede haber bits adicionales reservados para uso futuro, lo que reduciría el recuento máximo de recursos, pero no pude encontrar ninguna evidencia de esto.) Sería bueno si alguien pudiera proporcionar una respuesta autorizada, pero después de un año, ' m darse por vencido.

EDIT (ver el comment below by @B T): Basado en this answer by hackbod en otro hilo, parece que hay, de hecho, los 16 bits disponibles, por lo que uno puede tener hasta 65.535 recursos de cualquier tipo (no 65536, debido a cero no es disponible). Además, tenga en cuenta que este límite se aplica solo a la cantidad de recursos para una sola configuración (configuración regional, densidad de píxeles, etc.). Las variaciones de un recurso para diferentes configuraciones comparten la misma ID de recurso y no contribuyen al recuento. Por lo tanto, puede tener más de 65.535 recursos de cualquier tipo (por ejemplo, diseño o cadena), pero no para una configuración cualquiera.

+0

aapt impone un límite de 16 bits por tipo de recurso, por aplicación. Los recursos apklib se agregan al número total de declaraciones de recursos de la aplicación. –

+0

@JamesWald - Gracias. Pensé que no podía ser más de 16 bits, pero no estaba seguro de si quizás teníamos menos. ¿Puedes señalar alguna documentación para esto? –

+2

Tuve que buscar en el código fuente de Aapt porque no está documentado. Los 8 bits más significativos del valor del recurso representan el ID del paquete. Los siguientes 8 bits más significativos representan el tipo de recurso. Esto deja 16 bits para direccionar los recursos. Consulte makeResId() en https://android.googlesource.com/platform/frameworks/base.git/+/android-4.4_r1.1/tools/aapt/ResourceTable.h.Además, la línea 3817 de https://android.googlesource.com/platform/frameworks/base.git/+/android-4.4_r1.1/tools/aapt/ResourceTable.cpp establece el ID del paquete en 127, dándonos una base valor de 0x7f000000. –

0

No hay documentación explícita sobre esto que yo sepa, sin embargo, se pueden hacer suposiciones razonables de que los desarrolladores de Android han diseñado Android apropiadamente dadas sus recomendaciones. Recomiendan que coloques cadenas y drawables en los recursos con el potencial de suministrar diferentes para diferentes lugares, tamaños de pantalla, densidades de pantalla y orientaciones. El gran número de estas posibilidades me sugiere que esperan que las aplicaciones incluyan miles de recursos y que estarás muy bien suministrando unos pocos miles de pequeños recursos sin procesar.

+0

El problema aquí es que no puede contar diferentes configuraciones regionales, tamaños de pantalla, etc., de una sola cadena como recursos separados. En realidad, se superponen y usan el mismo valor de ID de recurso. Lo que me preocupa es bastante simple: ¿cuántos bits de un ID de recurso están disponibles para cada tipo de recurso? Muchos bits están reservados para identificar el tipo de recurso en sí, por lo que ciertamente no es de 32 bits. Desde navegar por algunos archivos R.java, parece que son como mucho 16 bits para cualquier tipo de recurso. Si tenemos tantos, podemos salir adelante, pero menos y podemos tener problemas. –

+0

Ese es un buen punto. Quizás la mejor manera es simplemente intentarlo. Puede escribir una aplicación rápida para generar archivos, tal vez 1.txt, 2.txt, hasta un número configurable, tal vez con el mismo número que el contenido del archivo. Luego haz lo mismo para generar un java simple para leer el recurso en Android y quizás lanzar una excepción o algo si falla. Incluso podría generar directamente una prueba JUnit. – kabuko

0

Teniendo en cuenta la clase R automática y el valor del recurso utilizado en la API que asumiría en algún lugar alrededor de Integer.MAX_INTEGER para la cadena, drawable y layout id cada uno.

+0

No hay manera de que sea correcto. Cada valor int en R tiene al menos la mitad de los bits reservados para banderas de varios géneros (para el tipo de recurso, si es un sistema o id de usuario, y quién sabe qué más). Como dije en otro comentario, una mirada casual a una R bien poblada sugiere que a lo más 16 bits están disponibles para distinguir entre recursos de cualquier tipo. –

Cuestiones relacionadas