The above article has introduced the calling process of AndroidJavaObject, this article will focus on the function flow in the calling process, after mastering the calling process, analyze the direction that can be optimized

​

Calling process

Again, the official example is used for analysisAccording to the above source analysis, the number of JNI calls and the number of Reflections on the Android side are counted

Create an object

  • JNI calls:
    • FindClass(string name)
    • NewString()
    • CallStaticObjectMethod()
    • FromReflectedMethod()
    • NewObject()
  • reflection
    • getConStructorID()

Creating an AndroidJavaObject at once requires five JNI calls and one Reflection from the Android layer

Executive function

  • JNI calls:
    • NewString()x2
    • CallStaticObjectMethod
    • FromReflectedMethod()
    • CallIntMethod()
  • Reflection:
    • getMethodId()

A function call requires five JNI calls and one Reflection from the Android layer

The second call to the function has one less reflection due to the Android layer cache

The above statistician did not calculate the parameters, JNI pass parameters are needed to create a JNI Array to temporarily save, delete after execution

AndroidJavaClass differs from AndroidJavaObject

You can see this in the Unity code**AndroidJavaClass**Is inherited from**AndroidJavaObject**Can that be used only in the project**AndroidJavaObject**And don’t useAndroidJavaClass * *? The answer isNo * *By viewing the source code can be seen in the creation**AndroidJavaClass**Yes, there is only one JNI call. Performance than**AndroidJavaObject**Much better.

Call optimization direction

Normal direction

According to the process analysis in this paper and above, the following methods can be summarized to improve the efficiency of calling with Android terminal

  • Call static method useAndroidJavaClass, prohibited useAndroidJavaObject
  • Objects that need to be invoked frequently can be invoked repeatedly after being cached to avoid frequent creation
  • Call a method parameter content objects, avoid to use the Android end Application, for example, Activity and Context, View, etc., can be directly on the Android side define packaging method, directly obtained from the Android.
  • Static methods rather than object methods are recommended to avoid creating Android objects

Optional direction

Method parameter protocol

In the process of passing multiple parameters of a method, it is possible to develop a protocol for passing parameters and wrap multiple parameters into a single parameter in Unity layer to reduce the number of passing parameters and reduce THE JNI memory footprint. In the Android layer, a single parameter is decomposed into multiple parameters according to the protocol, and then the specific method is called.

The singleton function Channel

Create a Channel static class on the Android side, register the Android method to be executed, specify a method, the parameters are the corresponding Android method to be executed Key, and the parameters required to execute the method.

The advantage of this scenario is that only one JNI creation and one method reflection are required. Subsequent calls can be mapped to the corresponding method through the Key, without reflection, and without the need for JNI to create the corresponding object to execute. You can expect JNI to deliver content to a minimum.