This problem usually occurs when the project is relatively large, OO is well used, and generic inheritance is used more often. During the first real machine test, the project finally entered the real machine test stage. It was developed and tested in the unity editing environment before. It ran well and packed and installed with full confidence. The results flashed back… , all kinds of code debugging and tracking have no clue. What about this? The problem is probably the AOT settings.
This is usually because the space allocated to trampoline when your program compiles is too small, and your program uses generics, generic method calls and interface implementations in large quantities. The specific solution is to have an AOT compilation options entry in player setting, the compilation option of unity3d. Add the following compilation parameters to this option entry
After that, repack the test to see if there is any problem
The meanings of the above three parameters are as follows:
Nrgctx trackolines = 8192, which is the space for recursive generics. The default value is 1024
Nimt trackolines = 8192, which is the space reserved for the interface. The default value is 128
Ntrampolines = 4096, which is the space for generic method calls. The default is 1024
What is trampoline
Trampoline is a very short handwritten component code used to perform many operations in the mono runtime. It is mainly generated dynamically at runtime by the local code macro used by JIT. They usually have corresponding C methods. In some more complex scenarios, when tramoline is not competent, the mono runtime will return these complex operations to these corresponding C methods for execution. This can also be seen as a way to give execution of JIT code back to runtime.
It seems obvious that this is to improve the efficiency of mono runtime when executing C code, but it is still a bit unclear.
Take a look at the official documents about JIT trampolines and AOT trampolines:
JIT Trampolines These trampolines are mainly used by JIT to compile methods when a method is called for the first time. When JIT compiles a method call instruction, it does not immediately compile the called method. In fact, it will first create a JIT trampoline and a call instruction to that trampoline. When the JIT trampoline is called to, it will call mono again_ magic_ The trampoline () method compiles the target method that the trampoline actually points to, and then returns the pointer address of the compiled method to the trampoline that points to it. This process is a little bit slow, so, mono_ magic_ The trampoline() method optimizes the process of calling JIT code, which attempts to call a JIT compiled method first rather than directly through trampoline immediately. These are all through mono in the trap -. C file_ patch_ The callsiete () method.
AOT trampolines is very similar to JIT trampolines, but the compilation parameters accepted by AOT trampolines are not a mono method but an image + token pair. If the method pointed to by the image + token pair passed in for compilation has been AOT compiled, when compiling the image + token pair again, the pointer address of the compiled method will be returned directly without loading the metadata of the method again for re compilation.
IMT trampolines are also used to optimize the efficiency of interface calls.
The value of trampolines is to reduce the performance loss of C code when running in mono runtime and improve the execution efficiency of C code.
You can try the above method when you encounter similar problems.
The above solution to IOS flash back in unity3d lab is all the content shared by Xiaobian. I hope it can give you a reference, and I hope you can support developepaer more.