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
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.
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.
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. –
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
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.
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. –
- 1. ¿Límites de recursos en Windows?
- 2. ¿Qué alternativas de gestión automática de recursos existen para Scala?
- 3. ¿Existen límites respecto a qué tan profundo puede anidar la inclusión de encabezado?
- 4. ¿Qué trampas existen para Django?
- 5. Recursos $ NotFoundException en Android
- 6. ¿Qué tipo de obstáculos existen para la firma de la APK de Android?
- 7. límites de cuota de Android Geocoder
- 8. Qué opciones existen para mantener la compatibilidad de Android 1.5 después de la Implementación de Fragmentos
- 9. Recursos de Android $ NotFoundException
- 10. ¿Qué visualizadores de depuración existen?
- 11. ¿Los diferentes teléfonos Android tienen diferentes límites en la cantidad de dispositivos de perfil SPP bluetooth a los que se pueden conectar?
- 12. ID de recursos de Android
- 13. Mapa límites Utilizando Android de Google Maps
- 14. Identificador de recursos de Android
- 15. Límites de escala en el zoom de pellizco de Android
- 16. ¿Qué marcos de pruebas de mutaciones existen?
- 17. JSON de análisis en Android - desde la carpeta de recursos
- 18. Android - Imágenes de la carpeta de recursos en un GridView
- 19. ¿Cómo verificar recursos de Android?
- 20. Constantes para tipos de recursos en Android
- 21. Recursos de Android Sync Adapter
- 22. Android: ¿Cómo encuentra GridView auto_fit la cantidad de columnas?
- 23. ¿Qué herramientas de edición T4 existen?
- 24. Qué herramientas de autotest existen para Clojure
- 25. ¿Qué bibliotecas JavaScript multiplataforma existen?
- 26. ¿Qué herramientas XSLT 2.0 existen?
- 27. Almacenamiento de gran cantidad de imágenes en android
- 28. ¿Qué herramientas gratuitas de formato SQL existen?
- 29. ¿Qué otras herramientas de analítica web existen?
- 30. ¿Cómo identifico qué ramas existen en CVS?
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. –
@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? –
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. –