In unity3d, coroutine is used to implement the "Update multiple times" feature.

Some tasks only need to be done once within one frame. For example, when sending and receiving emails, the data layer in one frame changes multiple times, and the presentation layer only needs to be updated once.
I used coroutine To Do This. To avoid initiating multiple coroutine, I recorded whether a coroutine was initiated.
However, the coroutine in U3D will not be updated after the initiated script acvited = false, and I have tested it and then restored it to actived = true. The coroutine will not be updated, just like not calling.

The following is U3D's explanation of coroutine calling mechanism:

"In unity3d, you can use the monobehaviour. startcoroutine method to start a collaboration program. That is to say, this method must be called in monobehaviour or a class inherited from monobehaviour.

In unity3d, you can use startcoroutine (string methodname) and startcoroutine (ienumerator routine) to open a thread. The difference is that you can use a string as a parameter to enable the thread and terminate the thread before the end of the thread. On the contrary, you can use ienumerator as a parameter to only wait for the end of the thread and cannot terminate it at any time (unless you use the stopallcoroutines ); in addition, when the string is used as a parameter, only one parameter can be passed when the thread is enabled, and the performance consumption will be greater, and ienumerator is used.
As a parameter, there is no such restriction.

In unity3d, stopcoroutine (string methodname) is used to terminate a collaboration program, and stopallcoroutines () is used to terminate all the collaboration programs that can be terminated, however, both methods can only terminate the collaboration program in the monobehaviour.

There is another way to terminate the collaboration program, that is, to set the active attribute of the gameobject where the collaboration program is located to false. When the active attribute is set to true again, the collaboration program will not be enabled again; if the enabled of the script in which the coprocessor is located is set to false, it does not take effect. This is because the coprocessor is running as a thread after it is enabled, while monobehaviour is also a thread. They become modules that do not interfere with each other. Unless called in the code, they act on the same object together, only when the object is invisible can the two threads be terminated at the same time. However, in order to manage our extra enabled threads, unity3d places the call of the coprocessor in monobehaviour, so that we can conveniently call the coprocessor in the specified script during programming, rather than being unable to manage it, especially for methods that only determine the thread based on the method name are prone to errors in multi-person development. This design ensures the rational management of objects and scripts and prevents duplicate names."

My flags are still in the "initiated" status, so a deadlock occurs-the update cannot be initiated, and the flag cannot be reset due to the exception.

The above phenomenon occurs when the user clicks the mouse in the frame after receiving the email and closes the email system.
Because network message dispatching is prior to user input (the existing structure in our project), the coroutine is initiated but cannot be executed.
If you close the service first and then process the data, the process will be performed when it is closed, so there will be no errors-however, network messages may also cause the UI to be closed, depending on the business logic.

Return to the status quo,
I can only restore the flag when hiding it.
However, the U3D hidden objects are too casual. Most of them use the gameobject. setactiverecursively (bool) interface to work.
This makes it impossible for me to ensure that all the code that processes this object knows the recovery flag.
I can refine a special visible interface to ensure that the flag is restored, but there are the following situations:
If the logic is distributed to multiple script components, it is very troublesome to access this special visible interface.
In this case, I 'd better use update.

The current solution is:
In one scenario, there is exactly one script, which can satisfy the requirement of "extracting a special visible interface and ensuring that the flag is restored ".
In another scenario, there are a lot of scripts, and the coroutine only performs visibility control, which leads to errors and is not afraid because it will be restored by other visibility operations.

 

Who can provide an update solution based on coroutine that will not cause deadlock issues?

The coroutine is also used for updating the friend list today. In addition, the closing logic is exactly in other scripts. The current plan is to let the closing button capture user input, forward it to the model layer, and then notify each script component to perform recovery operations separately.

I hope that the efficiency will be higher than the update efficiency. Anyway, I think this is not the core performance bottleneck.

 

Positive Solution of zpbaaa method ~~ Thank you.

It can be restored when ondisable is enabled.