时隔一年,多了些磨砺,懂了些故事,悟出些道理,但这一年技术却停留在了原地,以前的 Unix 高阶 C 在现在公司暂时无用武之地了,说句实话,打心里我还是喜欢硬件和 C 语言,只是可惜了。有很多人私信想让 NDK 系列文章持续下去,所以就顺带作为自己对过去的回顾整理吧。开始本篇前还是建议先按顺序看看前面这三篇吧,否则可能有些脱节。
《NDK-JNI实战教程(一) 在Android Studio运行第一个NDK程序》
《NDK-JNI实战教程(二) JNI官方中文资料》
《NDK-JNI实战教程(三) 从比Hello World稍复杂点儿的NDK例子说说模板》
上面这三篇内容其实在某种程度上只具备指点意义了,因为很多工具在这一年里发生了很大变化,所以里面的一些配置在现在看来似乎有些不太恰当了,不过你能自己发现这些版本的兼容性问题并改正它也是一种自我调试的能力。
【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载,请尊重作者劳动成果。私信联系我】
还记得之前的 Google IO 大会么? Google 除了在打包系统中集成了 NDK 的支持还将 JetBrains 的 C/C++ IDE CLion 直接集成在了 AS 中,关于 CLion 就不用多说了,做 C 开发且喜欢尝鲜的相信都不陌生的;这个结合对于现在的NDK开发来说简直是屌爆了,因为再也不像以前那么苦逼使用 Eclipse 等工具去写 C 代码,完事再编写 Android.mk 与Application.mk 用 ndk-build 命令行去巴拉巴拉编译了,对于应用层的 NDK 开发一下就变的 Easy 的许多了(现在再想想刚毕业那会在上家公司做 Token Lib 的 NDK 开发时是多么的麻烦与蛋疼!),不过源码下的 NDK 开发还是建议继续使用 Android.mk 的方式去匹配 Android 源码编译框架吧。当然了,近期的 AS 与 Gradle 版本的快速更新对 NDK 开发又有了更加牛叉的体验,因为它完全支持使用 GDB 和 LLDB (不清楚这两是啥的请自行脑部Unix编程基础)来 GUI 化 debug 我们得 native 代码了(以前真的好蛋疼,命令行巴拉巴拉的,泪奔啊!)。
总之现在的 AS 和 Gradle 已经趋于实验完善 NDK 开发了,主要表现在如下方面:
可以看见,现在 NDK 开发已经渐渐的变得越来越方便了,牛叉的一逼!
当我们在 AS 中进行 NDK 开发时 Gradle 脚本的编写其实在前面几篇文章已经给出了,基本模板如下:
//Project的build.gradle文件
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.5.0'
}
}
allprojects {
repositories {
jcenter()
}
}
//Module的build.gradle文件
apply plugin: 'com.android.application'
android {
compileSdkVersion = 23
buildToolsVersion = "23.0.2"
defaultConfig {
applicationId = "com.example.hellojni"
minSdkVersion 19
targetSdkVersion 23
ndk {
moduleName = "hello-jni"
//......
}
}
buildTypes {
release {
minifyEnabled = false
proguardFiles.add(file('proguard-rules.txt'))
}
}
}
可以发现很常规,就是在 android 闭包中添加 ndk 闭包写明一些 lib 相关东西即可,然后其他流程和我们前面几篇没啥区别的。不过有的同学使用新版 AS 和 Gradle 构造上面的脚本可能会遇上一个错误,如下:
Error:(12, 1) A problem occurred evaluating project ':app'.
> Error: NDK integration is deprecated in the current plugin. Consider trying the new experimental plugin. For details, see http://tools.android.com/tech-docs/new-build-system/gradle-experimental. Set "android.useDeprecatedNdk=true" in gradle.properties to continue using the current NDK integration.
Information:BUILD FAILED
哈哈,看见没有,这个错误的原因就是我们 2-2 中准备要介绍的,因为在当前 Gradle 插件版本中这样集成 NDK 的写法已经过时不推荐了,它推荐了新的实验版 Gradle 插件;有的小伙伴可能觉得实验版不爽,就是想用当前版本 Gradle 插件,那也没事,这里给出解决方法,如下:
1、在Project的根目录下创建 gradle.properties 文件;
2、在创建的文件中写上 android.useDeprecatedNdk=true 即可;
3、这样就声明了继续使用过时的 NDK ,然后我们再次构建工程就OK了;
其他流程和前面几篇文章没有区别,直接使用即可,下面我们就来看看新的实验版 Gradle 插件 NDK 开发吧。
前面几篇 NDK 文章都是基于上面 2-1 的 Gradle 脚本来构建了,既然说到了新实验版本 Gradle,那我们就来看看有啥区别(除过 Gradle 区别别的与前几篇 NDK 开发流程保持一致即可),如下:
//Project的build.gradle文件
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle-experimental:0.7.0-alpha1'
}
}
allprojects {
repositories {
jcenter()
}
}
//Module的build.gradle文件
apply plugin: 'com.android.model.application'
model {
android {
compileSdkVersion = 23
buildToolsVersion = "23.0.2"
defaultConfig.with {
applicationId = "com.example.hellojni"
minSdkVersion.apiLevel = 4
targetSdkVersion.apiLevel = 23
}
}
/* * native build settings */
android.ndk {
moduleName = "hello-jni"
/* * Other ndk flags configurable here are * cppFlags.add("-fno-rtti") * cppFlags.add("-fno-exceptions") * ldLibs.addAll(["android", "log"]) * stl = "system" */
}
android.buildTypes {
release {
minifyEnabled = false
proguardFiles.add(file('proguard-rules.txt'))
}
}
android.productFlavors {
// for detailed abiFilter descriptions, refer to "Supported ABIs" @
// https://developer.android.com/ndk/guides/abis.html#sa
create("arm") {
ndk.abiFilters.add("armeabi")
}
create("arm7") {
ndk.abiFilters.add("armeabi-v7a")
}
create("arm8") {
ndk.abiFilters.add("arm64-v8a")
}
create("x86") {
ndk.abiFilters.add("x86")
}
create("x86-64") {
ndk.abiFilters.add("x86_64")
}
create("mips") {
ndk.abiFilters.add("mips")
}
create("mips-64") {
ndk.abiFilters.add("mips64")
}
// To include all cpu architectures, leaves abiFilters empty
create("all")
}
}
看见了吗?Google 当前正在实验的 Gradle 插件已经更新到了 gradle-experimental 0.7.0-alpha1 ,可以明显感觉到 Project 和 Module 的 build.gradle 文件编写闭包都有了变化,细节的相信不需要我再解释了,只是让大家知道有这么回事就行了;框框架架有调整,但是实质其实没啥变化的,大家注意这里新的闭包规则就行了。
PS:关于变化和详细的ABI等细节参见官方文档就行了,非常详细的。
还记不记得我们前面的几篇 NDK 开发都需要手动命令行去 javah 生成 jni 头文件吗?是不是觉得很蛋疼呢?哈哈,AS 有一个功能相信你不陌生吧,那就是 External Tools 自定义功能。所以我们可以通过自定义 AS 的Tools-External Tools,添加 javah 的支持即可通过 AS 直接生成 jni 头文件,设置如下图:
当然了,有时候我们需要使用 Android.mk 和 Application.mk 的做法生成 so 等库文件发布使用,这个也容易,也是直接自定义 Tools-External Tools 即可,如下是 ndk-build 与 ndk-build clean 命令的 AS 自定义:
有了上面这种自定义的 Tools 那就提高很多效率了,譬如我们编译完 Java 文件后在 Project 栏选中要生成 jni 头文件的 java 源文件右键到 External Tools 中的 javah 就能看见 jni 文件夹下面自动生成了对应的 jni 规范头文件;在 Project 栏选中 jni 目录右键到 External Tools 中的 ndk-xxx 相关就能编译生成 so 等文件或者清空编译结果。
当然了,你依旧可以选择像前几篇文章叙述的那样开发 NDK,或者直接在源码环境下开发,又或者混合开发,这都是你自己的选择而已。至于当前选择那个版本的 Gradle 进行 NDK 开发也一样看你个人兴趣了。
【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载,请尊重作者劳动成果。私信联系我】
关于 NDK 的调试一直都是个坑,好在 Google 在大力布局 AS 时开始来填坑了;以前 NDK 的调试都只能依赖于 GDB 命令行的调试,而现在却变得 GUI 化,方便了许多。关于 NDK 的调试这里也是点到为止,因为不是很复杂,有 C 语言开发经验的都很熟悉的,没啥深奥的,只用记住流程就行了。
在现在版本的 AS 中通过 gradle-experimental plugin 插件和 LLDB 的配合使 NDK 调试变得很人性化了,现在基本都是傻瓜模式的 GUI 操作了,具体表现如下图:
可以看见,使用 AS 调试 NDK 和调试 Java 代码基本没啥区别,只是这里的目标选择的是 app-native,同时需要在 SDK Manager 中确认安装了 LLDB 工具。
当然了,有些人可能不喜欢实验板的 Gradle 插件,就想用旧的,可是你会发现按照上面那样选择 native-app 后使用 AS 调试会抛出如下提示窗口:
看着红色地方了吗?不可调试版本,所以我们如果想用原 Gradle 调试 NDK 就需要在 module 的 gradle 文件中进行如下配置:
buildTypes {
debug {
jniDebuggable true
}
}
就这样 OK 了,我们就可以随意的调试了,享受此刻吧!
所谓的其他方式就当做缅怀吧,这可能是我刚接触 NDK 时用的最多也最原始的方式了,那就是 ndk-gdb 手动命令行调试。我想现在基本没必要拥抱它了,所以也就不多介绍了。
【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载,请尊重作者劳动成果。私信联系我】
本文其实没啥技术含量,只是一个工具版本过度的介绍文章,但是大家一定要了解 NDK 的灵魂是 C/C++ 代码的编写,因为很多人一直都说 JNI 开发啥玩意的,其实这里再次阐明这个误区。NDK 开发是 C/C++ 的开发,上层是 Java 的开发,Java 与下面 C/C++ 相互调运的约定接口才叫做 JNI,JNI 接口与 NDK 代码最终合并编译为库文件供上面的 Java 调运而已,一般 NDK 开发和 Java JNI 开发不属于一个团队进行,但是接口规则的约定却时双方商榷的。
【工匠若水 http://blog.csdn.net/yanbober 未经允许严禁转载,请尊重作者劳动成果。私信联系我】