Reprint Address: http://www.gameres.com/339671.html
Unity Official Blog translation (after reading this blog is very excited, the first time to think of the translation is introduced to everyone, the article is to il2cpp internal developers of the angle to tell.
About a year ago, we wrote a blog about what the script in unity would look like in the future, and in that blog we talked about the new Il2cpp backend and promised that it would bring unity to a more efficient and better-suited virtual machine for each platform. In 2015 of January, we officially released the first platform to use Il2cpp: IOS 64-bit. And with the release of Unity 5, there is another platform to use Il2cpp: WebGL. Thanks to the vast amount of valuable feedback from users in our community, we have been able to update il2cpp and release patches in the following time to continually improve Il2cpp's compilers and runtime libraries.
We're not going to stop improving il2cpp, but at this point in time we feel we can go back and spare some time to tell you about some of the il2cpp's internal working mechanisms. Over the next few months, we're going to discuss the following topics (or other unlisted topics) to do a il2cpp in-depth tutorial series. The topics currently being discussed are:
1. Basics-Toolchain and command line parameters
2.il2cpp Generating Code Introduction
3.il2cpp Generating code debugging Tips
4. Method invocation Introduction (general method invocation and virtual method invocation, etc.)
5. Implementation of common code sharing
6.p/invoke (Platform invocation Service) Encapsulation of type (types) and method (methods)
7. Integration of the garbage collector
8. Test framework (testing frameworks) and its use
To make this series of discussions possible, we'll cover some of the il2cpp implementation details that will definitely change in the future. But it doesn't matter, and through these discussions, we hope to provide you with some useful and interesting information.
What is il2cpp.
Technically speaking, the il2cpp contains two parts:
A compiler for pre-compilation (Ahead-of-time, also known as AOT, using the AOT abbreviation below)
A run-time library that supports virtual machines
The AOT compiler will build the intermediate language (IL) code of the. NET output into C + + code. The runtime Library provides services and abstraction layers such as garbage collection, platform-independent threads, IO, and internal calls (C + + native code direct access to managed code structures).
AOT compiler
The actual execution file of the il2cpp AOT compiler is il2cpp.exe. On the Windows platform you can find it in the Editor\data\il2cpp directory of the Unity installation path. For the OSX platform, it is located in the Contents/frameworks/il2cpp/build directory of the Unity installation path. Il2cpp.exe This tool is a managed code executable that is written entirely in C #. In the process of developing il2cpp, we use it at the same time. NET and the mono compiler to compile it.
Il2cpp accepts managed assemblies from unity or generated by the mono compiler, converting these assemblies into C + + code. These converted C + + code is ultimately compiled by the C + + compiler on the deployment target platform.
You can understand the role of the Il2cpp tool chain in the following diagram:
Another part of the
Run-time library
Il2cpp is the run-time library that provides support for virtual machines. We basically use C + + code to implement the entire runtime library (well, in fact there are some platform-related code using the assembly, this as long as you know I know, do not tell others). We call the runtime library Libli2cpp, which is connected to the final game executable as a static library. One of the main benefits of doing so is that the entire il2cpp technology is simple and portable.
You can spy on how your code is organized by looking at the Libil2cpp header files that are published with Unity (Windows platform, header files in editor\data\playbackengines\webglsupport\ The Buildtools\libraries\libil2cpp\include directory. OSX platform, header files in the Contents/frameworks/il2cpp/libil2cpp directory). For example, the C + + code generated by Il2cpp and the interface API between Libil2cpp exist in the Codegen/il2cpp-codegen.h file. Another important part of the
Runtime is the garbage collector. In Unity 5, we use the LIBGC garbage collector. It is a typical Boehm garbage collector (Boehm-demers-weiser garbage collector). Relative use of the conservative garbage collection strategy. However, our libil2cpp are designed to facilitate the use of other garbage collector. So we are now also studying the integration of Microsoft Open Source garbage collector (Microsoft GC). For the garbage collector, we'll talk about it in a later article, not much here. How the
Il2cpp is performed.
Let's start with a simple example. The version of Unity used here is 5.0.1, in the Windows environment and creates a completely new empty project. Then create a script file with Monobehaviour and add it as a component to the main camera. The code is also very simple, output Hello World:
1 2 3 4 5 6 7 |
Using Unityengine;
public class Helloworld:monobehaviour { void Start () { Debug.Log ("Hello, il2cpp!"); } } |
When I switch to the WEBGL platform for project generation, we can use Process Explorer to observe the Il2cpp command line and get the following:
"C:\Program files\unity\editor\data\monobleedingedge\bin\mono.exe" "C:\Program files\unity\editor\data\il2cpp/ Il2cpp.exe "--copy-level=none--enable-generic-sharing--enable-unity-event-support--output-format=compact-- extra-types.file= "C:\Program files\unity\editor\data\il2cpp\il2cpp_default_extra_types.txt" "C:\Users\Josh Peterson\documents\il2cpp Blog example\temp\stagingarea\data\managed\assembly-csharp.dll "" C:\Users\Josh Peterson\ Documents\il2cpp Blog example\temp\stagingarea\data\managed\unityengine.ui.dll "" C:\Users\Josh peterson\documents\ Il2cpp Blog Example\temp\stagingarea\data\il2cppoutput "
Well, this is really the old lady's binding--smelly and long ... so let's split the command, and unity is running this executable file:
"C:\Program Files\unity\editor\data\monobleedingedge\bin\mono.exe"
The next parameter is the Il2cpp.exe tool itself:
"C:\Program Files\unity\editor\data\il2cpp/il2cpp.exe"
Note that the remaining parameters are actually passed to Il2cpp.exe instead of Mono.exe. In the above example, 5 parameters are passed to Il2cpp.exe:
–copy-level=none
• Indicate that Il2cpp.exe does not copy the generated C + + files
–enable-generic-sharing
• Tell Il2cpp if it is possible to share the common method. This can reduce the code and reduce the size of the last binary file
–enable-unity-event-support
• Make sure that the code that works with Unity events, through the reflection mechanism, can be generated correctly.
–output-format=compact
• Use shorter names for the types and methods inside when generating C + + code. This makes the C + + code difficult to read because the original name in the IL is replaced by the shorter. But the advantage is that you can make the C + + compiler run faster.
–extra-types.file= "C:\Program files\unity\editor\data\il2cpp\il2cpp_default_extra_types.txt"
• Use the default (also empty) extra type file. Il2cpp.exe will treat the base type or array type that appears in this file as being generated at run time rather than initially appearing in IL code.
It is important to note that these parameters may change in future unity releases. We are not yet stable enough to put Il2cpp.exe's command-line parameters to the fixed stage.
Finally, we have a list of two files and a directory on this long command line:
• "C:\Users\Josh peterson\documents\il2cpp Blog Example\temp\stagingarea\data\managed\assembly-csharp.dll"
• "C:\Users\Josh peterson\documents\il2cpp Blog Example\temp\stagingarea\data\managed\unityengine.ui.dll"
• "C:\Users\Josh peterson\documents\il2cpp Blog example\temp\stagingarea\data\il2cppoutput"
The Il2cpp.exe tool can receive a list of IL assemblies. In the example above, the assembly contains a simple script assembly in the project: Assembly-csharp.dll, and GUI assembly: UnityEngine.UI.dll. You may notice a noticeable lack of something here: where the UnityEngine.dll has gone. The mscorlib.dll on the bottom of the system also disappeared. In fact, Il2cpp.exe automatically references these assemblies internally. You can certainly put these in the list, but they are not required. You only need to mention those root assemblies (those that are not referenced by any other assembly), and the remaining il2cpp.exe are automatically added based on the reference relationship.
The last piece of binding cloth is a directory, Il2cpp.exe will generate the final C + + code here. If you still have a curious heart, you can look at the files produced in this directory. These documents are the subject of our next discussion. Before you look at the code, consider checking the "Development Player" option in the WebGL build settings. Doing so removes the –output-format=compact command-line arguments and makes the names of the types and methods in the C + + code more readable.
Try making some changes in the WebGL or iOS build settings. This way you will find that the parameters passed to the Il2cpp.exe will change accordingly. For example, setting "Enable Exceptions" to "full" will –emit-null-checks,–enable-stacktrace, and – Enable-array-bounds-check these three parameters into the Il2cpp.exe command line.
Something Il2cpp didn't do.
I would like to point out that Il2cpp has always challenged us not to accept it, and we are pleased that we have overlooked it. We did not attempt to rewrite the entire C # standard library. When you build your Unity project using the Il2cpp backend, all of the C # Standard libraries in Mscorlib.dll,system.dll and so on are exactly the same as when you used mono compilation.
We can rely on a robust and tried-and-tested C # standard library, so when it comes to dealing with il2cpp bugs, we can say with certainty that the problem is in the AOT compiler or the runtime library in two places instead of somewhere else.
How we develop, test, release il2cpp
Since we first introduced il2cpp in the January 4.6.1 P5 release, we have released 6 unity versions and 7 patches in succession (Unity version numbers span 4.6 and 5.0). We have fixed more than 100 bugs in these releases.
To ensure that continuous improvement is implemented, we keep only one up-to-date development code on the Backbone (Trunk branch), and before releasing each version we will il2cpp the changes to a specific section and then test to make sure all bugs have been corrected correctly. Our QA and maintenance team has worked surprisingly hard to ensure a fast iteration of the release. The feeling is the version management standard development process, in addition by the article mentioned in the trunk branch, they seem to still use SVN)
The user community that provides high-quality bugs proves to be an invaluable asset. We appreciate the feedback from our users to help us improve our il2cpp and hope that the more feedback we have, the better.
Our Il2cpp development team has a strong sense of "testing first". We often use the "test driven Design" approach, where there is little effort to merge the code without a sufficiently comprehensive test. This strategy is very good for the Il2cpp project. Most of the bugs that we face now are not the result of unexpected behavior, but rather unexpected special circumstances. (for example, using a 64-bit pointer in a 32-bit indexed array that causes the C + + compiler to fail, specifically discussed here) we can quickly and confidently fix this type of bug.
With the help of the community, we worked very hard to make il2cpp fast and stable. By the way, if you're interested in what I just said, we're hiring (well ...). I'm just saying that)
