No Unity, como implemento corretamente o padrão singleton?

Vi vários vídeos e tutoriais para criar objetos singleton no Unity, principalmente para um GameManager, que parecem usar abordagens diferentes para instanciar e validar um singleton.

Existe uma abordagem correta, ou melhor, preferida para isso?

Os dois exemplos principais que encontrei são:

Primeiro

public class GameManager
{
    private static GameManager _instance;

    public static GameManager Instance
    {
        get
        {
            if(_instance == null)
            {
                _instance = GameObject.FindObjectOfType<GameManager>();
            }

            return _instance;
        }
    }

    void Awake()
    {
        DontDestroyOnLoad(gameObject);
    }
}

Segundo

public class GameManager
{
    private static GameManager _instance;

    public static GameManager Instance
    {
        get
        {
            if(_instance == null)
            {
                instance = new GameObject("Game Manager");
                instance.AddComponent<GameManager>();
            }

            return _instance;
        }
    }

    void Awake()
    {
        _instance = this;
    }
}

A principal diferença que posso ver entre os dois é:

A primeira abordagem tentará navegar na pilha de objetos do jogo para encontrar uma instância da GameManagerqual, mesmo que isso só aconteça (ou só aconteça), uma vez parece que pode ser muito não otimizado à medida que as cenas aumentam de tamanho durante o desenvolvimento.

Além disso, a primeira abordagem marca o objeto a não ser excluído quando o aplicativo muda de cena, o que garante que o objeto persista entre as cenas. A segunda abordagem não parece aderir a isso.

A segunda abordagem parece estranha, pois no caso em que a instância é nula no getter, ela cria um novo GameObject e atribui um componente GameManger a ele. No entanto, isso não pode ser executado sem que o componente GameManager já esteja anexado a um objeto na cena, então isso está me causando alguma confusão.

Existem outras abordagens recomendadas ou um híbrido dos dois acima? Existem muitos vídeos e tutoriais sobre singletons, mas todos diferem tanto que é difícil fazer comparações entre os dois e, portanto, uma conclusão sobre qual é a melhor / preferida abordagem.

Depende, mas geralmente eu uso um terceiro método. O problema com os métodos que você usou é que, no início, o objeto é incluído, ele não os remove da árvore e ainda pode ser criado instanciando muitas chamadas, o que pode tornar as coisas realmente confusas.

public class SomeClass : MonoBehaviour {
    private static SomeClass _instance;

    public static SomeClass Instance { get { return _instance; } }


    private void Awake()
    {
        if (_instance != null && _instance != this)
        {
            Destroy(this.gameObject);
        } else {
            _instance = this;
        }
    }
}

O problema com as duas implementações é que elas não destroem um objeto criado posteriormente. Pode funcionar, mas é possível jogar uma chave de macaco nos trabalhos que podem resultar em um erro de depuração muito difícil na linha. Certifique-se de verificar em Despertar se já existe uma instância e, se houver, destruindo a nova instância.

Aqui está um resumo rápido:

                 Create object   Removes scene   Global    Keep across
               if not in scene?   duplicates?    access?   Scene loads?

Method 1              No              No           Yes        Yes

Method 2              Yes             No           Yes        No

PearsonArtPhoto       No              Yes          Yes        No
Method 3

Portanto, se tudo o que importa é o acesso global, todos os três terão o que você precisa. O uso do padrão Singleton pode ser um pouco ambíguo sobre se queremos instanciação lenta, exclusividade forçada ou acesso global. Portanto, pense cuidadosamente sobre o motivo pelo qual você está alcançando o singleton e escolha uma implementação que acerte esses recursos. do que usar um padrão para todos os três quando você precisar apenas de um.

(por exemplo, se meu jogo sempre tiver um GameManager, talvez eu não me importe com instâncias preguiçosas - talvez seja apenas o acesso global com existência garantida e exclusividade -, nesse caso, uma classe estática obtém exatamente esses recursos de maneira concisa, sem considerações de carregamento de cena)

... mas definitivamente não use o Método 1 como está escrito. O Find pode ser pulado mais facilmente com a abordagem Awake () do Method2 / 3, e se mantivermos o gerente entre as cenas, é provável que desejemos matar duplicados, caso possamos carregar entre duas cenas com um gerente já nelas.

A melhor implementação de um Singletonpadrão genérico para o Unity que conheço é (é claro) o meu.

Ele pode fazer tudo , e fá-lo perfeitamente e de forma eficiente :

Create object        Removes scene        Global access?               Keep across
if not in scene?     duplicates?                                       Scene loads?

     Yes                  Yes                  Yes                     Yes (optional)

Outras vantagens:

• É seguro para threads .
• Evita erros relacionados à aquisição (criação) de instâncias singleton quando o aplicativo é encerrado, garantindo que os singletons não possam ser criados depois OnApplicationQuit(). (E o faz com uma única bandeira global, em vez de cada tipo de singleton ter o seu próprio)
• Ele usa o Mono Update do Unity 2017 (aproximadamente equivalente ao C # 6). (Mas pode ser facilmente adaptado para a versão antiga)
• Ele vem com alguns doces grátis!

E porque compartilhar é cuidar , aqui está:

public abstract class Singleton<T> : Singleton where T : MonoBehaviour
{
    #region  Fields
    [CanBeNull]
    private static T _instance;

    [NotNull]
    // ReSharper disable once StaticMemberInGenericType
    private static readonly object Lock = new object();

    [SerializeField]
    private bool _persistent = true;
    #endregion

    #region  Properties
    [NotNull]
    public static T Instance
    {
        get
        {
            if (Quitting)
            {
                Debug.LogWarning($"[{nameof(Singleton)}<{typeof(T)}>] Instance will not be returned because the application is quitting.");
                // ReSharper disable once AssignNullToNotNullAttribute
                return null;
            }
            lock (Lock)
            {
                if (_instance != null)
                    return _instance;
                var instances = FindObjectsOfType<T>();
                var count = instances.Length;
                if (count > 0)
                {
                    if (count == 1)
                        return _instance = instances[0];
                    Debug.LogWarning($"[{nameof(Singleton)}<{typeof(T)}>] There should never be more than one {nameof(Singleton)} of type {typeof(T)} in the scene, but {count} were found. The first instance found will be used, and all others will be destroyed.");
                    for (var i = 1; i < instances.Length; i++)
                        Destroy(instances[i]);
                    return _instance = instances[0];
                }

                Debug.Log($"[{nameof(Singleton)}<{typeof(T)}>] An instance is needed in the scene and no existing instances were found, so a new instance will be created.");
                return _instance = new GameObject($"({nameof(Singleton)}){typeof(T)}")
                           .AddComponent<T>();
            }
        }
    }
    #endregion

    #region  Methods
    private void Awake()
    {
        if (_persistent)
            DontDestroyOnLoad(gameObject);
        OnAwake();
    }

    protected virtual void OnAwake() { }
    #endregion
}

public abstract class Singleton : MonoBehaviour
{
    #region  Properties
    public static bool Quitting { get; private set; }
    #endregion

    #region  Methods
    private void OnApplicationQuit()
    {
        Quitting = true;
    }
    #endregion
}
//Free candy!

Gostaria apenas de acrescentar que pode ser útil ligar DontDestroyOnLoadse você quiser que o seu singleton persista nas cenas.

public class Singleton : MonoBehaviour
{ 
    private static Singleton _instance;

    public static Singleton Instance 
    { 
        get { return _instance; } 
    } 

    private void Awake() 
    { 
        if (_instance != null && _instance != this) 
        { 
            Destroy(this.gameObject);
            return;
        }

        _instance = this;
        DontDestroyOnLoad(this.gameObject);
    } 
}

Outra opção pode ser dividir a classe em duas partes: uma classe estática regular para o componente Singleton e um MonoBehaviour que atua como um controlador para a instância singleton. Dessa forma, você tem total controle sobre a construção do singleton, e ele persistirá nas cenas. Isso também permite adicionar controladores a qualquer objeto que possa precisar dos dados do singleton, em vez de precisar percorrer a cena para encontrar um componente específico.

public class Singleton{
    private Singleton(){
        //Class initialization goes here.
    }

    public void someSingletonMethod(){
        //Some method that acts on the Singleton.
    }

    private static Singleton _instance;
    public static Singleton Instance 
    { 
        get { 
            if (_instance == null)
                _instance = new Singleton();
            return _instance; 
        }
    } 
}

public class SingletonController: MonoBehaviour{
   //Create a local reference so that the editor can read it.
   public Singleton instance;
   void Awake(){
       instance = Singleton.Instance;
   }
   //You can reference the singleton instance directly, but it might be better to just reflect its methods in the controller.
   public void someMethod(){
       instance.someSingletonMethod();
   }
} 

Aqui está minha implementação de uma classe abstrata singleton abaixo. Aqui está como ele se compara aos 4 critérios

             Create object   Removes scene   Global    Keep across
           if not in scene?   duplicates?    access?   Scene loads?

             No (but why         Yes           Yes        Yes
             should it?)

Ele tem algumas outras vantagens em comparação com alguns dos outros métodos aqui:

• Não usa o FindObjectsOfTypeque é um assassino de desempenho
• É flexível, pois não precisa criar um novo objeto de jogo vazio durante o jogo. Você simplesmente o adiciona no editor (ou durante o jogo) a um objeto de jogo de sua escolha.

• É seguro para discussão

  using System.Collections.Generic;
  using System.Linq;
  using UnityEngine;
  
  public abstract class Singleton<T> : MonoBehaviour where T : Singleton<T>
  {
      #region  Variables
      protected static bool Quitting { get; private set; }
  
      private static readonly object Lock = new object();
      private static Dictionary<System.Type, Singleton<T>> _instances;
  
      public static T Instance
      {
          get
          {
              if (Quitting)
              {
                  return null;
              }
              lock (Lock)
              {
                  if (_instances == null)
                      _instances = new Dictionary<System.Type, Singleton<T>>();
  
                  if (_instances.ContainsKey(typeof(T)))
                      return (T)_instances[typeof(T)];
                  else
                      return null;
              }
          }
      }
  
      #endregion
  
      #region  Methods
      private void OnEnable()
      {
          if (!Quitting)
          {
              bool iAmSingleton = false;
  
              lock (Lock)
              {
                  if (_instances == null)
                      _instances = new Dictionary<System.Type, Singleton<T>>();
  
                  if (_instances.ContainsKey(this.GetType()))
                      Destroy(this.gameObject);
                  else
                  {
                      iAmSingleton = true;
  
                      _instances.Add(this.GetType(), this);
  
                      DontDestroyOnLoad(gameObject);
                  }
              }
  
              if(iAmSingleton)
                  OnEnableCallback();
          }
      }
  
      private void OnApplicationQuit()
      {
          Quitting = true;
  
          OnApplicationQuitCallback();
      }
  
      protected abstract void OnApplicationQuitCallback();
  
      protected abstract void OnEnableCallback();
      #endregion
  }

Na verdade, existe uma maneira pseudo-oficial de usar o Singleton no Unity. Aqui está a explicação: basicamente crie uma classe Singleton e faça com que seus scripts sejam herdados dessa classe.

Vou seguir minha implementação também para as gerações futuras.

void Awake()
    {
        if (instance == null)
            instance = this;
        else if (instance != this)
            Destroy(gameObject.GetComponent(instance.GetType()));
        DontDestroyOnLoad(gameObject);
    }

Para mim, essa linha Destroy(gameObject.GetComponent(instance.GetType()));é muito importante porque uma vez deixei um script singleton em outro gameObject em uma cena e todo o objeto do jogo estava sendo excluído. Isso destruirá o componente apenas se ele já existir.

Eu escrevi uma classe singleton que facilita a criação de objetos singleton. É um script MonoBehaviour, para que você possa usar as Coroutines. É baseado neste artigo do Unity Wiki , e adicionarei a opção de criá-lo no Prefab posteriormente.

Portanto, você não precisa escrever os códigos Singleton. Basta baixar esta classe base Singleton.cs , adicioná-la ao seu projeto e criar seu singleton estendendo-o:

public class MySingleton : Singleton<MySingleton> {
  protected MySingleton () {} // Protect the constructor!

  public string globalVar;

  void Awake () {
      Debug.Log("Awoke Singleton Instance: " + gameObject.GetInstanceID());
  }
}

Agora sua classe MySingleton é um singleton e você pode chamá-lo por Instância:

MySingleton.Instance.globalVar = "A";
Debug.Log ("globalVar: " + MySingleton.Instance.globalVar);

Aqui está um tutorial completo: http://www.bivis.com.br/2016/05/04/unity-reusable-singleton-tutorial/