问题
部分C++代码库,Release版本与Debug版本速度差别很是大,拿以前的Dlib的人脸检测来讲,Debug版本在手机上跑速度基本上是15秒1帧,而Release版本差很少是1秒2帧,这个速度差别很是的大。android
AS上始终编译不出Release版本的库文件,又不会在Linux下去编译SO文件(技术不行,,,加上Android运行环境和Linux也有一点区别)c++
通过多天的摸索,大概有了思路,记录回顾一下。程序员
Android Studio使用Cmake时的版本设置问题
使用CmakeLists.txt指定,无效。。。
使用build.gradle的arguments指定-DBUILD_TYPE=Release,无效。。。
cppFlags指定-O2或-O3,一样无效。。。
探查目录结构
发现一:AS为了加速使用Cmake的编译效率,Configure模块后,会生成.ExternalNativeBuild文件夹,发现该目录下有cmake/debug和cmake/release两种版本的配置文件。json
继续往里面看,发现有cmake_build_command.txt和android_gradle_build.json。
android_gradle_build.json内容为以下形式: windows
其中的flags为编译此文件的参数。向后拖动,会发现带有-g、-O0(-O2)等。架构
Debug版本和Release版本的最大区别就是有没有加入调试信息和有没有进行优化。优化选项极大的影响了程序的执行速度和效率。jvm
下面的思路是找到这些参数的出处。工具
再来看cmake_build_command.txt内容为以下:gradle
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 版权声明:本文为博主原创文章,转载请附上博文连接!