¿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.)

One Solution collect form web for “¿Cómo se presentan los objetos Java en la 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.

  • Hash clave para Facebook Android SDK
  • Transmisión de datos de un fragmento en una actividad de otra actividad
  • Crashlytics no encuentra clave API en crashlytics.properties en tiempo de ejecución
  • OkHttp PublicKey pinning en Android
  • android obtener la fecha anterior de una fecha correspondiente (no la fecha de ayer)
  • Efecto de transición del botón ActionBar up
  • Android: error al cargar la biblioteca
  • Incluir proyecto Java como biblioteca
  • API de calendario de Android insertar evento recurrente
  • Después de la actualización de Google Play Service a la versión 13, recibí un error
  • En Java, si un puntero nulo sucede muy raramente es mejor usar catch en lugar de if
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.