April 23, 2018

Categories: Unity3D

Tags: Unity3D

继承自Monobehaviour的组件组件的构造函数

Table of Contents

请尊重原作者的工作，转载时请务必注明转载自：www.xionggf.com

问题1：

在unity中，继承自MonoBehaviour的组件类可以写构造函数吗？构造函数应该是public，protected，还是private的，构造函数的执行顺序比Awake和Start事件方法更早吗？

你想了解在Unity中，继承自MonoBehaviour的组件类里构造函数的使用规则、访问修饰符选择，以及它和Awake/Start的执行顺序关系，这个问题触及了Unity组件生命周期的核心知识点。

一、核心结论与详细解释

1. 可以写构造函数，但强烈不推荐

从语法上讲，你完全可以为MonoBehaviour子类编写构造函数，但Unity的组件系统设计逻辑决定了这是一种错误的实践。

原因：

Unity组件的实例化不是由new关键字创建的，而是由Unity引擎在场景加载、对象实例化（如Instantiate()）时自动创建的。
如果你手动写构造函数，Unity引擎并不会调用它（除非你自己用new创建，但这会导致组件脱离Unity的GameObject体系，失去所有MonoBehaviour的特性）。
构造函数中如果访问Unity的核心API（如transform、gameObject），会直接报错，因为此时组件还未被引擎初始化，这些引用都是null。

2. 构造函数的访问修饰符

即使你非要写构造函数，访问修饰符的选择也没有实际意义：

public：语法合法，但无意义，因为你不会手动new一个MonoBehaviour组件。
protected/private：同样合法，但Unity引擎也不会调用，仅能被类内部/子类的代码调用（而这种调用本身就不符合Unity的使用规范）。

总结： 无论选择哪种修饰符，对Unity组件的正常使用都没有帮助，反而可能造成误解。

3. 执行顺序对比

构造函数的执行顺序确实比Awake和Start更早，但这个“更早”没有实际价值：

执行时机：
1. 构造函数：当Unity引擎在内存中创建组件对象的“裸实例”时执行（场景加载/Instantiate的最早期）。
2. Awake：组件对象被引擎初始化（绑定到GameObject、初始化transform等引用）后立即执行（游戏开始/对象创建时）。
3. Start：在Awake之后，该组件第一次更新（Update）前执行。
关键问题：构造函数执行时，组件的gameObject、transform等核心属性都是null，无法进行任何有效的Unity相关操作，此时执行的代码几乎没有实际意义。

二、正确的替代方案

如果你想在组件初始化时执行代码，应该使用Unity提供的生命周期方法，而不是构造函数：

using UnityEngine;

public class MyComponent : MonoBehaviour
{
    // 错误示范：不要写构造函数
    // public MyComponent()
    // {
    //     // 这里访问transform会报错！
    //     // transform.position = Vector3.zero;
    // }

    // 正确：初始化逻辑写在Awake（最早的有效时机）
    private void Awake()
    {
        // 此时所有Unity引用都已初始化，可以安全操作
        transform.position = Vector3.zero;
        Debug.Log("Awake执行：组件初始化");
    }

    // 可选：延迟初始化写在Start（在Awake之后）
    private void Start()
    {
        Debug.Log("Start执行：延迟初始化");
    }
}

总结

不推荐写构造函数：MonoBehaviour组件由Unity引擎管理实例化，手动写构造函数无实际作用，还可能引发空引用错误。
访问修饰符无意义：无论public/protected/private，Unity都不会调用自定义构造函数，仅语法合法而已。
执行顺序：构造函数确实比Awake/Start更早，但此时组件未完成Unity初始化，无法访问transform/gameObject等核心属性，无实用价值；初始化逻辑应优先写在Awake中。

核心原则：遵循Unity的生命周期规范，所有组件初始化逻辑都放在Awake/Start中，而非构造函数。

问题2：

在一个prefab中，某个game object处于disable状态，在装载此prefab进来之后，在激活此game object之前，挂接在game object上的某个component的Awake方法是否执行

核心结论与详细解释

结论：会执行。

Unity中MonoBehaviour的Awake方法执行与否，不取决于GameObject是否激活（activeSelf/activeInHierarchy），而是取决于：

该GameObject是否被加载到场景中（实例化完成）；
组件本身是否启用（enabled = true）。

也就是说，只要满足“GameObject已加载 + 组件启用”，即使GameObject是禁用状态，Awake方法依然会在对象加载时执行，且仅执行一次。

关键细节补充：

Awake的执行时机：在GameObject被实例化（加载到场景）的瞬间，无论其激活状态如何，只要组件启用，Awake就会执行；
Start的执行时机：只有当GameObject被激活（且组件启用）后，Start才会在第一次Update前执行；
组件禁用的情况：如果组件自身的enabled设为false，那么Awake也不会执行（仅组件启用时Awake才会触发）。

代码验证示例

下面的代码可以直观验证这个逻辑，你可以将组件挂载到预制体中禁用的GameObject上：

using UnityEngine;

public class TestAwake : MonoBehaviour
{
    // 组件默认启用（enabled = true）
    private void Awake()
    {
        // 即使GameObject禁用，Awake依然执行
        Debug.Log($"Awake执行 | GameObject激活状态：{gameObject.activeSelf}");
    }

    private void Start()
    {
        // 只有GameObject激活后，Start才会执行
        Debug.Log($"Start执行 | GameObject激活状态：{gameObject.activeSelf}");
    }

    // 激活GameObject时触发
    private void OnEnable()
    {
        Debug.Log("OnEnable执行：GameObject/组件被激活");
    }
}

测试步骤与预期结果：

创建一个预制体，其中包含一个禁用的GameObject，挂载上述TestAwake组件（组件启用）；
在场景中实例化该预制体：
- 控制台立即输出：Awake执行 | GameObject激活状态：False（验证Awake执行）；
- 此时Start不会执行，因为GameObject禁用；
手动激活该GameObject：
- 控制台输出：OnEnable执行：GameObject/组件被激活；
- 随后输出：Start执行 | GameObject激活状态：True（Start延迟到激活后执行）。

特殊情况：组件自身禁用

如果将TestAwake组件的enabled设为false（在Inspector中取消勾选），那么：

GameObject加载后，Awake不会执行；
当你先启用组件、再激活GameObject时，Awake会立即执行，随后触发OnEnable和Start。

总结

核心规则：GameObject禁用不影响其挂载组件的Awake执行（只要组件启用），Awake在对象加载时仅执行一次；
Start的区别：Start必须等待GameObject激活后才会执行；
组件禁用的影响：组件自身禁用时，Awake/Start/OnEnable都不会执行，直到组件被启用。

记住这个关键区别：Awake是“对象加载初始化”，与激活状态无关；Start/OnEnable是“对象激活后逻辑”，依赖激活状态。