学习唐老狮基础框架课程时的记录与思考
ReadMe没有目录不便查阅，丢两个有目录的地址
Wiki 知乎

public class BaseManager<T> where T:new()
{//懒汉模式，当访问时，才实例化
    private static T instance;

    public static T GetInstance()
    {   
        if (instance == null)
            instance = new T();
        return instance;
    }
}

懒汉模式在访问时才实例化，避免了不常用的单例占用内存
饿汉模式在静态变量被记入内存时，就一起实例化了，坏处是占用内存，好处是提前实例化避免了线程不安全

运行最初，内存中只有该类的instance声明，类并没有实例化，当调用GetInstance（）时，会执行一系列的游戏物体创建与单例类的挂载等操作，最终返回单例类。

public class SingletonAutoMono<T> : MonoBehaviour where T : MonoBehaviour
{
    private static T instance;

    public static T GetInstance()
    {//当访问单例，单例为空时，创建GameObjcet并附加脚本
        if( instance == null )
        {
            GameObject obj = new GameObject();
        //设置对象的名字为脚本名
            obj.name = typeof(T).ToString();
        //让这个单例模式对象 过场景 不移除
            DontDestroyOnLoad(obj);
            instance = obj.AddComponent<T>();
        }
        return instance;
    }

}

场景加载时，挂载该脚本的游戏物体被创建，脚本也会实例化，即场景加载时，该单例类就已经存在

public class SingletonMono<T> : MonoBehaviour where T: MonoBehaviour
{
    private static T instance;

    public static T GetInstance()
    {
     return instance;
    }

 protected virtual void Awake()
  {//在GameObject创建时，给instance赋值
      instance = this as T;//父类转子类
   }

}

DontDestroyOnLoad（obj）是将该GameObject标记为切换场景不删除，在运行项目时，可以从Hierarchy面板中的DontDestroyOnLoad场景中找到不会删除的obj。

MonoBehaviour挂载的GameObject创建时，脚本会跟随创建。
在AddComponent时，也会创建脚本类，达到实例化的目的。
以上两种情况都会触发Awake方法

1. 调用PoolMgr.GetObj(子弹名称，拿到子弹后执行的方法())
2. GetObj()方法内，判断是否有对应的对象池（1:有对象池，取对象池内的物体 2:无对象池说明没有该物体，创建物体 3：有对象池但为空，创建物体），激活物体并传入委托
3. 访问到PoolData时，调用到GetObj（）从list中移出，并返回到PoolMgr

1. 调用PoolMgr.PushObj(对象名称，物体对象)
2. PushObj()方法内，判断是否有对象池（1:有对象池，调用对象池的PushObj，压入物体并失活 2:无对象池时，实例化一个对象池传入要缓存的物体，并记录对象池到字典）
3. 对象池失活物体并记入list,将物体的父物体改为自己，方便浏览

这种对象池只负责收纳，对于不使用的物体无法自动回收，需要有个外部的类管理取出的物体进行缓存池的装入操作。
由此可以面对不同模块，构建不同的对象管理类，进行回收操作。
缓存池和对象管理类就像：垃圾站和环卫工，面对特效和子弹，都有不同的环卫工去定期收集并放入垃圾站。

对象池也可以模块定制化,声明特效模块的对象池和子弹模块的对象池,只负责自己模块的回收与缓存.
这种方式一看就会声明很多类,不利于管理,但是在面对未知时,对象池面向模块高度定制化往往比设计通用的对象池省时和灵活(都是甲方逼得)

空接口

基本思路就是实现一个事件中心，代替其他类的互相监听。好处是统一了监听对象，降低了其他模块的耦合，坏处就是所有的类都要调用事件中心，不同的事件需要声明不同的事件，模块多了之后不利于管理。
关于事件过多，可以声明事件类，用来包装事件，再用字典统一管理，结构方面的混乱就迎刃而解了。

里氏替换原则的经典应用，用父类装子类，好处是可以将多个不同的类使用统一的父类包装，并且避免了传统object包装后的拆装箱问题。
此处还有一个泛型问题被一并解决：如果在字典中直接申明泛型的事件类，事件中心会需要变成泛型类，出现泛型方面的问题。泛型事件类根据每次不同的实例化确定泛型T的类型，而事件中心作为单例只会实例化一次，彼此冲突。当泛型事件类装入父类，再记录给事件中心时，事件中心就不需要变成泛型类，因为它的成员没有泛型了。

里氏替换在自己写过的对象池有应用过，表格模块的表类有多种，对象池为了每一种表格声明一个对象池类不现实。对象池的list选择记录表格的父类，返回到对象池管理器时，再转成对应的子类。
曾经写过的监听者模式，是一个事件中心根据需要声明不同的Action，没有对事件进行管理

向外提供MonoBehavior脚本的方法，比如生命周期周期函数，或者开启协程。
由此可以节省不必要的脚本声明，在热更新项目中也会担任很重要的角色，热更的逻辑可能无法写在Mono脚本中，需要根据Mono生命周期执行时，可以通过将事件交给MonoMgr来执行。

Initialization => Editor => Initialiazation => Physics => Input events => Game logic => Scene rendering => Gizmo rendering => GUI rendering => End of frame => Pausing => Decommissioning

自上表格可以看出，协程的生命周期方法是要迟于本体方法的。

异步操作协同程序

Resources包的异步加载请求，继承自AsyncOperation

目前大部分异步操作都是使用协程，并不是协程真的万能，而是Unity对于线程支持度较低。后续尝试多了解线程池等相关知识，考虑使用线程替代部分协程的工作。线程无法替代主线程的Unity操作，但是可以帮助处理网络或者寻路等复杂计算。

协程的逻辑执行只是被yield分帧在主线程里执行，好处是不用担心线程安全问题，坏处就是压力依然集中在主线程。 线程是独立于主线程的，在允许操作Unity资源的前提下，加载和操作资源是不会影响到主线程的，减少了主线程的压力，但也带来了线程安全问题。

简言之，多个线程访问同一个目标，出现的冲突就是线程安全问题。
如：
同时访问主角的100血量属性，一个要加10一个要扣10，结果一定不是100，只会是90或者110。
两个线程访问同一个没有实例化的单例类，此时就会实例化两个该类，因为都触发了类的实例化，哦吼，单例变双例。（bytheway：饿汉模式因为提前实例化，恰好避免了该问题）

新旧版输入系统
旧版输入控制是声明在哪就在哪修改。
新版集中化处理，在配置文件中声明并且兼容了多平台的输入，封装了自己的事件中心，并且事件内容也更加详细。

鉴于游戏公司多数使用旧版Unity，使用的都是旧版输入系统，暂不深入了解InputSystem

仅适用于没有距离要求的音效场景

老生常谈的经典原则，父类装子类，常常伴随泛型一起使用。此处是为了满足同时接受所有的UI控件类，使用共同的父类UIBehaviour接收，使用时再as成指定的类。

平时的UI控件都是Public或者SerializeField序列化到Inspector面板上手动拖拽，此处唐老师采用了全部Find，按照对象名称分别记录到字典。
访问时通过字典里的对象名与对应控件类可以找到，声明特殊事件委托的情况也可以通过提前编写带名称的委托封装方法实现。（ps：当前只写了Btn和Tog两种，其他Slider等用到的时候再加）

算是常识，UI正常情况下是按照Hierarchy的上下顺序来渲染的（World模式的UI是按照距离渲染）。如：A、B图片，A在上B在下，因为渲染顺序是自上向下，先渲染A再渲染B，所以在屏幕上就像先画了A再画了B，B就会掩盖在A上。
此处唐老师借此衍生出了UI的四个层级对象，底层，中层，顶层，系统层。
使用场景：打开背包界面，一个黑色的背景属于底层，背包栏和装备栏属于中层，被拖拽的装备临时属于顶层这样就不会被背包或者装备栏遮挡，而装备拖拽失败时弹出的警告必然属于系统层，渲染在所有层级之上。

Unity文档原话：

接收来自 EventSystem 的事件，并为每个事件调用已注册的函数。
EventTrigger 可用来指定您想为每个 EventSystem 事件调用的函数。 您可以将多个函数分配给单个事件，每当 EventTrigger 收到该事件时，都会按照这些函数的提供顺序调用它们。 注意：将此组件附加到游戏对象将导致该对象拦截所有事件，并且所有事件都不会传播到父对象。
您可以通过两种方式拦截事件：
一是扩展 EventTrigger，并覆盖您想拦截的事件的函数
二是指定单个委托

经测试，加入EventTrigger的Click并不会影响原本Btn的Click触发。

此处唐老师使用EventTrigger是为了额外拓展一些触发，比如图片也需要监听鼠标点击，与此类似的操作是在图片上挂载一个脚本并继承IPointerClickHandler接口。相较之下加入EventTrigger确实会更方便。（ps：以前真的是直接挂载脚本专门负责监听，真的太浪费了）

既然提到接口，就继续说说，IPointerClickHandler类似的接口，与EventTrigger都属于UnityEngine.EventSystems命名空间，EventTrigger就是Unity为我们提供的集事件大成者，与我刚才提到的挂在脚本做监听类似，不过是封装好的。

挖个坑EventSystems也可以写一篇笔记，结构参照Unity文档的结构