android jni framework,Android Framework层的JNI机制（一）

JNI(Java Native Interface)Java本地接口。最初对JNI的了解，仅仅停留在Java通过JNI可以实现对C/C++函数的调用。比如，首先在Java中写好native方法。然后在C或C++中文件中，定义一个对应的函数，在这个函数中，实现自己的代码或者调用其他的标准库。最后加载一下生成的动态库，便可以开始使用这个native方法。像是在照葫芦画瓢，知其然，不知其所以然。最近在看Framework层中JNI相关的代码，加上网上大咖的神贴，综合理解，先以Framework中Log为研究对象，分析JNI在其中的使用。

概要

JNI机制基本要点

Android中JNI的存在方式

Framework层Log的JNI使用

一、JNI机制基本要点

用过JNI的工程师，都接触过下面这些知识点：

JavaVM：表示Java虚拟机。

JNIEnv：表示JNI环境的上下文，例如注册、查找类、异常等。

jclass：在JNI中表示的Java类。

jmethodID：在JNI中表示的Java类中的方法。

jfiledID：在JNI中表示的Java类中的属性。

线程：JNI中通过AttachCurrentThread和DetachCurrentThread方法，实现和Java线程的结合。

它们都在一个叫jni.h的头文件中，这个头文件是JNI机制中很重要的一个头文件。

源代码路径：/libnativehelper/include/nativehelper/jni.h。

在libnativehelper目录下的源文件，编译后会生成一个libnativehelper.so的动态库。其实，jni.h是Android根据Java本地调用的标准写成的一个头文件，在它里面包括了基本类型(类型的映射)，以及JavaVM，JNIEnv，jclass，jmethodID，jfiledID等数据结构的定义。

JavaVM对应于jni.h中JNIInvokeInterface结构体，表示虚拟机。JNIEnv对应于JNINativeInterface结构体，表示JNI的环境。在JNI的使用过程中，所调用的功能大都来自JNINativeInterface结构体。例如，处理Java属性和方法的查找，Java属性的访问，Java方法的调用等功能。另外，在JNINativeInterface结构体中，涉及到的一个JNINativeMethod结构体，它表示在本地实现的一个方法，即native方法，后面进行JNI注册的时候会用到。

二、Android中JNI的存在方式

Android中JNI的存在方式主要分两种： 框架层和应用层的JNI使用。不对应用层的使用情况进行介绍，主要目的还是看看框架层里面的JNI。

在Android框架中，JNI库是一些普通的本地动态库，被放置在目标系统的/system/lib目录中。

Java框架层，最主要的JNI内容源代码路径为：/frameworks/base/core/jni。

这里面的代码会生成一个libandroid_runtiem.so的动态库。接下来要分析的Log中JNI的使用，就在这个目录之中。

三、Framework层Log的JNI使用

Java框架层的Log

在编程的时候，大家都用过Log，其实这个我们经常使用的Log工具，在Java框架层最终调用的是native方法。

贴上源码的路径：/frameworks/base/core/java/android/util/Log.java。

如果感兴趣，可以进去瞧一瞧。咱们以Log.java中的println_native()这个本地方法，进行分析。

Log的JNI实现

Log的JNI的实现是在一个叫android_util_Log.cpp的源文件中。

源码路径：

头文件：/frameworks/base/core/jni/android_util_Log.h。

源文件：/frameworks/base/core/jni/android_util_Log.cpp。

在android_util_Log.cpp源文件中，我们可以找到println_native的身影。

/*

* JNI registration.

*/

static const JNINativeMethod gMethods[] = {

/* name, signature, funcPtr */

{ "isLoggable", "(Ljava/lang/String;I)Z", (void*) android_util_Log_isLoggable },

{ "println_native", "(IILjava/lang/String;Ljava/lang/String;)I", (void*) android_util_Log_println_native },

{ "logger_entry_max_payload_native", "()I", (void*) android_util_Log_logger_entry_max_payload_native },

};

JNINativeMethod是前面提到的一个结构体，这个结构体表示一个实现的本地方法。这个结构体在jni.h文件中定义，内容如下：

typedef struct {

const char* name;

const char* signature;

void* fnPtr;

} JNINativeMethod;

它有三个指针变量，第一个是字符型指针，可以表示一个字符串，即native方法的名称；第二个也是字符型指针，同样可以表示一个字符串，代表这个native方法的参数和返回值(有特殊的表示方法)；第三个是一个未指定类型指针，表示一个函数指针，指向这个native方法对应的jni函数。

有了对JNINativeMethod了解，就可以理解println_native在android_util_Log.cpp源文件中的含义了。其对应jni实现函数是android_util_Log_println_native()。在jni实现函数中，又调用了__android_log_buf_write()这个方法，__android_log_buf_write是本地框架层(非Java框架层)基础的C库之上，Android最底层的本地Log库。

Log库的源码路径为：

头文件：system/core/include/cutils/log.h。

源文件：system/core/liblog。

编译后会生成liblog.so动态库和liblog.a静态库。

Log的JNI注册

int register_android_util_Log(JNIEnv* env)

{

jclass clazz = FindClassOrDie(env, "android/util/Log");

levels.verbose = env->GetStaticIntField(clazz, GetStaticFieldIDOrDie(env, clazz, "VERBOSE", "I"));

levels.debug = env->GetStaticIntField(clazz, GetStaticFieldIDOrDie(env, clazz, "DEBUG", "I"));

levels.info = env->GetStaticIntField(clazz, GetStaticFieldIDOrDie(env, clazz, "INFO", "I"));

levels.warn = env->GetStaticIntField(clazz, GetStaticFieldIDOrDie(env, clazz, "WARN", "I"));

levels.error = env->GetStaticIntField(clazz, GetStaticFieldIDOrDie(env, clazz, "ERROR", "I"));

levels.assert = env->GetStaticIntField(clazz, GetStaticFieldIDOrDie(env, clazz, "ASSERT", "I"));

return RegisterMethodsOrDie(env, "android/util/Log", gMethods, NELEM(gMethods));

}

这是android_util_Log.cpp源文件中对jni的注册，可以看到RegisterMethodsOrDie()这个方法的调用，传入了我们前面看到的gMethods数组，进行JNI注册。到这里结束了吗？确实第一次看到这里的时候，以为就此结束了。然而，是谁调用了register_android_util_Log()这个方法？在RegisterMethodsOrDie()这个函数里面又做了什么呢？

register_android_util_Log()函数

register_android_util_Log()这个方法只在android_util_Log.cpp源文件中进行定义，需要找到谁对它进行了调用，才好进一步理解Log的JNI的注册过程。Android源码环境有一个非常不错的方法，可以通过字符串，找到出现过的文件。

指令：cgrep 'register_android_util_Log'

类似于：find . -type f -name "*.cpp" | xargs grep "register_android_util_Log"

通过结果可以发现一个AndoridRuntime.cpp，这是个什么鬼？只能说它很强，是系统运行时的工具类，为Android的运行提供支持。JNI的部分封装也在这个类中。

源码路径：

/frameworks/base/include/android_runtime/AndroidRuntime.h。

/frameworsk/base/core/jni/AndroidRuntime.cpp。

可以发现，它也是在/frameworsk/base/core/jni目录下，说明也是在libandroid_runtime.so动态库中。

在AndroidRuntime.cpp源文件gRegJNI数组中，发现了register_android_util_Log方法。

static const RegJNIRec gRegJNI[] = {

REG_JNI(register_com_android_internal_os_RuntimeInit),

REG_JNI(register_android_os_SystemClock),

REG_JNI(register_android_util_EventLog),

REG_JNI(register_android_util_Log),

REG_JNI(register_android_util_MemoryIntArray),

//省略

}

然后，又在AndroidRuntime.cpp源文件的AndroidRuntime::startReg()这个方法中，使用了gRegJNI这个数组。

/*

* Register android native functions with the VM.

*/

/*static*/ int AndroidRuntime::startReg(JNIEnv* env)

{

ATRACE_NAME("RegisterAndroidNatives");

/*

* This hook causes all future threads created in this process to be

* attached to the JavaVM. (This needs to go away in favor of JNI

* Attach calls.)

*/

androidSetCreateThreadFunc((android_create_thread_fn) javaCreateThreadEtc);

ALOGV("--- registering native functions ---\n");

/*

* Every "register" function calls one or more things that return

* a local reference (e.g. FindClass). Because we haven't really

* started the VM yet, they're all getting stored in the base frame

* and never released. Use Push/Pop to manage the storage.

*/

env->PushLocalFrame(200);

if (register_jni_procs(gRegJNI, NELEM(gRegJNI), env) < 0) {

env->PopLocalFrame(NULL);

return -1;

}

env->PopLocalFrame(NULL);

//createJavaThread("fubar", quickTest, (void*) "hello");

return 0;

}

按源代码注释的意思是，这里在向虚拟机注册本地方法。同样在AndroidRuntime.cpp源文件中，AndroidRuntime::start()中又调用了AndroidRuntime::startReg()，到这里，需要继续往下看，就得找找是谁调用了AndroidRuntime::start()方法。然而，要想知道谁调用了它，已经涉及到zygote这一块的知识。

zygote

zygote是通过init进程读取init.rc启动的一个守护进程的名称。如果从最下面开始说，得再介绍一下Android启动流程的本地阶段，这一块，属于扩充了解。

Android启动流程的本地阶段：

BootLoader运行，Linux通用内容。

Linux内核运行，Linux通用内容，通常是二进制形式代码形式存在。

内核加载根文件系统，Linux通用内容。

init进程运行，用户空间的第一个进程。

运行init.rc脚本。

加载system和data文件系统。

运行各种服务，主要为各种守护进程。

本地部分启动完成，形成一系列守护进程，其中名称为zygote的守护进程，将继续完成Java部分的初始化。

Java部分的启动流程：

从本地可执行程序运行名为zygote的守护进程。

zygote运行ZygoteInit(进入Java程序)。

ZygoteInit运行SystemServer(Java类)，并分裂出新的进程。

SystemServer首先运行libandroid_servers.so库当中的初始化(进入本地程序)。

执行libanroid_servers.so当中的系统初始化。

SystemServer中的Java初始化再次被调用(再入Java程序)。

建立ServerThread线程。

ServerThread线程建立各个服务，然后进入循环。

ActivityManagerService在启动结束发送相关信息。

各个Java应用程序运行。

这些是引用资料书中的知识，想详细了解，可以看看《Android核心原理及系统级应用高效开发》或《深入理解Android系统》。回到我们的zygote进程，init.rc中包含了一个init.${ro.zygote}.rc。 init.rc和init.${ro.zygote}.rc源码路径：/system/core/rootdir。

在init.zygote32.rc中，相关内容如下：

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server

class main

socket zygote stream 660 root system

onrestart write /sys/android_power/request_state wake

onrestart write /sys/power/state on

onrestart restart audioserver

onrestart restart cameraserver

onrestart restart media

onrestart restart netd

writepid /dev/cpuset/foreground/tasks

这个是Android系统中的特殊语法，它启动了一个名称为zygote的进程，也就是/system/bin/app_process这个可执行程序。

源码路径为：/frameworks/base/cmds/app_process。

在这个目录下，有一个app_main.cpp的源文件，其中相关的代码如下：

// 省略

if (zygote) {

runtime.start("com.android.internal.os.ZygoteInit", args, zygote);

} else if (className) {

runtime.start("com.android.internal.os.RuntimeInit", args, zygote);

} else {

fprintf(stderr, "Error: no class name or --zygote supplied.\n");

app_usage();

LOG_ALWAYS_FATAL("app_process: no class name or --zygote supplied.");

return 10;

}

在app_main.cpp源文件中，有一个AppRuntime的类，它继承了AndroidRuntime。runtime是AppRuntime类的一个实例，runtime.start()相当于调用了AndroidRuntime::start()这个方法，至此，前后就连接起来了。概括的说，系统启动zygote进程时，会调用AndroidRuntime::start()方法，接着调用AndroidRuntime::startReg()，然后调用到了register_android_util_Log()这个方法。剩下最后一个问题，register_android_util_Log()被调用后，在它方法体中的RegisterMethodsOrDie()函数做了什么？

RegisterMethodsOrDie()函数

RegisterMethodsOrDie()这个方法是/frameworks/base/core/jni/core_jni_helpers.h中声明的一个方法。

static inline int RegisterMethodsOrDie(JNIEnv* env, const char* className,

const JNINativeMethod* gMethods, int numMethods) {

int res = AndroidRuntime::registerNativeMethods(env, className, gMethods, numMethods);

LOG_ALWAYS_FATAL_IF(res < 0, "Unable to register native methods.");

return res;

}

在其中我们可以看到，其实又回到了AndroidRuntime这个类，调用了它的registerNativeMethods()方法，并最终调用了jniRegisterNativeMethods()进行本地方法的注册。而jniRegisterNativeMethods()是/libnativehelper/JNIHelp.cpp源文件中的方法，它里面内容为：

extern "C" int jniRegisterNativeMethods(C_JNIEnv* env, const char* className,

const JNINativeMethod* gMethods, int numMethods)

{

JNIEnv* e = reinterpret_cast(env);

ALOGV("Registering %s's %d native methods...", className, numMethods);

scoped_local_ref c(env, findClass(env, className));

if (c.get() == NULL) {

char* tmp;

const char* msg;

if (asprintf(&tmp,

"Native registration unable to find class '%s'; aborting...",

className) == -1) {

// Allocation failed, print default warning.

msg = "Native registration unable to find class; aborting...";

} else {

msg = tmp;

}

e->FatalError(msg);

}

if ((*env)->RegisterNatives(e, c.get(), gMethods, numMethods) < 0) {

char* tmp;

const char* msg;

if (asprintf(&tmp, "RegisterNatives failed for '%s'; aborting...", className) == -1) {

// Allocation failed, print default warning.

msg = "RegisterNatives failed; aborting...";

} else {

msg = tmp;

}

e->FatalError(msg);

}

return 0;

}

这段代码可以看出，通过调用(*env)的RegisterNatives指针函数，进行了JNI注册。所以最后的动作是交给了JNINativeInterface结构体所表示的JNI环境执行。当在Java层调用native方法时，不需要依据native方法包和名称寻找对应的JNI函数。而是可以通过已经注册的映射关系，快速找到对应的JNI函数的指针，从而开始函数调用，大大提高执行效率。