Unity关于方法事件生命周期官方文档

- 日理万妓 2022-01-06 05:07 509阅读 0赞

![1463614-20190113014451723-463562417.jpg][]

[http://docs.unity3d.com/Manual/ExecutionOrder.html][http_docs.unity3d.com_Manual_ExecutionOrder.html]

**一.组件运行的基本顺序**

下图中创建类的顺序为A,B,C,A1,二运行的结果为A1,B,C,A。

可以得到如果不设置类的运行权值，那么类之间运行顺序为倒叙。所有类的运行事件呈现同步状态，先全部运行玩Awake,后面是Start,Update

![1463614-20190416035752286-2136191970.png][]

**二.生成的物体的生命周期**

在物体A的start中生成B物体，结果如下，可以看到当物体生成时，Awake会立即执行，Start不会立即执行，而是遵循物体的顺序与其他物体同步执行

![1463614-20190416214635589-922483668.png][]

unity理论其他如下

![1463614-20190416215135091-1266266372.png][]

![1463614-20190416215740920-1996545779.png][]

（借用图，如果看到此图的原作者有异议请跟我联系，我会及时进行处理，不过我认为你是个大度的人，不会在意这点）

最先执行的方法是Awake，这是生命周期的开始，用于进行激活时的初始化代码，一般可以在这个地方将当前脚本禁用:this.enable=false，如果这样做了，则会直接跳转到OnDisable方法执行一次，然后其它的任何方法，都将不再被执行。

如果当前脚本处于可用状态，则正常的执行顺序是继续向下执行OnEnable，当然我们可以在另外一个脚本中实现这个脚本组件的启动：this.enab=true;

再向下执行，会进行一个判断，如果Start方法还没有被执行，则会被执行一次，如果已经被执行了，则不会再被执行。这是个什么意思呢？我们可以在某个脚本中将组件禁用this.enable=false，再启用时会转到OnEnable处执行，这时继续向下走，发现Start执行过了，将不再被执行。比如说：第一次启用时，将怪物的初始位置定在了(0,0,0)点，然后怪物可能会发生了位置的变换，后来被禁用了，再次启用时，不会让怪物又回到初始的(0,0,0)位置。

继续向后执行，就是Update了，然后是FixUpdate，再然后是LateUpdate，如果后面写了Reset，则会又回到Update，在这4个事件间可以进行循环流动。

再向后执行，就进入了渲染模块（Rendering），非常重要的一个方法就是OnGUI，用于绘制图形界面。当然，如果你使用了NGUI，这个生命周期的事情你就不用考虑了。

再向后，就是卸载模块（TearDown），这里主要有两个方法OnDisable与OnDestroy。当被禁用(enable=false)时，会执行OnDisable方法，但是这个时候，脚本并不会被销毁，在这个状态下，可以重新回到OnEnable状态（enable=true）。当手动销毁或附属的游戏对象被销毁时，OnDestroy才会被执行，当前脚本的生命周期结束。

详情：

**1、静态构造函数**

当程序集被加载的时候就被调用了，如果你的unity处于编辑状态时，此时你保存一个脚本（从而迫使重新编译），静态构造函数会立即被调用，因为unity加载了DLL。并且它将不会再次运行，永远只会执行一次，unity运行时，是不会再次执行了！在一个已部署的游戏上，这个构造器将会在unity加载过程的早期被调用！

静态构造函数文章：[http://www.cnblogs.com/MrZivChu/p/BaseKnowledge\_staticConstructor.html][http_www.cnblogs.com_MrZivChu_p_BaseKnowledge_staticConstructor.html]

**2、非静态构造器**

Unity将会在一个貌似随机的时间调用一个对象的默认构造器。当你编辑一个游戏时，在你保存一个脚本（从而迫使重新编译）后，这构造器将会被立马调用！

程序运行时被随机调用多次，程序结束时也被调用了（自己测试发现）

所以不要使用构造器去初始化字段的值，unity的Awake就是专门为这个目的设计的。

**3、Awake**

只会被调用一次，在Start方法之前被调用！ 主要用于字段值的初始化工作，禁用脚本，创建游戏对象，或者Resources.Load(Prefab) 对象

**4、Start**

只执行一次，在Awake方法执行结束后执行，但在Update方法执行前执行， 主要用于程序UI的初始化操作，比如获取游戏对象或者组件

**5、Update**

每一帧执行的，监听用户输入，播放动画，当机器忙或者性能差的时候，他会停止执行，会产生停顿的感觉，例如一个人本来在1米的位置，突然到了5米的位置上，产生了跳帧，而下面的FixedUpdate方法则相反！会一米一米的去执行！（自己调试发现，Update是先于OnGUI执行的，且执行一次Update之后，会执行两次OnGUI）

**6、FixedUpdate**

不管当前机器忙不忙，都会保证每一帧执行一次！避免跳帧！固定更新。固定更新常用于移动模型等操作。

**7、LateUpdate**

先执行Update，然后才去执行lateUpdate(Update方法执行完，必定接着执行LateUpdate，而Update和FixedUpdate方法的执行顺序不确定，而且有时候FIxedUpdate执行了多帧，而Update却只执行了一帧，这就是因为跳帧的缘故造成的（取决于你的机器性能）！)，如果现在有100个脚本，分别有100个 Update()函数，其中只有一个LateUpdate，那么在同一帧中，等待100个Update()执行完后，才执行这一个LateUpdate()。

**8、OnGUI**

在这里面进行GUI的绘制，且GUI是每帧擦除重绘的！仅仅只是绘制！没有生命周期的概念！所有关于绘制GUI的代码，都要直接或者间接地写到OnGUI方法中！

**9、OnDestroy**

当前脚本销毁时调用

**10、OnEnable**

脚本可用时被调用、如果脚本是不可用的，将不会被调用！

如果有三个对象，a1 > a2 > a3 （父子级的关系），挂有三个脚本s1，s2，s3，三个脚本都有Awake，Start，OnEnable，OnDisable，Update方法，那么unity执行的顺序为：

awake1，OnEnable1，awake2，OnEnable2，awake3，OnEnable3，Start1，Start2，Start3，Update1，Update2，Update3

如果在脚本s2的Awake方法中设置脚本s1不可用（s1.enabled=false），那么脚本的执行结果为：

awake1，OnEnable1，OnDisable1，awake2，OnEnable2，awake3，OnEnable3，Start2，Start3，Update2，Update3

如果在脚本s2的Awake方法中设置脚本s3不可用（s3.enabled=false），那么脚本的执行结果为：

awake1，OnEnable1，awake2，OnEnable2，awake3，Start1，Start2，Update1，Update2

如果在脚本s2的Start方法中设置脚本s3不可用（s3.enabled=false），那么脚本的执行结果为：

awake1，OnEnable1，awake2，OnEnable2，awake3，OnEnable3，Start1，OnDisable3，Start2，Update1，Update2

**总结：****关键是看设置脚本不可用的位置：**

**A****（1）**如果在父级的Awake方法里面设置子级的脚本不可用

那么仅仅只会执行子级里面的Awake方法，当子级被激活后（enabled=true），会先执行OnEnable，然后执行Start方法，Update等帧序列方法都会开始执行

**（2）**如果在父级的Start方法里面设置子级的脚本不可用

那么会执行子集里面的Awake，OnEnable和OnDisable方法，当子级被激活后（enabled=true），会先执行OnEnable，然后执行Start方法，Update等帧序列方法也都会开始执行

**B****（1）**如果在子级的Awake方法里面设置父级的脚本不可用

那么会执行父级里面的Awake，OnEnable和OnDisable方法，当父级被激活后（enabled=true），会先执行OnEnable，然后执行Start方法，Update等帧序列方法都会开始执行

**（2）**如果在子级的Start方法里面设置父级的脚本不可用

那么会执行父集里面的Awake，OnEnable，Start和OnDisable方法，当父级被激活后（enabled=true），会先执行OnEnable，Update等帧序列方法也都会开始执行

**如果被激活的脚本之前没有调用Start方法，那么当此脚本被激活后，会调用一次Start方法！具体，看生命周期第一幅图，在文章后面！**

**11、OnDisable**

如果脚本被设置为不可用将会被执行，程序结束时也会执行一次！

**OnEnable 和 OnDisable 只受脚本的可用状态的影响（enabled）**

**而OnBecameVisible 和 OnBecameInvisible 是受对象是否可见的影响（如下）！即使脚本设置为不可用，OnBecameVisible和OnBecameInvisible 也会被执行，主要是看对象是否在场景中显示了！**

**OnBecameVisible 和 OnBecameInvisible ：**

**（1）当一开始加载一个对象时：**

Game 显示 Scene 显示 OnBecameInvisible 不执行 OnBecameVisible 执行

Game 不显示 Scene 不显示 OnBecameInvisible 不执行 OnBecameVisible 不执行

Game 不显示 Scene 显示 OnBecameInvisible 不执行 OnBecameVisible 执行

Game 显示 Scene 不显示 OnBecameInvisible 不执行 OnBecameVisible 执行

小结：只要Game和Scene中有一个显示了，OnBecameVisible 就会执行！而OnBecameInvisible 一直都不会执行

**（2）当移动对象时：**

game 和 scene 对象必须在两个场景中同时消失 OnBecameInVisible 才执行

scene 和 game 只要有一方进入了场景 OnBecameVisible 就执行了

**脚本执行顺序总结：**

假如现在有三个GameObject对象：a1 > a2 > a3 (a1为a2的父节点，a2为a1的父节点，unity执行脚本的顺序是从上往下执行，也就是说先执行父节点上的脚本，再去执行子节点的脚本，子节点上如果有多个脚本，那么也是自上而下的顺序执行)，这三个对象对应各有一个脚本：s1，s2，s3，且这三个脚本代码都一样，都有Awake，Start，Update，LateUpdate，FixUpdate，那么当运行程序时，程序会进行分组，即把s1，s2，s3中的Awake方法组成一组，把Start方法组成一组，把Update方法组成一组，把LateUpdate方法组成一组，把FixUpdate方法组成一组，最后按照Awake，Start，FixUpdate，Update，LateUpdate（FixUpdate和Update顺序不确定）的顺序依次执行！即把Awake组里面的Awake方法全执行完，再去依次执行Start，FixUpdate，Update，LateUpdate组里面的代码：执行顺序如下：

Awak1 Awak2 Awak3 Start1 Start2 Start3 FixUpdate1 FixUpdate2 FixUpdate3 Update1 Update2 Update3 LateUpdate1 LateUpdate2 LateUpdate3

转载于:https://www.cnblogs.com/xiaoahui/p/10261766.html

[1463614-20190113014451723-463562417.jpg]: /images/20211228/86bd1d2893924c759f94dff146ddb411.png
[http_docs.unity3d.com_Manual_ExecutionOrder.html]: http://docs.unity3d.com/Manual/ExecutionOrder.html
[1463614-20190416035752286-2136191970.png]: /images/20211228/3c9ee07a43da44b7be3629b9a3f33f59.png
[1463614-20190416214635589-922483668.png]: /images/20211228/7d416e335bd34bf09cbf328cc01eb616.png
[1463614-20190416215135091-1266266372.png]: /images/20211228/2202d5425ab94fe6adfea10d032afad3.png
[1463614-20190416215740920-1996545779.png]: /images/20211228/9a6186d0261848b1977af60fc5e189e4.png
[http_www.cnblogs.com_MrZivChu_p_BaseKnowledge_staticConstructor.html]: http://www.cnblogs.com/MrZivChu/p/BaseKnowledge_staticConstructor.html