¿Cómo se presentan los objetos Java en la memoria en Android?

Estoy bastante familiarizado con el diseño de objetos en el montón de HotSpot, pero no tanto para Android.

Por ejemplo, en una JVM HotSpot de 32 bits, un objeto en el montón se implementa como un encabezado de 8 bytes, seguido por los campos del objeto (un byte para boolean , cuatro bytes para una referencia y todo lo demás como se espera), establecido Out en algún orden específico (con algunas reglas especiales para los campos de superclases), y padded a un múltiplo de 8 bytes.

He hecho algunas investigaciones, pero no puedo encontrar ninguna información específica de Android.

(Estoy interesado en optimizar algunas estructuras de datos muy utilizadas para minimizar el consumo de memoria en Android.)

dalvik/vm/oo/Object.h es tu amigo aquí. El comentario de struct Object dice:

 /* * There are three types of objects: * Class objects - an instance of java.lang.Class * Array objects - an object created with a "new array" instruction * Data objects - an object that is neither of the above * * We also define String objects. At present they're equivalent to * DataObject, but that may change. (Either way, they make some of the * code more obvious.) * * All objects have an Object header followed by type-specific data. */ 

java.lang.Class objetos java.lang.Class son especiales; Su diseño está definido por la estructura Object.h en Object.h . Los objetos del arreglo son simples:

 struct ArrayObject : Object { /* number of elements; immutable after init */ u4 length; /* * Array contents; actual size is (length * sizeof(type)). This is * declared as u8 so that the compiler inserts any necessary padding * (eg for EABI); the actual allocation may be smaller than 8 bytes. */ u8 contents[1]; }; 

Para matrices, las anchuras están en vm/oo/Array.cpp . Los booleanos son el ancho 1, los objetos tienen sizeof(Object*) length (generalmente 4), y todos los otros tipos primitivos tienen su longitud esperada (embalada).

Los objetos de datos son muy simples:

 /* * Data objects have an Object header followed by their instance data. */ struct DataObject : Object { /* variable #of u4 slots; u8 uses 2 slots */ u4 instanceData[1]; }; 

El diseño de un DataObject (todas las instancias de clases que no son de clase) se rige por computeFieldOffsets en vm/oo/Class.cpp . Según el comentario:

 /* * Assign instance fields to u4 slots. * * The top portion of the instance field area is occupied by the superclass * fields, the bottom by the fields for this class. * * "long" and "double" fields occupy two adjacent slots. On some * architectures, 64-bit quantities must be 64-bit aligned, so we need to * arrange fields (or introduce padding) to ensure this. We assume the * fields of the topmost superclass (ie Object) are 64-bit aligned, so * we can just ensure that the offset is "even". To avoid wasting space, * we want to move non-reference 32-bit fields into gaps rather than * creating pad words. * * In the worst case we will waste 4 bytes, but because objects are * allocated on >= 64-bit boundaries, those bytes may well be wasted anyway * (assuming this is the most-derived class). * * Pad words are not represented in the field table, so the field table * itself does not change size. * * The number of field slots determines the size of the object, so we * set that here too. * * This function feels a little more complicated than I'd like, but it * has the property of moving the smallest possible set of fields, which * should reduce the time required to load a class. * * NOTE: reference fields *must* come first, or precacheReferenceOffsets() * will break. */ 

Por lo tanto, los campos de superclase vienen primero (como de costumbre), seguidos de campos de tipo de referencia, seguidos de un solo campo de 32 bits (si está disponible, y si se requiere padding porque hay un número impar de campos de referencia de 32 bits) seguido de 64 -bits. Siguen los campos de 32 bits regulares. Tenga en cuenta que todos los campos son de 32 bits o 64 bits (primitivas más cortas se rellenan). En particular, en este momento, la VM no almacena byte / char / short / boolean campos utilizando menos de 4 bytes, aunque sin duda podría apoyar esto en teoría.

Tenga en cuenta que todo esto se basa en leer el código fuente de Dalvik a partir de commit 43241340 (6 de febrero de 2013). Dado que este aspecto de la VM no parece estar documentado públicamente, no debe confiar en que esto sea una descripción estable del diseño del objeto de la VM: puede cambiar con el tiempo.

  • Cambiar imagen de contacto mediante programación
  • Androide. Cambio de brillo
  • Comprobar si existe un fragmento y reutilizarlo
  • Compruebe si una ruta representa un archivo o una carpeta
  • ¿Por qué la configuración de settings.xml se superpone a la barra de herramientas / barra de herramientas?
  • Extraño resultado de análisis de fecha y hora con SimpleDateFormat
  • NDK no encuentra las bibliotecas estándar de C ++
  • Android aceleración de hardware TextureView con lockCanvas ()
  • Desplazamiento pequeño al calcular la rotación en función del punto de contacto
  • Pasa la variable entre la clase de no actividad a la clase de actividad de Android
  • ¿Cómo puedo configurar el cliente Retrofit de Square para manejar una solicitud con un número variable de parámetros
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.