Android NDK-based learning tour-resource release

Android NDK-based learning tour-resource release
During the previous project, because of frequent interaction with the C engine, the entire application suddenly fails. Because I started learning Java, I don't have much idea about actively releasing the memory (GC directly helps to recycle it). The reason for the later query is that some JNI object memory is not released. The following describes how to release related resources.
 
JNI programming implements the interaction between native code and Java programs. Therefore, JNI code programming complies with the native code programming language programming rules and JNI programming documentation specifications. In terms of memory management, the memory management mechanism of native code programming language should still be followed, and the memory management of JNI programming should also be considered.
This chapter briefly summarizes the obvious Memory leakage in JNI programming. This article describes native code programming language memory management and JNI specification memory management.
Native Code Memory leakage
JNI programming is first a specific programming language, or C language, or C ++, or assembly, or other native programming languages. Each Programming Language Environment implements its own memory management mechanism. Therefore, JNI program developers should follow the native language's memory management mechanism to avoid Memory leakage. Take the C language as an example. When malloc () is used to dynamically allocate memory in the process heap, after the JNI program is used up, it should call free () to release the memory. In short, all the memory leak rules that should be paid attention to in native programming are still applicable in JNI programming.
Memory leakage introduced by Native language itself will cause native memory, which may cause native memory out of memory in severe cases.
Memory leakage introduced by Global Reference
JNI programming also complies with the JNI standard. JVM attaches the JNI programming-specific memory management mechanism.
The Local Reference in JNI only exists when native method is executed. It is automatically invalid when native method is executed. This automatic failure makes the use of the Local Reference relatively simple. After the native method is executed, the reference count of the referenced Java objects is reduced by 1. Does not cause memory leakage of Java objects in Java Heap.
Global Reference has always been valid for Java objects. Therefore, the Java objects referenced by Global Reference will always exist in Java Heap. When using Global Reference, programmers must carefully maintain the use of Global Reference. If you must use Global Reference, make sure to delete it when you do not need it. Just like in C, after calling malloc () to dynamically allocate a piece of memory, call free () to release it. Otherwise, the Java object referenced by Global Reference will remain in Java Heap forever, resulting in Memory leakage of Java Heap.
 
 
1. What needs to be released?
What do you need? The basic data types of JNI do not need to be released, such as jint, jlong, and jchar. We need to release the referenced data type, including the array family. Such as jstring, jobject, jobjectArray, and jintArray.
Of course, you may often ignore jclass and jmethodID, which also need to be released.
 
2. How to release it?
1) Release String
Jstring jstr = NULL;
Char * cstr = NULL;
// Call Method
Jstr = (* jniEnv)-> CallObjectMethod (jniEnv, mPerson, getName );
Cstr = (char *) (* jniEnv)-> GetStringUTFChars (jniEnv, jstr, 0 );
_ Android_log_print (ANDROID_LOG_INFO, "JNIMsg", "getName ----> % s", cstr );
// Release resources
(* JniEnv)-> ReleaseStringUTFChars (jniEnv, jstr, cstr );
(* JniEnv)-> DeleteLocalRef (jniEnv, jstr );
2) Release classes, objects, and methods
(* JniEnv)-> DeleteLocalRef (jniEnv, XXX );
 
"XXX" indicates the referenced object
3) release the array family
JobjectArray arrays = NULL;
 
Jclass jclsStr = NULL;
 
JclsStr = (* jniEnv)-> FindClass (jniEnv, "java/lang/String ");
 
Arrays = (* jniEnv)-> NewObjectArray (jniEnv, len, jclsStr, 0 );
 
(* JniEnv)-> DeleteLocalRef (jniEnv, jclsStr); // release the String class
 
(* JniEnv)-> DeleteLocalRef (jniEnv, arrays); // release the jobjectArray Array
 

 
When the native method calls DeleteLocalRef () to release a JNI Local Reference, it first uses the pointer p to locate the location of the corresponding Local Reference in the Local Ref table, and then deletes the Local Reference from the Local Ref table, this cancels the reference to the corresponding Java object (Ref count minus 1 ).
 
 

This article is from duicky's blog