Android Studio编译C++代码——Release与Debug版本的记录

2019独角兽企业重金招聘Python工程师标准>>>

问题
部分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 : 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
里面定义了一些参数，发现有-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找到不同架构的库文件。
--------------------- 
作者：从程序猿到程序员 
来源：CSDN 
原文：https://blog.csdn.net/u012525096/article/details/79069623 
版权声明：本文为博主原创文章，转载请附上博文链接！

转载于:https://my.oschina.net/u/4000302/blog/3058021