学习 android ndk 1 - 相关配置与环境搭建

最新推荐文章于 2022-12-13 20:31:57 发布

阿祖AAAAAA

最新推荐文章于 2022-12-13 20:31:57 发布

阅读量1k

点赞数 1

分类专栏： cocos2dx 文章标签： android ndk

本文链接：https://blog.csdn.net/carl_zhong/article/details/18136997

版权

cocos2dx 专栏收录该内容

13 篇文章 1 订阅

订阅专栏

由于最近项目在android上存在几率性崩溃的bug，对此我“郁闷”了很长一段时间，至于在windows上运行完全无误的程序怎么可能在android就这么的脆弱易蹦呢？我认为系统之间的差异再所难免，写程序要是真正实现跨平台确实是很有挑战性的。对于十分流行的苹果和android两个系统，开发苹果系统上的游戏应该相对于android更易开发，更易调试的。但是android就不那么容易了，至少我周围懂移动开发的全是xcode苹果流的，android懂的人少，没人精通。因为只针对游戏开发，我为此大概的学了下android的开发流程并打算深入ndk的学习，了解下android相关地层系统调用的特性与其他平台的差异，开发出更稳定更有效率的好游戏~。(顺便吐下槽，我更看好android的发展，毕竟开源的魅力是无限的 )

我认为搞android开发至少得了解java吧，就算你只用c++编程有的时候还是会调用些android系统的API或者其他第三方的API吧，毕竟android源生API是java啊，至少知道android的一个简单的程序入口和运行基本流程吧，所以不懂的话多多少少还是对这些东西要有所了解和学习的。

这就步入正题：先在android官网下载 adt-bundle-windows(集成android开发环境) 和 android-ndk-<ver> (NDK) 安装完毕后解压待用

android NDK的下载地址： http://developer.android.com/tools/sdk/ndk/index.html 该网址的下面有相应的NDK的说明，我想将我感觉有用的内总结下：

1.为了确保兼容需要在项目的manifest文件下增加

<uses-sdk android:minSdkVersion="9" />

2.因为cocos2dx现阶段使用的是opengles2.0所以要设置

<uses-feature android:glEsVersion="0x00020000" />

3.下载的ndk中有相关的说明文档在 <ndk>/docs/ directory 下，需要阅读 OVERVIEW.HTML 的文档

4.ndk的目的及实现java 与 c/c++之间的互调

5.开发工具(相关的c/c++编译器，和其他)，以及系统头文件的本地调用API：

libc (C library) headers
libm (math library) headers
JNI interface headers
libz (Zlib compression) headers
liblog (Android logging) header
OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
libjnigraphics (Pixel buffer access) header (for Android 2.2 and above).
A Minimal set of headers for C++ support
OpenSL ES native audio libraries
Android native application APIS

---------------------------------------------------------------------------------------------------------------------------------------------------------华丽的分界线-

看一看下载的ndk里面根目录的说明文档： documentation.html 可以知道大概的编译jni的流程（example）：

Your application's source code will declare one or more methods with the 'native' keyword to indicate that they are implemented through native code. E.g.:
```
  native byte[]  loadFile(String  filePath);
```
You must provide a native shared library that contains the implementation of these methods, which will be packaged into your application's .apk. This library must be named according to standard Unix conventions as lib.so, and shall contain a standard JNI entry point (more on this later). For example:
```
  libFileLoader.so
```
Your application must explicitly load the library. For example, to load it at application start-up, simply add the following to its source code:
```
  static {
    System.loadLibrary("FileLoader");
  }
```

编译链接c++的重点是写mk文件：

1. Android.mk的编写：具体参照ndk安装目录下的文档 Android.mk File

The file syntax is designed to allow you to group your sources into 'modules'. A module is one of the following:
- A static library. --静态库
- A shared library. --动态库
- A standalone executable.

You can define one or more modules in each Android.mk file, and you can use the same source file in several modules.

The build system handles many details for you. For example, you don't need to list header files or explicit dependencies between generated files in your Android.mk. The NDK build system will compute these automatically for you.

Note that the syntax is very close to the one used in Android.mk files distributed with the full open-source Android platform sources. While the build system implementation that uses them is different, this is an intentional design decision made to allow reuse of 'external' libraries' source code easier for application developers.

一个mk例子(ndk的hellojni示例)的说明：

    ---------- cut here ------------------
    LOCAL_PATH := $(call my-dir)

    include $(CLEAR_VARS)

    LOCAL_MODULE    := hello-jni
    LOCAL_SRC_FILES := hello-jni.c

    include $(BUILD_SHARED_LIBRARY)
    ---------- cut here ------------------

Now, let's explain these lines:

    LOCAL_PATH := $(call my-dir) --声明localpath(必须第一个对此进行声明)

An Android.mk file must begin with the definition of the LOCAL_PATH variable. It is used to locate source files in the development tree. In this example, the macro function 'my-dir', provided by the build system, is used to return the path of the current directory (i.e. the directory containing the Android.mk file itself).

    include $(CLEAR_VARS) --清除除localpath的所有变量

The CLEAR_VARS variable is provided by the build system and points to a special GNU Makefile that will clear many LOCAL_XXX variables for you (e.g. LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, etc...), with the exception of LOCAL_PATH. This is needed because all build control files are parsed in a single GNU Make execution context where all variables are global.

    LOCAL_MODULE := hello-jni --模块命名(每个模块必须声明)

The LOCAL_MODULE variable must be defined to identify each module you describe in your Android.mk. The name must be unique and not contain any spaces. Note that the build system will automatically add proper prefix and suffix to the corresponding generated file. In other words, a shared library module named 'foo' will generate 'libfoo.so'.

IMPORTANT NOTE: If you name your module 'libfoo', the build system will not add another 'lib' prefix and will generate libfoo.so as well. This is to support Android.mk files that originate from the Android platform sources, would you need to use these.

    LOCAL_SRC_FILES := hello-jni.c --设置编译的c/c++源码

The LOCAL_SRC_FILES variables must contain a list of C and/or C++ source files that will be built and assembled into a module. Note that you should not list header and included files here, because the build system will compute dependencies automatically for you; just list the source files that will be passed directly to a compiler, and you should be good.

Note that the default extension for C++ source files is '.cpp'. It is however possible to specify a different one by defining the variable LOCAL_CPP_EXTENSION. Don't forget the initial dot (i.e. '.cxx' will work, but not 'cxx').

    include $(BUILD_SHARED_LIBRARY) --将最近执行 CLEAR_VARS 到此的所有local变量内容信息编译成 sharedlib

The BUILD_SHARED_LIBRARY is a variable provided by the build system that points to a GNU Makefile script that is in charge of collecting all the information you defined in LOCAL_XXX variables since the latest 'include $(CLEAR_VARS)' and determine what to build, and how to do it exactly. There is also BUILD_STATIC_LIBRARY to generate a static library.

所有Android.mk命令的归类：

This is the list of variables you should either rely on or define in an Android.mk. You can define other variables for your own usage, but the NDK build system reserves the following variable names:

Names that begin with LOCAL_ (e.g. LOCAL_MODULE)
Names that begin with PRIVATE_, NDK_ or APP_ (used internally)
Lower-case names (used internally, e.g. my-dir)

接下来的reference还是需要在看例子用到的时候再进行查阅的，这就不必列出来了。

如果需要更深层次的学习用法可以多参考下ndk里面的例子吧，毕竟自己刚接触这些东西。

忘了还有一个 Application.mk 的文件描述(也是很重要的)：

Overview:

The purpose of Application.mk is to describe which native 'modules' (i.e. static/shared libraries) are needed by your application.

An Application.mk file is usually placed under $PROJECT/jni/Application.mk, where $PROJECT points to your application's project directory.

Another alternative is to place it under a sub-directory of the top-level $NDK/apps directory, e.g.:

      $NDK/apps/<myapp>/`Application.mk`

Where is a short name used to describe your 'application' to the NDK build system (this name doesn't go into your generated shared libraries or your final packages).

The Application.mk is really a tiny GNU Makefile fragment that must define a few variables:（详细的还是看文档吧，感觉还是很有用的，里面有很多平台之间的细节部分~）

另外关于编译环境的配置需要说一点：现在下的最新adt-bundle 已经将所有的东西都包含了，不需要配置任何东西，在接入ndk后将ndk放到任意目录即可，也不需要进行任何相关的配置，在加载Android NDK的sample后唯一需要做的就是为每一个使用了 jni 的工程添加相关的 ndk编译builder，大概如下：

右键项目选择properties , 再选择builders 再 new一个builder 相关配置如下图所示：