问题
部分C++代码库，Release版本与Debug版本速度差异非常大，拿之前的Dlib的人脸检测来说，Debug版本在手机上跑速度基本上是15秒1帧，而Release版本差不多是1秒2帧，这个速度差异非常的大。
AS上始终编译不出Release版本的库文件，又不会在Linux下去编译SO文件（技术不行，，，加上Android运行环境和Linux也有一点区别）
经过多天的摸索，大概有了思路，记录回顾一下。
Android Studio使用Cmake时的版本设置问题
- 使用CmakeLists.txt指定，无效。。。
- 使用build.gradle的arguments指定-DBUILD_TYPE=Release，无效。。。
- cppFlags指定-O2或-O3，同样无效。。。
探查目录结构
发现一：AS为了加速使用Cmake的编译效率，Configure模块后，会生成.ExternalNativeBuild文件夹，发现该目录下有cmake/debug和cmake/release两种版本的配置文件。
继续往里面看，发现有cmake_build_command.txt和android_gradle_build.json。
android_gradle_build.json内容为如下形式：
其中的flags为编译此文件的参数。向后拖动，会发现带有-g、-O0（-O2）等。
Debug版本和Release版本的最大区别就是有没有加入调试信息和有没有进行优化。优化选项极大的影响了程序的执行速度和效率。
下面的思路是找到这些参数的出处。
再来看cmake_build_command.txt内容为如下：
Executable : F:\sdk\android-sdk-windows\cmake\3.6.4111459\bin\cmake.exe
arguments :
-HE:\AS_Workspace\TestDlibModule0103\dlibtool
-BE:\AS_Workspace\TestDlibModule0103\dlibtool\.externalNativeBuild\cmake\debug\arm64-v8a
-DANDROID_ABI=arm64-v8a
-DANDROID_PLATFORM=android-21
-DCMAKE_LIBRARY_OUTPUT_DIRECTORY=E:\AS_Workspace\TestDlibModule0103\dlibtool\build\intermediates\cmake\debug\obj\arm64-v8a
-DCMAKE_BUILD_TYPE=Debug
-DANDROID_NDK=F:\sdk\android-sdk-windows\ndk-bundle
-DCMAKE_CXX_FLAGS=-std=c++11
-DCMAKE_TOOLCHAIN_FILE=F:\sdk\android-sdk-windows\ndk-bundle\build\cmake\android.toolchain.cmake
-DCMAKE_MAKE_PROGRAM=F:\sdk\android-sdk-windows\cmake\3.6.4111459\bin\ninja.exe
-GAndroid Gradle - Ninja
-DANDROID_PLATFORM=android-19
-DANDROID_TOOLCHAIN=clang
-DANDROID_STL=c++_shared
jvmArgs :里面定义了一些参数，发现有-DCMAKE_TOOLCHAIN_FILE=F:\sdk\android-sdk-windows\ndk-bundle\build\cmake\android.toolchain.cmake这样的参数，打开该文件。
可看到如下内容：
找到了一些默认配置，其实都是NDK为了方便我们编译，使用了该工具进行编译参数上的简化。向下翻动，发现目标-g：
上面是通用的flags，不知道为什么默认使用了-g，带有调试信息的标志。
下面是Debug和Release的标志信息。此时的疑问：该处有Dubug和Release版本的区分，为什么在外面进行修改参数，不起作用呢？
猜测、尝试
.ExternalNativeBuild/cmake/debug和.ExternalNativeBuild/cmake/release中的android_gradle_build.json的flags其实是不一样的。
Debug的flags是-O0，不进行任何优化。
Release的flags是-Os，进行了不缩小代码体积的O3优化（相当于-O2.5）。
Build/intermediates/下是一些中间文件，找到cmake文件夹，发现只有debug文件夹，说明只生成了debug版本的库文件。
发现了build variants这么个东西，欣喜若狂的发现了Release，修改成Release，立马Make 模块名。
从中间文件那里看到，生成了需要的Release版本的库文件，大小明显比Debug版本的要小。
验证
拷贝到主工程的Jnilibs下，编译APK，安装，运行，速度果然相比Debug版本提升很多很多。
使用预编译的库出现的问题
发现主工程与导入的module（用到了JNI）关联后，即使在build.gradle设置了sourceSets.main.jniLib.srcDirs，粘贴了生成好的库文件，主工程编译时，还是会先去检查被关联的module的intermediates文件夹中的cmake的debug下的debug版本的so库是否存在以及是否被替换（猜测应该在哪里配置了的），若不存在或被替换，则重新去编译module，生成最新的so库文件。
然后自动拷贝到生成APK中去。
进一步发现
主工程的libs中的文件优先于module的中间文件的，也就是说APK中的SO库是来自于libs，但还是会进行上面的检查和编译。
除非删掉module下的C++代码和取消CmakeLists.txt，让Module变成纯的JAVA库。
小问题
由于module中设置了STL=c++_shared，一开始只将我自己的库拷贝到了另外的工程的libs去，发现运行时报错，说找不到libc++_shared.so库文件，但是在自己的工程中，就不会出现这样的问题。
自己的工程中，发现在生成的APK中的libs下是有这个库文件的，猜想也是默认将中间文件添加到了主工程的库文件当中去（就像上面的那样，自己的工程中，即使在libs中不加自己的库，但是有依赖关系的话，主工程就会自动加依赖模块的库文件进去，而在别人的工程中，没有关联的module或添加的是纯JAVA库不编译C++代码）。
解决办法
手动拷贝libc++_shared.so到主工程的libs下，当作预编译的库使用，该文件可在android-sdk-windows\ndk-bundle\sources\cxx-stl\llvm-libc++\libs找到不同架构的库文件。
