See Android and iOS cross-platform things from COCOS2DX source code

COCOS2DX a game engine that supports 2d and 3d on a cross-mobile (flatbed) platform, and is based on C/E + +, which is not described here.
We are concerned about cross-platform of those things, naturally found platform directory. Guys, there's a lot of support for the platform, and the most interesting thing we can focus on is the first two platforms in alphabetical order, Android and Apple. Then take a look at WINRT and Linux. Platform this directory, the name of the object, is something that uses the Platform Service (encapsulation). The platform services of each platform subdirectory in the platform directory are the same, but the Android directory is more specific than the JNI and Java two directories. Because it is used under the Android platform, it is also cross-language in C + +. As for the ios,c/c++ and OC mash-up is very natural. So let's look at the cross-language things on the Android platform.

Cocos/platform/android/jni, no explanation, is Java native interface. Contains the invocation contract from Java to C + + and from C + + to java.
The main thing about this directory is the Jnihelper related header and source two files. It is primarily responsible for helping the C + + code layer to complete calls to static methods of the Java code layer. The other code files are specific to a Java class that provides C + + to Java static method invocation Help, or Java-to-C + + function invocation help.
Therefore, this directory is mainly used to help C + + code to call Java code, and C + + cross-platform Java-provided functions (or services) functions, generally dispersed in the specific module directory, when the need to support cross-platform code, the platform-related code will be written as a class of '- Android.cpp ' file to go.

Another directory is Cocos/platform/android/java. Yes, it is the directory of Java code. It contains components that are designed for the Cocos engine layer, which is the Java library, or the Java library, that is used to make it possible to use the C + + code layer. You can use Java code to provide services to the Android platform. It's natural for the Apple platform (iOS and Mac) to be mixed with the OC class, while the WINRT platform provides the services that the platform offers, which is in the form of a COM/C + +, or a C + + library for Linux, a third-party library. So the subdirectories of other platforms, other than Android, don't make much of a lot of trouble (as opposed to Android).

Here's a look at this comparison:

// jniJclass _clazz = (jclass) env->= env->findclass (_cstrclassname); // IOS Class _clazz =class];

// jniJmethodid methodid = env->getmethodid (_clazz, Cstrmethodname, cstrparamcode); // IOS SEL _selector =

// JNI /* */); // IOS /* */);

Can see between Java and OC there is a common, now from Java to see OC, or from OC see Java, will not feel completely unfamiliar, but a bit close.
One thing to note is that Java's class name is full-path, referencing the package in code as a point reference, and in the name, the path separated by the '/' node. Java splits methods into method names and prototype descriptions. The prototype description contains the parameter list and the return type, the parameter list is placed in front of the ' () ' inclusion, followed by the return type. A description of the Java object type is contained in ' L; ' In pairing, the Java object type is naturally the full path of the class name. ' [' represents an array.

JNI calls C + + code from Java it's probably the same thing. There are only class static and member methods in Java, so Java is called to have a corresponding method entry at the Java layer (or the equivalent of the Java code call, Methodid), so that the member method is declared as native. The Java call from the above-C + + function Callobjectmethod can be seen, Java calls the Member method is also based on Methodid to find the corresponding code entry, JNI generated C/ A function declaration is a mapping of methodid in Java that corresponds to a member method declared as native.

When cross-JNI, the corresponding loss is also generated, the reason is only to see the JVM code. Here I'm just trying to guess, maybe C + + functions and methodid is not directly mapped, the middle may be to do routing or adaptation, or there are several layers of processing, building a cross-language stack frame environment. It is also possible that the C + + function is not a byte-code directive, not conducive to the optimization of the virtual machine code, as if the processor in the branch prediction failure, to empty the pre-loaded instructions to reload the instruction branch.

See Android and iOS cross-platform things from COCOS2DX source code