Unity 面试个人笔记

ScriptableObject:

ScriptableObject 是 Unity 提供的一个数据配置存储基类，它是一个可以用来保存大量数据的数据容器，我们可以将它保存为自定义的数据资源文件。

ScriptableObject 是一个类似 MonoBehaviour 的基类，继承自 UnityEngine.Object 。要想使用它，需要我们写个脚本去继承 ScriptableObject 。需要注意的是，继承自 SctiptableObject 的脚本无法挂载到游戏物体上，毕竟它不是继承自 MonoBehaviour。

ScriptableObject 类的实例会被保存成资源文件（.asset文件），和预制体，材质球，音频文件等类似，都是一种资源文件，存放在 Assets 文件夹下，创建出来的实例也是唯一存在的。

ScriptableObject 的主要作用

大体上可以分成三点：
1） 编辑模式下的数据持久化
2） 配置文件 （配置游戏中的数据）
3） 数据复用 （多个对象共用一套数据）

如何生成非持久化数据？
利用 ScriptableObject 类中的静态方法 CreateInstance<>() 。该方法可以在运行时创建出指定继承自 ScriptableObject 的对象，该对象只存在于内存中，可以被GC垃圾回收，调用一次就创建一次。

Ⅳ. 让 ScriptableObject 真正意义上持久化

既然 ScriptableObject 本身无法在游戏打包发布后实现数据持久化，那么我们可以配合 Json，PlayerPrefs， xml ，二进制等方式来实现 ScriptableObject 真正意义上的数据持久化。

📕 Ⅱ. 生命周期函数

ScriptableObject 和 MonoBehaviour 类似，也存在生命周期函数，但是数量会少很多。

Awake 数据文件创建时调用

OnDestroy 对象将被销毁时调用

OnEnable 创建或加载对象时调用

OnDisable 对象销毁时，即将加载脚本程序集时调用

OnValidate 编辑器才会调用的函数，Unity在加载脚本或者Inspector面板中更改值时调用

除此之外继承自 ScriptableObject 的类中也可以自定义函数，并不是只能声明和数据有关的变量。

寻路算法

对于一些动态场景，比如运行时会动态生成障碍物或者障碍物可以移动的场景可以使用D-Star（D*）算法。对于静态场景，也就是场景固定的情况可以使用Dijkstra算法，A-Star（A*）算法。

对于上述这些算法如今都有一些比较完善的插件，我们只需要左点右点就可以实现寻路的功能，此外Unity也提供了NavMeshComponents用于寻路。本篇主要就是简单的介绍下A*算法的概念以及代码逻辑，只有了解了最基础的寻路算法，才能更好的理解更牛逼的寻路算法嘛，例如Jump Point Search。

* 初始化open_set和close_set；
* 将起点加入open_set中，并设置优先级为0（优先级最高）；
* 如果open_set不为空，则从open_set中选取优先级最高的节点n：
    * 如果节点n为终点，则：
        * 从终点开始逐步追踪parent节点，一直达到起点；
        * 返回找到的结果路径，算法结束；
    * 如果节点n不是终点，则：
        * 将节点n从open_set中删除，并加入close_set中；
        * 遍历节点n所有的邻近节点：
            * 如果邻近节点m在close_set中，则：
                * 跳过，选取下一个邻近节点
            * 如果邻近节点m在open_set中，则：
                * 判断节点n到节点m的 F(n) + cost[n,m] 值是否 < 节点m的 F(m) 。来尝试更新该点，重新设置f值和父节点等数据
            * 如果邻近节点m也不在open_set中，则：
                * 设置节点m的parent为节点n
                * 计算节点m的优先级
                * 将节点m加入open_set中

Unity 常用设计模式

工厂模式:

工厂模式（Factory Pattern）是 游戏开发中最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。在工厂模式中，我们在创建对象时不会对用户暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。

某个品牌的汽车制造工厂，对外提供生产这个品牌的不同型号汽车的服务。外界只要下一个”汽车型号”, 工厂可以根据型号构建出来不同型号的汽车。这样外界不用关心工厂内部是怎么运作的，当用户需要某个型号的汽车的时候调用接口就可以了，同时内部工厂的机制，可以任意的修改,比如增加了一个新的汽车型号的服务等。

单例模式：

在我们的整个游戏生命周期当中，有很多对象从始至终有且只有一个。这个唯一的实例只需要生成一次，并且直到游戏结束才需要销毁。
单例模式一般应用于管理器类，或者是一些需要持久化存在的对象。

优点：写起来很方便，调用方便。
缺点：容易形成依赖，忽略与其他设计模式的协作。

某个类只能有一个实例&#x