Understanding of the application of unity in the process of game development and technology

On the unity of the description of the process, online already a lot of. I will not do forwarding. In this article I mainly talk about my own understanding of the process.

We know that in a typical UI system, general control drawing needs to be in the UI thread. Includes actions on controls, changes to property values, and so on. Even though there are some UI frameworks that allow you to change property values in a non-UI thread, the framework actually handles message distribution, leaving the drawing messages for non-UI threads to the next frame to draw. (for example, a typical example is the Wpf/silverlight/mfc UI thread is not allowed to manipulate the UI control), which is necessarily a framework for the game engine.

So in our business logic, there has to be a calculation------------"rendering logic, the results of calculations, need to be shown in the next frame or several frames."

Unity provides us with a more user-friendly programming framework for logic to interface rendering, which allows you to take a coroutine, to do a logical operation without blocking the UI, and then allow you to initiate a callback when the UI needs to be refreshed.

So Startcoroutine's input parameter is "a function that returns a value of IEnumerator", and you can get the result in the next update or Ongui function in the unity frame when you return yield.

In fact, it is similar to the Dispatcher.begininvoke in Silverlight. is used to display the logic of the operation to the next frame. Only the framework for the process is more intuitive for programmers.