Wie sind Java-Objekte im Speicher auf Android gelegt?

Ich bin ziemlich vertraut mit dem Layout von Objekten auf dem Heap in HotSpot, aber nicht so viel für Android.

Zum Beispiel wird in einem 32-Bit-HotSpot-JVM ein Objekt auf dem Heap als 8-Byte-Header implementiert, gefolgt von den Feldern des Objekts (ein Byte für boolean , vier Bytes für eine Referenz und alles andere als erwartet), gelegt Out in einer bestimmten Reihenfolge (mit einigen speziellen Regeln für Felder aus Superklassen), und gefüllt zu einem Vielfachen von 8 Bytes.

  • M_mainFrame-> editor () -> hasComposition nicht ausgeben
  • Anhängen mehrerer Listener auf Ansichten in Android?
  • Android assetManager
  • Mit ZXing erstellen Sie eine Android-Barcode-Scan-App
  • Android Studio-Konfiguration für die ORMLite-Konfigurationsgenerierung
  • Wie mache ich die Zeitschrift window.location.href nicht auf Chrome auf Android
  • Ich habe einige Recherchen gemacht, aber ich kann keine Android-spezifischen Informationen finden.

    (Ich bin daran interessiert, einige extrem weit verbreitete Datenstrukturen zu optimieren, um den Speicherverbrauch auf Android zu minimieren.)

  • Nexus 4 Kamera Vorschau Aspekt Verhältnis benötigt immer 16x9 Oberflächenansicht? Warum
  • Renderscript über die Unterstützungsbibliothek
  • Booleschen und Integers von strings.xml erhalten
  • Activity.finish () genannt, aber Aktivität bleibt im Speicher geladen
  • Android: Muss Notification.DEFAULT_VIBRATE Vibrationsberechtigung erfordern?
  • So ändern Sie den Titeltext und die Schaltflächen Farbe OHNE ändernde Aktion Überlauf Menü Textfarbe in der neuen Symbolleiste?
  • One Solution collect form web for “Wie sind Java-Objekte im Speicher auf Android gelegt?”

    dalvik/vm/oo/Object.h ist dein Freund hier. Der Kommentar für struct Object sagt:

     /* * 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 Objekte sind besonders; Ihr Layout wird durch das ClassObject struct in Object.h . Array-Objekte sind einfach:

     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]; }; 

    Bei Arrays sind die Breiten in vm/oo/Array.cpp . Booleans sind Breite 1, Objekte haben sizeof(Object*) Länge (in der Regel 4), und alle anderen primitiven Typen haben ihre erwartete (gepackte) Länge.

    Datenobjekte sind ganz einfach:

     /* * 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]; }; 

    Das Layout eines DataObject (alle Nicht-Klasse-Klasse-Instanzen) wird von computeFieldOffsets in vm/oo/Class.cpp . Nach dem Kommentar dort:

     /* * 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. */ 

    So kommen Oberklasse-Felder zuerst (wie üblich), gefolgt von Referenz-Typ-Feldern, gefolgt von einem einzigen 32-Bit-Feld (falls vorhanden, und wenn Padding erforderlich ist, da es eine ungerade Anzahl von 32-Bit-Referenzfeldern gibt) gefolgt von 64 -bit-Felder. Regelmäßige 32-Bit-Felder folgen. Beachten Sie, dass alle Felder 32-Bit oder 64-Bit sind (kürzere Primitive werden gepolstert). Insbesondere, zu diesem Zeitpunkt, die VM nicht speichern Byte / char / short / boolean Felder mit weniger als 4 Bytes, obwohl es sicherlich könnte dies in der Theorie zu unterstützen.

    Beachten Sie, dass dies alles auf dem Lesen des Dalvik-Quellcodes als Commit 43241340 (6. Februar 2013) basiert. Da dieser Aspekt der VM nicht öffentlich dokumentiert zu sein scheint, sollte man sich nicht darauf verlassen, dass es sich um eine stabile Beschreibung des Objektlayouts der VM handelt: Es kann sich im Laufe der Zeit ändern.

    Das Android ist ein Google Android Fan-Website, Alles ├╝ber Android Phones, Android Wear, Android Dev und Android Spiele Apps und so weiter.