Shulou(Shulou.com)06/01 Report--

This article introduces the native plug-ins and platform interaction principles in Unity. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Native plug-in / platform interaction

Although most of the time when you use Unity3D for game development, you only need to write logically in C #. However, sometimes it is inevitable to use and write native plug-ins, for example, some third-party plug-ins only provide Cmax plug-ins, reuse existing Cmax plug-ins + modules, and so on. Some functions cannot be realized by Unity3D, so we must call the native interface of Android/iOS, such as obtaining the hardware information of the phone (which is not provided by UnityEngine.SystemInfo), the native pop-up window of the calling system, the vibration of the phone, and so on.

1. The plug-in for CAccord Clippers +

There are several key points for writing and using native plug-ins:

To create a native plug-in for CAccord Clippers +

The export interface must be a C ABI-compatible function

Function calling convention

Identify the function of CCompact + in C# and call the

Identifies the function in DLL. At least specify the name of the function and the name of the DLL that contains the function.

Create a class to hold the DLL function. You can use existing classes to create a separate class for each unmanaged function, or to create a class that contains a set of related unmanaged functions.

Create a prototype in managed code. Use DllImportAttribute to identify DLL and functions. Mark the method with the static and extern modifiers.

Call the DLL function. Call a method on a managed class like any other managed method.

Create the callback function in C #, and call the C # callback function in C # callback function.

Create a managed callback function.

Create a delegate and pass it as an argument to the Candlestick + function. Platform invocation automatically converts the delegate to the common callback format.

Ensure that the garbage collector does not reclaim the delegate until the callback function finishes its work.

So how do C # and native plug-ins call each other?

1. Compile the source code into a managed module

two。 Assemble managed modules into assemblies

3. Load the common language runtime CLR

4. Execute the assembly code.

Note: CLR (Common language Runtime, Common LanguageRuntime) is a runtime environment like the Java virtual machine, which is responsible for resource management (memory allocation and garbage collection) and ensures the necessary separation between the application and the underlying operating system.

In order to improve the reliability of the platform and to achieve the level of stability required by transaction-oriented e-commerce applications, CLR is responsible for other tasks, such as monitoring the running of programs. According to .NET, programs running under CLR supervision are "managed" code, while applications or components that are not under CLR and run directly on bare metal are "unmanaged" code.

These processes are summarized as follows:

Figure. Net program running

The callback function is a function defined in the managed code C#. The call to the callback function enables the managed C# code to be called from the unmanaged Cpool code. So how does C # be called by C _ blank +? It is roughly divided into two steps, which can be shown in the following figure:

Register the callback function pointer in the unmanaged C _ delegate + code (callback function in C # refers to delegate function)

Call a registered managed C# function pointer

Callback functions are a little more complicated than managed calls to unmanaged calls. Callback functions are ideal for repetitive tasks, asynchronous calls, and so on.

From the above introduction, we can know that CLR provides an environment for C # programs to run, and it also completes the interactive calls to C # programs + with unmanaged code. CLR provides two mechanisms for interacting with unmanaged Cripple Category + code:

Platform invocation (Platform Invoke, PInvoke or P/Invoke for short), which enables managed code to call functions derived from unmanaged DLL.

COM interoperability, which enables managed code to interact with component object Model (COM) objects through interfaces. Considering cross-platform, Unity3D does not use this approach.

Platform invocation relies on metadata to find the exported function at run time and Marshal its parameters. The following figure shows this process.

Note:

1. Except when callback functions are involved, platform invocation method calls flow from managed code to unmanaged code and never flow in the opposite direction. Although calls to platform invocations can only flow from managed code to unmanaged code, data can still flow in both directions as input or output parameters.

two。 In the figure, DLL represents dynamic libraries, Windows platform refers to .dll files, Linux/Android refers to .so files, Mac OS X refers to .dylib / framework files, and .a can only be used in iOS. Later on, DLL is used for reference, and DLL is written in Candlestick +.

When platform invocation calls an unmanaged function, it does the following in turn:

Find the DLL that contains the function.

Load the DLL into memory.

Find the address of the function in memory and push its parameters onto the stack to marshal the required data (parameters).

Transfer control to an unmanaged function.

Note: only when the function is called for the first time will the DLL be found and loaded and the address of the function in memory will be found. What is used in iOS is that .a has been statically packaged into the final execution file.

2. Android plug-in

Java also provides such an extension mechanism, JNI (Java NativeInterface), which can communicate with Chand Clearing +.

Note:

JNI wiki- https://en.wikipedia.org/wiki/Java_Native_Interface does not introduce JNI in depth here, those who are interested can study it by themselves. If you don't know JNI yet, don't be afraid, just like Unity3D uses the CMonet + library, it's relatively easy to use, you just need to know this thing. And Unity3D encapsulates this piece of Candlestick + bridge to provide AndroidJNI/AndroidJNIHelper/AndroidJavaObject/AndroidJavaClass/AndroidJavaProxy for easy to use and so on. The specific use will be introduced later. JNI provides several API to enable communication between Java and other languages (mainly ClearCraft +). Starting with Java1.1, the JNI standard has become part of the java platform, which allows Java code to interact with code written in other languages, ensuring that native code works in any Java virtual machine environment. "

As an extension of knowledge, mention the Android Java virtual machine. Android has two Java virtual machines, starting with Dalvik, and later Google added an application running mode ART to the Android 4.4 system. The main difference between ART and Dalvik is that it has an AOT compilation mode. According to the AOT concept, the DEX byte code conversion occurs only once when the device installs the application. This achieves a real advantage over Dalvik, because Dalvik's just-in-time (JIT) compilation method requires transcoding each time the application is run. Below, the Java virtual machine is used to refer to Dalvik/ART.

C#/Java can communicate with Java, so it is possible for C# to communicate with Java by writing a module as bridge, as shown in the following figure:

Note: the C _ Unity3D + bridge itself is not directly related to Unity3D and does not belong to Android and Unity3D. The figure is placed in Unity3D to refer to the bridge implemented in libunity.so to represent the real situation.

JNI can be used not only for the Java code to call the Cpicket + code, but also for the interaction between the Cmax Cure + code and the Java (Dalvik/ART virtual machine). JNI defines two key concepts / structures: JavaVM and JNIENV. JavaVM provides virtual machine creation, destruction and other operations. A process in Java can create multiple virtual machines, but Android can only have one virtual machine per process. JNIENV is thread-related, which corresponds to the JNI environment of the current thread in JavaVM. Only threads attached (attach) to JavaVM have JNIENV pointers. JNI functions can be obtained through JNIEVN pointers, otherwise JNI functions cannot be called.

The Java code to be accessed must be able to access the Java virtual machine. There are two ways to get the virtual machine:

When the dynamic link library is loaded, JVM calls JNI_OnLoad (JavaVM* jvm, void* reserved), and the first parameter is passed in the JavaVM pointer.

Call JNI_CreateJavaVM (& jvm, (void**) & env, & vm_args) to create JavaVM pointers in C & vm_args +

So, all we need to do is define the JNI_OnLoad (JavaVM* jvm, void*reserved) method when writing the C JavaVM Candle + bridge so, and then save the JavaVM pointer as a context.

After getting the JavaVM, you can't get the Java code directly from the JNI function, it must be obtained through the JNIENV pointer associated with the thread. So, as a good development habit to call AttachCurrentThread () every time you get a thread's JNI-related functionality, or every time you get the current JNIENV:java_vm- > GetEnv ((void**) & jni_env, version) through the JavaVM pointer, it must be a thread that has been attached to JavaVM. You can get the Java code through JNIENV. For example, if you want to access an object's field (field) in the local code, you can do something like this:

1. For a class, use jni_env- > FindClass to get a reference to the class object

two。 For fields, use jni_env- > GetFieldId to get the field ID

3. Use the corresponding method (for example, jni_env- > GetIntField) to get the value of the field

Similarly, to call a method, you

Step1. You need to get a reference obj for a class object.

Step2. Is the method methodID. These ID usually point to the internal data structures of the runtime. Finding them requires some string comparisons, but once you actually execute them to get fields or make method calls, it's very fast. Step3. Call jni_env- > CallVoidMethodV (obj,methodID,args).

From the sample code above, we can see that using the original JNI way to interact with the Android (Java) plug-in is too tedious, you have to do too much on your own, and you need to consider caching the queried methods ID, field ID and so on for performance. Fortunately, Unity3D has packaged these for us and has taken into account performance optimizations. Unity3D mainly provides the following two levels of encapsulation to help write code efficiently:

Note: the corresponding Cmax Candle + bridge in Unity3D is included in libunity.so.

Level 1:AndroidJNI, AndroidJNIHelper, the original package is equivalent to the C # Wrapper we wrote above. AndroidJNIHelper and AndroidJNI automate many tasks (finding class definitions, constructors, etc.) and use caching to make calls to java faster. AndroidJavaObject and AndroidJavaClass are created based on AndroidJNIHelper and AndroidJNI, but have a lot of their own logic in the autocomplete section, and static versions of these classes are also available to access static members of the java class. Http://docs.unity3d.com/ScriptReference/AndroidJNI.html, http://docs.unity3d.com/ScriptReference/AndroidJNIHelper.html

Level 2:AndroidJavaObject, AndroidJavaClass, AndroidJavaProxy, these three classes are based on Level1 encapsulation to provide a higher level of encapsulation that is easier to use, which is described in detail in the third part.

3. IOS plug-in

Writing plug-ins in iOS is much easier than Android, because Objective-C is also C-compatible and is fully compatible with the standard C language. These can be very simple to package a layer of extern "c" {}, encapsulate the iOS function in C language, and expose it to Unity3D calls. And it can be compiled into a .a plug-in like the native CumberCandle + library. The principle of communication between C# and iOS (Objective-C) is exactly the same as that of Calgary +:

In addition, UnityiOS supports automatic integration of plug-ins. All files with suffixes .m, .mm, .c, .cpp located in the Asset/Plugings/iOS folder are automatically incorporated into the generated Xcode project. However, it is eventually compiled into the execution file. Files with the suffix .h cannot be included in the Xcode's project tree, but they will appear in the target file system, causing the .m / .mm/.c/.cpp file to compile. This way to write iOS plug-ins, in addition to the need to have some understanding of iOSObjective-C, is no different from the Cmax Cure + plug-in, but more simple.

About the native plug-ins in Unity and platform interaction principles are shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.