Android JNI 开发
概述
几乎稍有经验的Android开发，都会在工作中用到JNI的开发。即使工作中没有涉及到JNI的开发，在我们使用第三方的库时，也经常需要引入.so文件。
最初我在学习JNI开发时，基本是懵的。因为大部分JNI开发的指南，其实是在教我们，如何生成.so文件和如何引入.so文件。
我们参照着博客的步骤，修改build.gradle，添加cmakelists，写JNI接口，写c++。但每一步，我们实际是在做啥，我们并没有清晰的认识。这也导致每次JNI的配置步骤，看一次忘一次。
本文旨在彻底写清楚，当我们在做JNI开发时，我们在做什么。
.so文件
so是shared object的缩写，见名思义就是共享的对象，机器可以直接运行的二进制代码。大到操作系统，小到一个专用软件，都离不开so。参见https://en.wikipedia.org/wiki/Library so主要存在于Unix和Linux系统中。
A shared library or shared object is a file that is intended to be shared by executable files and further shared object files. Modules used by a program are loaded from individual shared objects into memory at load time or run time, rather than being copied by a linker when it creates a single monolithic executable file for the program.
我们通过C/C++开发的软件，如果以动态链接库的形式输出，那么在Android中它的输出就是一个.so文件。
相比于.a，.so文件是在运行时，才会加载的。所以，当我们将.so文件放入工程时，一定有一段Java代码在运行时，load了这个native库，并通过JNI调用了它的方法。
所以，当我们使用JNI开发时，我们就是在开发一个.so文件。不论我们是开发一个工程，还是开发一个库，只要当我们使用C++开发，都会生成对应的.so文件。
所以JNI开发的核心是，我们生成so的过程，和使用so的过程。
生成.so文件
当我们在新建工程过程中，选中support c++时，系统会为我们写好一些配置。
build.gradle
android {
compileSdkVersion 26
defaultConfig {
minSdkVersion 14
targetSdkVersion 26
versionCode 1
versionName "1.0"
externalNativeBuild {
cmake {
// cpp 编译时的额外选项
cppFlags ""
}
}
// 设置 执行 gradle assembleRelease 时，支持的 SO 库构架
ndk{
abiFilters "armeabi" , "armeabi-v7a" , "arm64-v8a"
}
}
buildTypes {
release {
postprocessing {
removeUnusedCode false
removeUnusedResources false
obfuscate false
optimizeCode false
proguardFile 'proguard-rules.pro'
}
}
}
externalNativeBuild {
cmake {
// cmakelists文件的路径
path "CMakeLists.txt"
}
}
}这是module的build.gradle中的一段。其中，两个externalNativeBuild与ndk是与JNI相关的配置。
我们写好的.cpp/.h文件需要经过编译才能生成.so，让apk得以调用。在编译生成.so文件的过程中，我们可以添加如下一些配置。
cppFlags
cmake时的额外参数，此时我们暂时没有额外参数，所以为空。具体使用参考https://developer.android.com/studio/projects/add-native-code?hl=zh-cn
abiFilters
设置 执行 gradle assembleRelease 时，支持的 SO 库构架。如果像上面的代码这样设置，我们打出来的包，就会包含三种架构的.so包。这必然会使APK包体积变大。可以考虑使用productFlavors进行优化。
cmake.path
指定cmakelists文件的路径。
除了这些必须的标签外，externalNativeBuild中还有很多可以配置的东西，因为不是必需，不在此赘述。如ndkBuild中可以设置c++的版本等配置。
CMakeLists.txt
# For more information about using CMake with Android Studio, read the
# documentation: https://d.android.com/studio/projects/add-native-code.html
# Sets the minimum version of CMake required to build the native library.
cmake_minimum_required(VERSION 3.4.1)
# Creates and names a library, sets it as either STATIC
# or SHARED, and provides the relative paths to its source code.
# You can define multiple libraries, and CMake builds them for you.
# Gradle automatically packages shared libraries with your APK.
add_library( # Sets the name of the library.
native2-lib
# Sets the library as a shared library.
SHARED
# Provides a relative path to your source file(s).
src/main/cpp/native-lib.cpp )
# Searches for a specified prebuilt library and stores the path as a
# variable. Because CMake includes system libraries in the search path by
# default, you only need to specify the name of the public NDK library
# you want to add. CMake verifies that the library exists before
# completing its build.
find_library( # Sets the name of the path variable.
log-lib
# Specifies the name of the NDK library that
# you want CMake to locate.
log )
# Specifies libraries CMake should link to your target library. You
# can link multiple libraries, such as libraries you define in this
# build script, prebuilt third-party libraries, or system libraries.
target_link_libraries( # Specifies the target library.
native2-lib
# Links the target library to the log library
# included in the NDK.
${log-lib} )add_library
该指令的主要作用就是将指定的源文件生成链接文件，然后添加到工程中去。指令语法如下：
add_library(<name> [STATIC | SHARED | MODULE]
[EXCLUDE_FROM_ALL]
[source1] [source2] [...])find_library
该指令的作用为查找库，指令语法如下：
find_library (<VAR> name1 [path1 path2 ...])target_link_libraries
该指令的作用为将目标文件与库文件进行链接。该指令的语法如下：
target_link_libraries(<target> [item1] [item2] [...]
[[debug|optimized|general] <item>] ...)完成以上配置后，当你Make Project时，我们就可以在build目录下，看到我们的.so文件了。
不论是给自己项目用，还是提供给其他项目用。当我们执行我们的C++代码时，我们都使用的是这个.so文件了。
使用.so文件。
将下来，我们就需要关注。Android是如何使用.so文件的了。 在很多如何使用so文件的博客中，我们可以看到下面这一句话：
jniLibs.srcDirs = ['libs']这句话是将我们的so文件的目录指定为libs文件夹。这样，我们只需要将so文件放入libs即可。
这样，当我们构建APK包时，gradle就会帮我们，将这个.so文件，打入我们的APK文件中。
这样，当我们在代码中，执行到
System.loadLibrary("native2-lib");我们就会加载这个libnative2-lib库了。
有趣的问题
在开发中，我们会遇到一个有趣的情况。
比如，我们有工程ProjectA。有库LibraryA。
Project依赖库LibraryA。
LibraryA使用了NDK，生成了.so库。
由于ProjectA依赖了库LibraryA，所以当我们构建ProjectA时，一定会先构建LibraryA。此时，我们就已经生成了libnative2-lib.so。
如果我们再将libnative2-lib.so放入ProjectA的libs目录时，我们的工程下，其实就有两个libnative2-lib.so了。此时，我们生成APK时，系统如何辨认两个libnative2-lib.so呢。当我们调用
System.loadLibrary("native2-lib");我们到底加载的是哪个libnative2-lib.so呢？
经过试验，我们发现，APK中，只会有一个libnative2-lib.so。并且，是ProjectA中的libnative2-lib.so。这个地方，我们可以推断出gradle在为我们构建APK时的逻辑。
gradle在构建Android APK 时，一定是指定了好几个工程中存放.so文件的目录。在build时，会遍历这些目录，并将指定目录下的.so文件复制到APK包中。如果名字相同的.so文件，则会相互覆盖。 由于LibraryA是先build的，所以LibraryA中的.so文件会被ProjectA中的.so文件覆盖。
SDK如何输入.so
如果我们开发的就是一个Library。当其他Project集成我们的Library时，需要将我们的.so文件，拷贝到Project的so文件指定路径。
通常来说，我们会在build.gradle中，添加一个小小的脚本。将.so文件在build后，复制到我们的指定目录中。方便使用Project取用。
task(copySoFile) {
String fromDir = './build/intermediates/cmake/debug/obj'
String toDir = [target dir]
copy {
into toDir
from(fromDir) {
include '**'
}
}
println "------------ so files copied --------------"
}总结
本文记录了当Android需要进行JNI开发，需要明白的一些基础知识。如有问题，欢迎指正。