Problem arises
This problem generally occurs when the project is relatively large, OO is used well, and generic inheritance is used more often. During the first real machine test, the project finally entered the real machine test stage. Before, it was developed and tested in the Unity editing environment. It was run very well and packaged and installed with confidence, but it crashed. . . , there are no clues to debug various codes and tracking. What to do about this? The problem is most likely in the AOT settings.
Solution
This is usually caused by the fact that the space allocated to trampoline when your program is compiled, and your program uses a lot of generics, generic method calls and interface implementations. The specific solution is to have an AOT Compilation Options entry in the Unity3D compilation option Player Setting. Just add the following compilation parameters to this option entry.
nrgctx-trampolines=8192,nimt-trampolines=8192,ntrampolines=4096
In addition, repackage the test to see if there are any problems
Parameter meaning
The meanings of the above three parameters are as follows:
nrgctx-trampolines=8192 This is the space left for recursive generics, the default is 1024
nimt-trampolines=8192 This is the space left for the interface, the default is 128
ntrampolines=4096 This is the space left for generic method calls to use, the default is 1024
What is trampoline
Trampoline is a very short handwritten Component Code that is used to perform many operations in Mono Runtime. It is mainly generated dynamically at runtime through the local code macros used by JIT. They usually have corresponding C methods. In some more complex scenarios, when trampoline is not competent, the mono runtime will hand back these complex operations to these corresponding C methods for execution. This can also be seen as a way to return the execution rights of the JIT code to runtime.
This seems to be obviously to improve the efficiency of mono runtime when executing C# code, but it still doesn't understand.
Let’s take a look at the official documentation about JIT Trampolines and AOT Trampolines:
JIT Trampolines These Trampolines are mainly used by JIT to compile methods when they first call a certain method. When JIT compiles a method call instruction, it does not compile the called method immediately. In fact, it will first create a JIT Trampoline and create a call directive pointing to this trampoline. When this JIT Trampoline is called, it will call the mono_magic_trampoline() method to compile the target method actually pointed to by the trampoline, and then return the pointer address of the compiled method to the trampoline pointing to it. This process is a little slow, so the mono_magic_trampoline() method will optimize the process of calling JIT code. It will first try to call methods that have been compiled through JIT instead of directly calling them through trampoline immediately. These are done by the mono_patch_callsiete() method in the file.
AOT Trampolines
AOT Trampolines are very similar to JIT Trampolines, but the compile parameters accepted by AOT Trampolines are not a Mono method but an image+token pair. If the method pointed to by the image+token passed in for compilation has been AOT compiled, then when the image+token pair is compiled again, the pointer address of the compiled method will be directly returned without loading the metadata of the method again for compilation.
IMT Trampolines are also used to optimize interface call efficiency.
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.
Summarize
When encountering similar problems, you can try the above method.
The above article "Unity3D Lab" solution to the iOS real-move crash is all the content I share with you. I hope you can give you a reference and I hope you can support me more.