スクリプトの制限
UnityEvent

スクリプトシリアライゼーション

「もの (オブジェクト)」のシリアライズは、Unity のコアです。Unity の機能の多くは、シリアライゼーションシステムの上に構築されています。

  • インスペクターウィンドウ。インスペクターウィンドウは、それがインスペクトされているプロパティーの値が何であるかを把握するためにC#のAPIを使用しているのではありません。オブジェクトを自分自身でシリアライズするために要求し、その後、シリアライズされたデータを表示します。

  • プレハブ。 内部的には、プレハブは、1 つや複数のゲームオブジェクトとコンポーネントをシリアライズしたデータストリームです。プレハブインスタンスは、シリアライズされたデータに行われるべき変更リストになります。プレハブの概念は、実際には、エディターにおいてのみ存在しています。プレハブの変更は Unity がビルドを行う際、通常のシリアライズの流れの中でベイクされ、それがインスタンス化されたときゲームオブジェクトが、エディター上でプレハブだったのか判断することはできません。

  • インスタンス化。 プレハブ、シーンの中のゲームオブジェクト、他の何か (UnityEngine.Object から派生したオブジェクトはすべてシリアライズ可能) で Instantiate() を呼び出したとき、オブジェクトをシリアライズし新しいオブジェクトを作成します。その後、新しいオブジェクトのデータを「デシリアライズ」します。そのとき、他の UnityEngine.Object が参照される場合、再び同じシリアライズのコードを異なるバリアントで実行し、他の UnityEngine.Object が参照されているかをチェックします。それから、すべての参照された UnityEngine.ObjectInstantiated() されたデータであるがどうかを検証します。参照が(テクスチャのように)「外部」の何かを指している場合は、その参照をそのまま保持し、(子ゲームオブジェクトのように)「内部」の何かを指している場合には、対応するコピーの参照を適用します。

  • 保存。 テキストエディターで .unity シーンファイルを開いたとき、Unity を “force text serialization” に設定している場合は、シリアライザを YAML 形式でバックエンドで実行します。

  • 読み込み。驚くことではないかもしれませんが、後方互換性を持たせた読み込みも同じようにシリアライゼーションの上に構築されたシステムです。エディターでは YAML 形式の読み込みについてシリアライゼーションシステムを使用しているだけでなく、シーンのランタイム読み込み、アセットとアセットバンドルもシリアライゼーションシステムを使用しています。

  • エディターコードのホットリロード。エディタースクリプトを変更するとすべてのエディターウィンドウをシリアライズし(UnityEngine.Objectに由来してます)、そのときすべてのウィンドウは破棄されます。古い C#のコードを破棄し、新しいコードを読み込み、ウィンドウを再作成した後、この新しいウィンドウに戻って、データストリームをデシリアライズします。

  • Resource.GarbageCollectSharedAssets() 。 これは Unity のネイティブなガベージコレクタで、C#のガベージコレクタとは違うものです。これはシーンを読み込んだ後、前のシーンのものが参照されていないかを把握して実行するもので、参照されてないものを破棄できます。ネイティブガベージコレクタは外部の UnityEngine.Objects を参照したすべてのオブジェクトレポートを得たとき、シリアライザモードで実行します。これはシーン 2 を読み込むとき、シーン 1 で使用されたテクスチャについて(使用されてないと報告を受けて)、破棄するものです。

シリアライゼーションシステムは C++で書かれており、すべての内部のオブジェクトタイプ( Texture,AudioClip,Camera など)を使います。シリアライゼーションは、UnityEngine.Object レベルで行われ、各 UnityEngine.Object は毎回、全体をシリアライズします。これらは、他の UnityEngine.Object への参照を含めることができ、参照はシリアライズされたプロパティーを得ます。

今、実際にいくつかのコンテンツを作成し、それが動作することに満足している場合、あまり関係がないことだと思うかもしれません。

これが関係している所は、作成したスクリプトがバックグランドで MonoBehaviour コンポーネントをシリアライズするために、同じシリアライザを使用していることです。すべてのケースにおいて、C# デベロッパーがシリアライザに期待するように動作しません。なぜなら、非常に高いパフォーマンスをシリアライザが要求するためです。このドキュメントでシリアライザがどのように機能するか、それを最大限に活用する方法、いくつかの最適な演習について説明します。

スクリプトにおいてシリアライズするのに必要なこと。

  • public[SerializeField] 属性を持つ
  • static ではないこと
  • const ではないこと
  • readonly ではないこと
  • fieldtype はシリアライズができるタイプである必要があります

どの fieldtype をシリアライズできるか。

  • [Serializable] 属性を持つカスタム非抽象クラス
  • [Serializable] 属性を持つカスタム構造体( Unity4.5 から追加)
  • UnityEngine.Object から派生したオブジェクトの参照
  • プリミティブ型(int, float, double, bool, string, etc.)
  • シリアライズできるフィールドタイプの配列
  • シリアライズできるフィールドタイプの List<T>

シリアライザが期待した動作をしない状況とは。

カスタムクラスは構造体のように動作します。

[Serializable]
class Animal
{
   public string name;
}

class MyScript : MonoBehaviour
{
      public Animal[] animals;
}

ひとつの Animal オブジェクトで 3 つの参照を持つ animals 配列を作成する場合、シリアライゼーションストリームは 3 つのオブジェクトを検索します。デシリアライズしたときそれが3つの異なるオブジェクトになります。参照が必要な複雑なオブジェクトグラフをシリアライズする必要がある場合は、そのすべてを自動的に Unity のシリアライザにやってもらうことはできません。そのオブジェクトグラフを自分でシリアライズするためにいくつかの作業を行う必要があります。Unity 自身のシリアライザを使用せずにシリアライズする方法については、以下の例を参照してください。

これはカスタムクラスにとって、それらのデータは使用されている MonoBehaviour のための完全な シリアライゼーションデータ の一部となるので、「インライン」にシリアライズされたことに注意してください。 public Camera myCamera のように、 UnityEngine.Object 派生クラスで何かへの参照を持つフィールドがある場合、その camera からのデータは、インラインでシリアライズされず、 UnityEngine.Object への実際の参照がシリアライズされます。

カスタムクラスでは null はサポートされません。

さてクイズです。このスクリプトを使用している MonoBehaviour をデシリアライズするとき、どれだけ配分されるでしょうか?

class Test : MonoBehaviour
{
    public Trouble t;
}

[Serializable]
class Trouble
{
   public Trouble t1;
   public Trouble t2;
   public Trouble t3;
}

テストオブジェクトとして、1 アロケーションを期待することはおかしいことではありません。また、テストオブジェクトとトラブルオブジェクトとして 2 アロケーションを期待するのもおかしくありません。正解は 729 です。シリアライザは null をサポートしていません。オブジェクトをシリアライズした際、フィールドが null のとき、その型の新しいオブジェクトをインスタンス化し、それをシリアライズします。明らかにこれは無限のサイクルにつながる可能性があるため、おまじないとして相対的に 7 層の深さまでと制限されています。その(7 層になった)時点で、カスタムクラス/構造体やリストと配列の型を持つフィールドのシリアライズを停止します。

サブシステムの多くは、シリアライゼーションシステム上でビルドするため、Test monobehaviour のためのこの予想外に大きなシリアライゼーションのストリームは、これらすべてのサブシステムの実行の速度低下を招きます。Unityがさまざまなプロジェクトにおけるパフォーマンスの問題を調査すると、ほとんど常にこの問題がでてきました。このような状況のため Unity4.5 で警告を追加しました。

ポリモーフィズムはサポートされていません

もし、public Animal[] animals に犬、猫、キリンのインスタンスを収納して、シリアライズを行うと、3 つの Animal インスタンスを持つことになります。

この制限に対処する一つの方法は、そのシリアライズされたインラインを取得する custom classes のみに適用することです。他の ‘UnityEngine.Object’ への参照は、実際の参照としてシリアライズされて、ポリモーフィズムは正しく動作します。あなたは ‘ScriptableObject’ 継承クラスや別の ‘MonoBehaviour’ 継承クラスを作り、それらを参照すると思います。それの欠点は、どこかにその ScriptableObject や Monobehaviour オブジェクトを保存する必要があり、インラインにうまくそれをシリアライズできないことです。

これらの制限の理由は、シリアライゼーションシステムのコア部分の一つが事前に既知のオブジェクトのデータストリームのレイアウトであり、フィールド内の処理の内容ではなく、クラスのフィールドの型に依存することです。

Unity のシリアライザがサポートしていないものをシリアライズするためには何をすればいいですか?

多くの場合、最善のアプローチはシリアライズのコールバックを使用することです。シリアライザがフィールドからデータを読み込む前や、書き込みが完了した後に通知させることができます。実際にシリアライズするときよりも、実行時にシリアライズするのが難しいデータを別データとして持たせたいときに使用することができます。 Unity がデータをシリアライズする前に、Unityがシリアライズできる形式に変換し、デシリアライズした後にも、本来持たせたかった形式に入れなおすために使用します。

例えば、データをツリー構造にしたい場合、Unity に直接データ構造をシリアライズさせると、“no support for null” 制限によりデータストリームは、非常に大きくなり、多くのシステムにおいて性能の劣化につながります。

using UnityEngine;
using System.Collections.Generic;
using System;

public class VerySlowBehaviourDoNotDoThis : MonoBehaviour
{
    [Serializable]
    public class Node
    {
        public string interestingValue = "value";

        //The field below is what makes the serialization data become huge because
        //it introduces a 'class cycle'.
        public List<Node> children = new List<Node>();
    }
    
    //this gets serialized  
    public Node root = new Node();  

    void OnGUI()
    {
        Display (root);
    }

    void Display(Node node)
    {
        GUILayout.Label ("Value: ");
        node.interestingValue = GUILayout.TextField(node.interestingValue, GUILayout.Width(200));

        GUILayout.BeginHorizontal ();
        GUILayout.Space (20);
        GUILayout.BeginVertical ();

        foreach (var child in node.children)
            Display (child);
        if (GUILayout.Button ("Add child"))
            node.children.Add (new Node ());

        GUILayout.EndVertical ();
        GUILayout.EndHorizontal ();
    }
}

代わりに、Unity が直接ツリーをシリアライズしないように指示し、Unity のシリアライザに適したシリアライズした形式のツリーをフィールドで分けて保存します。

using UnityEngine;
using System.Collections.Generic;
using System;

public class BehaviourWithTree : MonoBehaviour, ISerializationCallbackReceiver
{
    //node class that is used at runtime
    public class Node
    {
        public string interestingValue = "value";
        public List<Node> children = new List<Node>();
    }

    //node class that we will use for serialization
    [Serializable]
    public struct SerializableNode
    {
        public string interestingValue;
        public int childCount;
        public int indexOfFirstChild;
    }

    //the root of what we use at runtime. not serialized.
    Node root = new Node(); 

    //the field we give unity to serialize.
    public List<SerializableNode> serializedNodes;

    public void OnBeforeSerialize()
    {
        //unity is about to read the serializedNodes field's contents. lets make sure
        //we write out the correct data into that field "just in time".
        serializedNodes.Clear();
        AddNodeToSerializedNodes(root);
    }

    void AddNodeToSerializedNodes(Node n)
    {
        var serializedNode = new SerializableNode () {
            interestingValue = n.interestingValue,
            childCount = n.children.Count,
            indexOfFirstChild = serializedNodes.Count+1
        };
        serializedNodes.Add (serializedNode);
        foreach (var child in n.children)
            AddNodeToSerializedNodes (child);
    }

    public void OnAfterDeserialize()
    {
        //Unity has just written new data into the serializedNodes field.
        //let's populate our actual runtime data with those new values.

        if (serializedNodes.Count > 0)
            root = ReadNodeFromSerializedNodes (0);
        else
            root = new Node ();
    }

    Node ReadNodeFromSerializedNodes(int index)
    {
        var serializedNode = serializedNodes [index];
        var children = new List<Node> ();
        for(int i=0; i!= serializedNode.childCount; i++)
            children.Add(ReadNodeFromSerializedNodes(serializedNode.indexOfFirstChild + i));
    
        return new Node() {
            interestingValue = serializedNode.interestingValue,
            children = children
        };
    }

    void OnGUI()
    {
        Display (root);
    }

    void Display(Node node)
    {
        GUILayout.Label ("Value: ");
        node.interestingValue = GUILayout.TextField(node.interestingValue, GUILayout.Width(200));

        GUILayout.BeginHorizontal ();
        GUILayout.Space (20);
        GUILayout.BeginVertical ();

        foreach (var child in node.children)
            Display (child);
        if (GUILayout.Button ("Add child"))
            node.children.Add (new Node ());

        GUILayout.EndVertical ();
        GUILayout.EndHorizontal ();
    }
}

通常メインスレッド上では実行されないシリアライザから来るこれらのコールバックを含むシリアライザに注意してください。実行できる Unity API の呼び出しが大きく制限されています。ただし、Unityがシリアライズできない形式からのUnityがシリアライズできる形式からデータを取得し、必要なデータ変換ができます。

スクリプトのシリアライズエラー

スクリプトがコンストラクターかフィールドイニシアライザーから Unity API を呼び出すとき、または、デシリアライゼーション (読み込み) の間に、エラーがトリガーされます。ここでは、エラーの要因となる良くない例を紹介します。

Unity API のほとんどは、例えば、MonoBehaviour の StartUpdate などメインスレッドから呼び出すべきです。Unity API の一部だけが、Debug.LogMathf などのスクリプトコンストラクターやフィールドイニシアライザーから呼び出されるべきです。その理由は、デシリアライゼーションの間、クラスのインスタンスをコンストラクトするときにはコンストラクターが呼び出され、これはメインスレッド上でのみ実行されるべきなのに、最終的にはメインスレッド以外で実行されるからです。そのため、スクリプトコンストラクターやフィールドイニシアライザーから Unity API すべてを呼び出す場合、エラーが発生します。

Unity 5.4 ではたいていの場合、これらのエラーには例外が投げられず、スクリプトの処理を妨げることはありません。これにより、プロジェクトを Unity 5.4 にアップグレードするプロセスは簡単になります。ただし、これらのエラーは、後続の Unity リリースでも例外を発生させる要因になります。そのため、5.4 にアップグレードするときはすぐに、すべてのエラーを修正するべきです。

Unity API のコンストラクターかフィールドイニシアライザーからの呼び出し

Unity が MonoBehaviour または ScriptableObject の派生クラスのインスタンスを作成するとき、マネージドオブジェクトを作成するためにデフォルトコンストラクターを呼び出します。これは、メインループに入る前と画面が完全に読み込まれる前に発生します。フィールドイニシアライザーもマネージドオブジェクトのデフォルトコンストラクターから呼び出されています。一般的には、大抵の Unity API にとっては安全でないため、Unity API をコンストラクターからは呼び出さないでください。

悪い

//NOTE: THIS IS A DELIBERATE BAD EXAMPLE TO DEMONSTRATE POOR PRACTISE  - DO NOT REUSE

public class FieldAPICallBehaviour : MonoBehaviour
{
   public GameObject foo = GameObject.Find("foo");   // This line will generate an error 
                        // message as it should not be called from within a constructor

}
//NOTE: THIS IS A BAD EXAMPLE TO DEMONSTRATE POOR PRACTISE - DO NOT REUSE

public class ConstructorAPICallBehaviour : MonoBehaviour
{
   ConstructorAPICallBehaviour()
   {
       GameObject.Find("foo");   // This line will generate an error message
                                // as it should not be called from within a constructor
   }
}

これらの例は両方ともエラーメッセージ「Find is not allowed to be called from a MonoBehaviour constructor (or instance field initializer), call in in Awake or Start instead.(Find は MonoBehaviour コンストラクター、または、インスタンスフィールドイニシアライザーから呼び出すことはできません。代わりに、Awake か Start から呼び出してください。)」を発します。

MonoBehaviour.Start で Unity API への呼び出しを行うことにより修正できます。

シリアライズ中に呼び出されるメソッド

Unity がシーンを読み込む場合、保存されたシーンからマネージドオブジェクトを再作成し、保存した値に設定します (デシリアライゼーション)。マネージドオブジェクトを作成するためには、オブジェクトのデフォルトコンストラクターを呼び出します。オブジェクトを参照するフィールドが保存され (シリアライゼーション)、オブジェクトのデフォルトコンストラクターが Unity API を呼び出すと、シーンを読み込む際にエラーが発生します。以前のエラーで、まだメインループを開始しておらず、シーンが完全に読み込まれていません。この状態は、たいていの Unity API にとって安全ではないと考えられます。

悪い

//NOTE: THIS IS A BAD EXAMPLE TO DEMONSTRATE POOR PRACTISE  - DO NOT REUSE

public class SerializationAPICallBehaviour : MonoBehaviour
{
   [System.Serializable]
   public class CallAPI
   {
       public CallAPI()
       {
           GameObject.Find("foo"); // This line will generate an error message 
                                                 // as it should not be called during serialization

       }
   }

   CallAPI callAPI;
}

この例はエラーメッセージ「Find is not allowed to be called during serialization, call it from Awake or Start instead. (Find はシリアライゼーションの間は呼び出しすることができません。代わりに、Awake か Start から呼び出してください。)」を発します。

これを修正するには、コードのリファクターリングを行い、シリアライズされたオブジェクトに対して、コンストラクターから Unity API の呼び出しを行わないようにします。オブジェクトに対し Unity API の呼び出しが必要な場合は、メインスレッド内で、StartAwakeUpdate などの MonoBehaviour コールバックの 1つから行うようにします。

スクリプトの制限
UnityEvent