ISerializable Schnittstelle
Definition
Wichtig
Einige Informationen beziehen sich auf Vorabversionen, die vor dem Release ggf. grundlegend überarbeitet werden. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.
Die Serialisierbarkeit einer Klasse wird durch die Klasse aktiviert, die den Java implementiert.
[Android.Runtime.Register("java/io/Serializable", "", "Java.IO.ISerializableInvoker")]
public interface ISerializable : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable[<Android.Runtime.Register("java/io/Serializable", "", "Java.IO.ISerializableInvoker")>]
type ISerializable = interface
interface IJavaObject
interface IDisposable
interface IJavaPeerable- Abgeleitet
- Attribute
- Implementiert
Hinweise
Die Serialisierbarkeit einer Klasse wird durch die Klasse aktiviert, die die java.io.Serializable-Schnittstelle implementiert.
<starke>Warnung: Die Deserialisierung nicht vertrauenswürdiger Daten ist inhärent gefährlich und sollte vermieden werden. Nicht vertrauenswürdige Daten sollten sorgfältig überprüft werden. </strong>
Klassen, die diese Schnittstelle nicht implementieren, weisen keinen serialisierten oder deserialisierten Zustand auf. Alle Untertypen einer serialisierbaren Klasse sind selbst serialisierbar. Die Serialisierungsschnittstelle hat keine Methoden oder Felder und dient nur zur Identifizierung der Semantik, die serialisierbar ist.
Damit Untertypen von nicht serialisierbaren Klassen serialisiert werden können, übernimmt der Untertyp möglicherweise die Verantwortung für das Speichern und Wiederherstellen des Zustands der öffentlichen, geschützten und (falls zugänglichen) Paketfelder des Supertyps. Der Untertyp kann diese Verantwortung nur übernehmen, wenn die erweiterte Klasse über einen barrierefreien No-Arg-Konstruktor verfügt, um den Zustand der Klasse zu initialisieren. Es ist ein Fehler, eine Klasse serialisierbar zu deklarieren, wenn dies nicht der Fall ist. Der Fehler wird zur Laufzeit erkannt.
Während der Deserialisierung werden die Felder nicht serialisierbarer Klassen mithilfe des öffentlichen oder geschützten No-Arg-Konstruktors der Klasse initialisiert. Auf einen no-arg-Konstruktor muss auf die unterklasse zugegriffen werden kann, die serialisierbar ist. Die Felder serialisierbarer Unterklassen werden aus dem Datenstrom wiederhergestellt.
Beim Durchlaufen eines Diagramms ist möglicherweise ein Objekt aufgetreten, das die serialisierbare Schnittstelle nicht unterstützt. In diesem Fall wird die NotSerializableException ausgelöst und identifiziert die Klasse des nicht serialisierbaren Objekts.
Klassen, die während des Serialisierungs- und Deserialisierungsprozesses spezielle Behandlung erfordern, müssen spezielle Methoden mit diesen genauen Signaturen implementieren:
private void writeObject(java.io.ObjectOutputStream out)
throws IOException
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;
private void readObjectNoData()
throws ObjectStreamException;
Die writeObject-Methode ist für das Schreiben des Zustands des Objekts für die jeweilige Klasse verantwortlich, damit die entsprechende readObject-Methode sie wiederherstellen kann. Der Standardmechanismus zum Speichern der Felder des Objekts kann durch Aufrufen von out.defaultWriteObject aufgerufen werden. Die Methode muss sich nicht mit dem Staat befassen, der zu seinen Superklassen oder Unterklassen gehört. Der Zustand wird gespeichert, indem die einzelnen Felder mithilfe der writeObject-Methode oder mithilfe der Methoden für primitive Datentypen geschrieben werden, die von DataOutput unterstützt werden.
Die readObject-Methode ist für das Lesen aus dem Datenstrom und das Wiederherstellen der Klassenfelder verantwortlich. Möglicherweise wird in.defaultReadObject aufgerufen, um den Standardmechanismus zum Wiederherstellen der nicht statischen und nicht vorübergehenden Felder des Objekts aufzurufen. Die defaultReadObject-Methode verwendet Informationen im Datenstrom, um die Felder des im Datenstrom gespeicherten Objekts mit den entsprechenden benannten Feldern im aktuellen Objekt zuzuweisen. Dies behandelt den Fall, wenn sich die Klasse weiterentwickelt hat, um neue Felder hinzuzufügen. Die Methode muss sich nicht mit dem Staat befassen, der zu seinen Superklassen oder Unterklassen gehört. Der Zustand wird wiederhergestellt, indem Daten aus objectInputStream für die einzelnen Felder gelesen und Zuordnungen zu den entsprechenden Feldern des Objekts vorgenommen werden. Das Lesen von primitiven Datentypen wird von DataInput unterstützt.
Die readObjectNoData-Methode ist für die Initialisierung des Zustands des Objekts für die jeweilige Klasse verantwortlich, wenn der Serialisierungsstream die angegebene Klasse nicht als Superklasse deserialisierten Objekts auflistet. Dies kann in Fällen auftreten, in denen die empfangende Partei eine andere Version der Klasse der deserialisierten Instanz als die sendende Partei verwendet, und die Version des Empfängers erweitert Klassen, die nicht durch die Version des Absenders erweitert werden. Dies kann auch auftreten, wenn der Serialisierungsstream manipuliert wurde; daher ist readObjectNoData nützlich, um deserialisierte Objekte trotz eines "feindlichen" oder unvollständigen Quelldatenstroms ordnungsgemäß zu initialisieren.
Serialisierbare Klassen, die ein alternatives Objekt festlegen müssen, das beim Schreiben eines Objekts in den Datenstrom verwendet werden soll, sollten diese spezielle Methode mit der genauen Signatur implementieren:
ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException;
Diese writeReplace-Methode wird durch Serialisierung aufgerufen, wenn die Methode vorhanden ist und über eine methode, die in der Klasse des serialisierten Objekts definiert ist, zugänglich wäre. Daher kann die Methode privaten, geschützten und paketgeschützten Zugriff haben. Der Unterklassenzugriff auf diese Methode folgt java-Barrierefreiheitsregeln.
Klassen, die eine Ersetzung festlegen müssen, wenn eine Instanz davon aus dem Datenstrom gelesen wird, sollten diese spezielle Methode mit der genauen Signatur implementieren.
ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException;
Diese readResolve-Methode folgt den gleichen Aufrufregeln und Barrierefreiheitsregeln wie writeReplace.
Die Serialisierungslaufzeit ordnet jeder serialisierbaren Klasse eine Versionsnummer zu, die als serialVersionUID bezeichnet wird, die während der Deserialisierung verwendet wird, um zu überprüfen, ob der Absender und Empfänger eines serialisierten Objekts Klassen für dieses Objekt geladen haben, die in Bezug auf die Serialisierung kompatibel sind. Wenn der Empfänger eine Klasse für das Objekt geladen hat, das über eine andere serialVersionUID als die der Klasse des entsprechenden Absenders verfügt, führt die Deserialisierung zu einer InvalidClassException. Eine serialisierbare Klasse kann eine eigene serialVersionUID explizit deklarieren, indem ein Feld deklariert "serialVersionUID" wird, das statisch, endgültig und vom Typ sein longmuss:
ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;
Wenn eine serialisierbare Klasse keine serialVersionUID explizit deklariert, berechnet die Serialisierungslaufzeit einen standardmäßigen serialVersionUID-Wert für diese Klasse basierend auf verschiedenen Aspekten der Klasse, wie in der Java(TM) Object Serialization Specification beschrieben. Es wird <>jedoch dringend empfohlen</em> empfohlen, dass alle serialisierbaren Klassen SerialVersionUID-Werte explizit deklarieren, da die serialVersionUID-Standardberechnung streng vertraulich für Klassendetails ist, die je nach Compilerimplementierung variieren können und somit zu unerwarteten InvalidClassExceptionErgebnissen während der Deserialisierung führen können. Daher muss eine serialisierbare Klasse einen expliziten serialVersionUID-Wert deklarieren, um einen konsistenten serialVersionUID-Wert über verschiedene Java-Compilerimplementierungen hinweg zu gewährleisten. Es wird auch dringend empfohlen, dass explizite serialVersionUID-Deklarationen den private Modifizierer verwenden, da solche Deklarationen nur für die sofort deklarierenden Klassen-serialVersionUID-Felder als geerbte Member nicht nützlich sind. Arrayklassen können keine explizite serialVersionUID deklarieren, sodass sie immer den berechneten Standardwert aufweisen, aber die Anforderung für übereinstimmende serialVersionUID-Werte wird für Arrayklassen aufgehoben.
Die Android-Implementierung der serialVersionUID-Berechnung ändert sich für einige Klassen geringfügig, wenn Sie android N verwenden. Um die Kompatibilität beizubehalten, ist diese Änderung nur aktiviert, wenn die Ziel-SDK-Version der Anwendung auf 24 oder höher festgelegt ist. Es wird dringend empfohlen, ein explizites serialVersionUID-Feld zu verwenden, um Kompatibilitätsprobleme zu vermeiden.
<h3>Implement Serializable Judiciously</h3> Refer to Effective Java's chapter on serialization for thorough coverage of the serialization API. Im Buch wird erläutert, wie Sie diese Schnittstelle verwenden, ohne die Wartungsfreundlichkeit Ihrer Anwendung zu beeinträchtigen.
<h3>Empfohlene Alternativen</h3><starke>JSON</strong> ist präzise, lesbar und effizient. Android enthält sowohl eine als auch eine android.util.JsonReader streaming APIorg.json.JSONObject tree API json-Datei zum Lesen und Schreiben. Verwenden Sie eine Bindungsbibliothek wie GSON , um Java-Objekte direkt zu lesen und zu schreiben.
In 1.1 hinzugefügt.
Java-Dokumentation für java.io.Serializable.
Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die vom Android Open Source-Projekt erstellt und freigegeben werden und gemäß den in der Creative Commons 2.5 Attribution License beschriebenen Begriffen verwendet werden.
Eigenschaften
| Handle |
Ruft den JNI-Wert des zugrunde liegenden Android-Objekts ab. (Geerbt von IJavaObject) |
| JniIdentityHashCode |
Gibt den Wert |
| JniManagedPeerState |
Status des verwalteten Peers. (Geerbt von IJavaPeerable) |
| JniPeerMembers |
Mitgliedszugriff und Aufrufunterstützung. (Geerbt von IJavaPeerable) |
| PeerReference |
Gibt eine JniObjectReference der umbrochenen Java-Objektinstanz zurück. (Geerbt von IJavaPeerable) |
Methoden
| Disposed() |
Wird aufgerufen, wenn die Instanz verworfen wurde. (Geerbt von IJavaPeerable) |
| DisposeUnlessReferenced() |
Wenn keine offenen Verweise auf diese Instanz vorhanden sind, wird nichts aufgerufen |
| Finalized() |
Wird aufgerufen, wenn die Instanz abgeschlossen wurde. (Geerbt von IJavaPeerable) |
| SetJniIdentityHashCode(Int32) |
Legen Sie den von |
| SetJniManagedPeerState(JniManagedPeerStates) |
Die Serialisierbarkeit einer Klasse wird durch die Klasse aktiviert, die den Java implementiert. (Geerbt von IJavaPeerable) |
| SetPeerReference(JniObjectReference) |
Legen Sie den von |
| UnregisterFromRuntime() |
Heben Sie die Registrierung dieser Instanz auf, damit die Laufzeit sie nicht aus zukünftigen Java.Interop.JniRuntime+JniValueManager.PeekValue Aufrufen zurückgibt. (Geerbt von IJavaPeerable) |
Erweiterungsmethoden
| JavaCast<TResult>(IJavaObject) |
Führt eine android-laufzeitgecheckte Typkonvertierung aus. |
| JavaCast<TResult>(IJavaObject) |
Die Serialisierbarkeit einer Klasse wird durch die Klasse aktiviert, die den Java implementiert. |
| GetJniTypeName(IJavaPeerable) |
Die Serialisierbarkeit einer Klasse wird durch die Klasse aktiviert, die den Java implementiert. |