The JNI traps of the Android NDK

Background: The last one months have been working on porting libraries, porting C code to the share library to the Android platform. This involves Android NDK (native develop kit) content. The only thing you want to record here is that JNI (Java native Interface) often encounters problems.

Question 1. Forget delete local reference. Take the new to method (e.g., newbytearray) so that the method is more recognizable and needs to be manually called Deletelocalref () to release (except for the return value). One of the more special methods is that getbytearrayelement must call releasebytearrayelements to release. Of course if you just take ByteArray to byte, then you can use getbytearrayregion to achieve it.

Question 2. No newglobalref. Calling Java methods on different threads requires you to save the Jobject object, which requires a global reference to the Jobject object, otherwise it will fail.

Question 3. The length of the Jbytearray. When the JNI layer gets to Jbytearray to the length is not correct, it should be obtained by Java to get byte[] length and then passed to the C layer. Otherwise, c layer may get to be garbled.

Question 4. Threading issues. Different threads use the Jnienv* object, which requires attachcurrentthread to hang the env to the current thread, or env cannot be used.

Question 5. The JAVAP command is a class file operation on Java, and the Javah command needs to run in the package name to the previous path, otherwise the. h file cannot be generated.

Question 6. Try to avoid frequent calls to JNI or to transfer large amounts of data using JNI.

Question 7. Reference table Overflow (max=1024) or Reference table overflow (max=512) must be the result of forgetting to release global Reference or local Reference, Please check the code carefully.

Question 8. Do not use Cygwin to compile NDK code under Windows, and you will encounter arguments too long problem, because the Windows path length is limited. Although you can use subst to map a path to a short path, the windows to the child will not be able to hurt at compile time and debug. The same to build, under windows for about 15 minutes, while under the Mac as long as 5 points, 3 times times the difference. Debugging JNI code to the speed is not to mention, too much difference.

In summary, the JNI code is not much, jni as a data transfer layer, it to the role of only Java and C directly to the bridge, but if the processing is not good will be a disaster, debugging and find a bug very difficult.

Original link: http://blog.csdn.net/goof/article/details/12206783

The JNI traps of the Android NDK