unity fixedupdate_Unity中Start的调用时机

主要是因为被坑到了，所以记录下。

使用Unity的MonoBehaviour写游戏逻辑，会经常用到被称之为“Message”的Magic Method。比如在Start中初始化，在Update里处理输入的响应等等。为此，了解这些方法的执行顺序就非常重要，在Unity的手册里，提供了一个脚本生命周期内的方法执行循序图，如下：

重点关注几个常用的方法调用顺序，应该是Awake->Start->Update->LateUpdate。

再看下手册里关于Start调用时机的描述：

Start会在第一次帧更新前调用，对于放在scene中的对象，start会在所有脚本的Update调用前触发，但对于运行时实例化的对象则没有这个要求。

这次被坑到的就是后半段话了，如果对象在Update中被创建，并且上面挂有一个enabled的脚本，那齐Start方法是什么时候触发的呢？写个简单的测试。

首先是挂在prefab上的脚本

using 

接着是用于实例化的脚本

using 

输出如下

从日志可以看到，Awake方法在Instantiate返回前就触发了，而Start则是在打印了“after create Update”这之后，再之后是LateUpdate，而Update方法则是下一帧触发。也就是说被实例化的prefab上的Update没有被触发，但是依然执行了LateUpdate，所以Start方法如手册中说的，再LateUpdate调用前触发了。

我们可以再详细一点，看下Start更具体的触发时机：

using 

结果如下

可以看到Start在yield null之前调用了

为什么要测试这个，关键是点在于下方的Internal Animation Update。这是当Animator的UpdateMode不是AnimationPhysics时的调用位置。也就是说，如果Spawner上有Animator，那么这是被实例化的prefab的Start时机是早于Spawner上Animator的更新时机的。

最后说下被坑的情景：Spawner上有个Animator，同时被实例化的prefab上也有个动画挂着。而prefab上有个脚本，会在start的时候去获取spawner上动画的时间，达到同步两者时间的效果（虽然这样写很糟糕）。问题在于，prefab是在Spawner的Update中创建的，当获取Spawner动画时间时，Spawner的动画状态还未更新，等于获取的还是上一帧的数据，最终导致两者之间会有一帧时间的差距。