Question Build changes the order of Start() functions being called

Hello,

I have the following issue: I have a working project in Unity Editor. I hit play, everything goes well.
Then I build (for Android). The build is successful, but I observe that some stuff is not working. For instance, a menu with buttons is not showing in the app on my phone. If I try to hit play again in the Editor (without doing anything else at all than having done the build), I see that there also, it's not working properly anymore.

I dig a bit, and it seems that this is due to an event being invoked before a listener function is assigned to that event. So, of course, the listener function is never called, and the app is not working.
What's of course really intriguing to me is that before I do the build, it does work! I can hit play 20 times, it will work 20 times. It's only after the build that somehow to "code order" is altered..

To be more specific, the listener function is assigned in a Start() method. And the invoke of the event is also done in another Start() method, of another script.
So for some reason before the build, the Start() method of the listener assignment is called before the invoke, and after the build it is called after the invoke..

How could this be explained, and is there anything I could do to prevent that?

Thanks a lot,
Arnaud

 

There's a reason why we have both Awake, Start and OnEnable. The order of two different Start calls (or any Unity callback) can't be guaranteed, so you need to use all three in some cases to ensure things are initialised in a certain order.

Personally I do all self initialisation in Awake, and any initialisation that requires other objects to be ready in Start.

 

Yes, I get that, but I'm really surprised that it looks like it's the action of building the project that somehow permanently changes the order in which the different Start() functions are called. It's not like it works every now and then. It always works before the build, and it never works again after the build..

 

It's not surprising in the slightest. This stuff is called from and managed by the black-box native side of the engine of which we can't see into. Anything number of things could change the order of things of which we know are indeterminate. I would say the building of a game is very likely to knock something into a different order.

So just subscribe the listener in Awake, and invoke it in Start. There's nothing else to care about here.

 

Ok! Thanks for the clarification!

 

the order was never deterministic, there are ways to force certain scripts to invoke Start earlier then others but i would not recommend using them. The idea is initialization that does not need external objects happens in Awake, then initialization that requires access to other objects or requires other Awake calls to be done happens in Start.