Unity beschreibt am 6. Juni 2016 die Änderungen an der Script-Serialisierung in Unity 5.4. Die Engine prüft seit dieser Version genauer, welche Teile eines MonoBehaviour während der Deserialisierung ausgeführt werden.
Die meisten Unity-APIs dürfen nur vom Hauptthread aus aufgerufen werden, etwa in Start oder Update. Konstruktoren und Feldinitialisierer von MonoBehaviour bilden dabei einen Sonderfall. Unity kann Konstruktoren beim Laden und Deserialisieren einer Instanz auf einem anderen Thread ausführen.
Warum Unity 5.4 genauer prüft
Vor Unity 5.4 wurden diese Regeln nicht konsequent durchgesetzt. Das konnte Abstürze, Race Conditions und schwer reproduzierbare Fehler auslösen. Die neue Prüfung macht solche Zugriffe sichtbar und gibt Entwicklern damit einen konkreten Ansatz für die Fehlersuche in bestehenden Projekten.
Die Meldungen unterbrechen den Skriptablauf in Unity 5.4 zunächst in der Regel nicht und lösen meist keine verwaltete Ausnahme aus. Unity kündigte an, dass spätere Versionen hier strenger reagieren können. Beim Umstieg sollten die gemeldeten Stellen deshalb behoben werden.
Dokumentation für Script Serialization
Unity verweist für typische Fälle auf den Abschnitt Script Serialization im offiziellen Manual. Dort geht es um die Daten, die Unity beim Laden von Szenen, Assets und Komponenten wiederherstellt. Für ein älteres Unity-Projekt ist die Umstellung damit nicht nur eine Laufzeitfrage, sondern betrifft auch Editorwerkzeuge und Importprozesse.
Ein früherer Beitrag zur Unity-Serialisierung beschreibt bereits, wie Editor-Daten einen Assembly-Reload überstehen. Unity 5.4 verschiebt den Fokus von der Speicherung auf die zulässige Ausführung während des Deserialisierens.