‘壹’ 如何使用android的ndk编译器 编译c++的库
1. 概述 首先回顾一下 Android NDK 开发中，Android.mk 和 Application.mk 各自的职责。 Android.mk，负责配置如下内容： （1） 模块名（LOCAL_MODULE） （2） 需要编译的源文件（LOCAL_SRC_FILES） （3） 依赖的第三方库（LOCAL_STATIC_LIBRARIES，LOCAL_SHARED_LIBRARIES） （4） 编译/链接选项（LOCAL_LDLIBS、LOCAL_CFLAGS） Application.mk，负责配置如下内容： （1） 目标平台的ABI类型（默认值：armeabi）（APP_ABI） （2） Toolchains（默认值：GCC 4.8） （3） C++标准库类型（默认值：system）（APP_STL） （4） release/debug模式（默认值：release） 由此我们可以看到，本文所涉及的编译选项在Android.mk和Application.mk中均有出现，下面我们将一个个详细介绍。 2. APP_ABI ABI全称是：Application binary interface，即：应用程序二进制接口，它定义了一套规则，允许编译好的二进制目标代码在所有兼容该ABI的操作系统和硬件平台中无需改动就能运行。（具体的定义请参考 网络 或者 维基网络 ） 由上述定义可以判断，ABI定义了规则，而具体的实现则是由编译器、CPU、操作系统共同来完成的。不同的CPU芯片（如：ARM、Intel x86、MIPS）支持不同的ABI架构，常见的ABI类型包括：armeabi，armeabi-v7a，x86，x86_64，mips，mips64，arm64-v8a等。 这就是为什么我们编译出来的可以运行于Windows的二进制程序不能运行于Mac OS/linux/Android平台了，因为CPU芯片和操作系统均不相同，支持的ABI类型也不一样，因此无法识别对方的二进制程序。 而我们所说的“交叉编译”的核心原理也跟这些密切相关，交叉编译，就是使用交叉编译工具，在一个平台上编译生成另一个平台上的二进制可执行程序，为什么可以做到？因为交叉编译工具实现了另一个平台所定义的ABI规则。我们在Windows/Linux平台使用Android NDK交叉编译工具来编译出Android平台的库也是这个道理。 这里给出最新 Android NDK 所支持的ABI类型及区别： 那么，如何指定ABI类型呢？在 Application.mk 文件中添加一行即可： APP_ABI := armeabi-v7a //只编译armeabi-v7a版本 APP_ABI := armeabi armeabi-v7a //同时编译armeabi，armeabi-v7a版本 APP_ABI := all //编译所有版本 3. LOCAL_LDLIBS Android NDK 除了提供了Bionic libc库，还提供了一些其他的库，可以在 Android.mk 文件中通过如下方式添加依赖： LOCAL_LDLIBS := -lfoo 其中，如下几个库在 Android NDK 编译时就默认链接了，不需要额外添加在 LOCAL_LDLIBS 中： （1） Bionic libc库 （2） pthread库（-lpthread） （3） math（-lmath） （4） C++ support library (-lstdc++) 下面我列了一个表，给出了可以添加到“LOCAL_LDLIBS”中的不同版本的Android NDK所支持的库： 下面是我总结的一些常用的CFLAGS编译选项： （1）通用的编译选项 -O2 编译优化选项，一般选择O2，兼顾了优化程度与目标大小 -Wall 打开所有编译过程中的Warning -fPIC 编译位置无关的代码，一般用于编译动态库 -shared 编译动态库 -fopenmp 打开多核并行计算， -Idir 配置头文件搜索路径，如果有多个-I选项，则路径的搜索先后顺序是从左到右的，即在前面的路径会被选搜索 -nostdinc 该选项指示不要标准路径下的搜索头文件，而只搜索-I选项指定的路径和当前路径。 --sysroot=dir 用dir作为头文件和库文件的逻辑根目录，例如，正常情况下，如果编译器在/usr/include搜索头文件，在/usr/lib下搜索库文件，它将用dir/usr/include和dir/usr/lib替代原来的相应路径。 -llibrary 查找名为library的库进行链接 -Ldir 增加-l选项指定的库文件的搜索路径，即编译器会到dir路径下搜索-l指定的库文件。 -nostdlib 该选项指示链接的时候不要使用标准路径下的库文件 （2） ARM平台相关的编译选项 -marm -mthumb 二选一，指定编译thumb指令集还是arm指令集 -march=name 指定特定的ARM架构，常用的包括：-march=armv6， -march=armv7-a -mfpu=name 给出目标平台的浮点运算处理器类型，常用的包括：-mfpu=neon，-mfpu=vfpv3-d16 -mfloat-abi=name 给出目标平台的浮点预算ABI，支持的参数包括：“soft”, “softfp” and “hard”
‘贰’ 安卓开发用什么编译器………
android studio以及eclipse
Android Studio 是一个Android开发环境，基于IntelliJ IDEA. 类似 Eclipse ADT，Android Studio 提供了集成的 Android 开发工具用于开发和调试。
而Eclipse 是一个开放源代码的、基于java的可扩展开发平台。就其本身而言，它只是一个框架和一组服务，用于通过插件组件构建开发环境。幸运的是，Eclipse 附带了一个标准的插件集，包括Java开发工具（Java Development Kit，JDK）。
‘叁’ 求一个好用的c++编译器，在android上运行，不要C4droid,最好放链接
gcc编译器，里面有gcc 和 g++，分别用于C和C++编译，文件位置在解压后的bin目录下，文件名为arm-linux-androidabi-g++。
使用两个程序需要使用终端模拟器，并且在root模式下将解压后的目录移动到手机内存中。
#su
#mv/storage/sdcard0/gcc/data/gcc
#cd/data/gcc/bin
#./arm-linux-androideabi-gccmain.c-omain
#./main
‘肆’ android系统编译能用分布式编译吗
项目越来越大，每次需要重新编译整个项目都是一件很浪费时间的事情。Research了一下，找到以下可以帮助提高速度的方法，总结一下。
1. 使用tmpfs来代替部分IO读写
2.ccache，可以将ccache的缓存文件设置在tmpfs上，但是这样的话，每次开机后，ccache的缓存文件会丢失
3.distcc,多机器编译
4.将屏幕输出打印到内存文件或者/dev/null中，避免终端设备（慢速设备）拖慢速度。
tmpfs
有人说在Windows下用了RAMDisk把一个项目编译时间从4.5小时减少到了5分钟，也许这个数字是有点夸张了，不过粗想想，把文件放到内存上做编译应该是比在磁盘上快多了吧，尤其如果编译器需要生成很多临时文件的话。
这个做法的实现成本最低，在Linux中，直接mount一个tmpfs就可以了。而且对所编译的工程没有任何要求，也不用改动编译环境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel来测试一下编译速度：
用物理磁盘：40分16秒
用tmpfs：39分56秒
呃……没什么变化。看来编译慢很大程度上瓶颈并不在IO上面。但对于一个实际项目来说，编译过程中可能还会有打包等IO密集的操作，所以只要可能，用tmpfs是有益无害的。当然对于大项目来说，你需要有足够的内存才能负担得起这个tmpfs的开销。
make -j
既然IO不是瓶颈，那CPU就应该是一个影响编译速度的重要因素了。
用make -j带一个参数，可以把项目在进行并行编译，比如在一台双核的机器上，完全可以用make -j4，让make最多允许4个编译命令同时执行，这样可以更有效的利用CPU资源。
还是用Kernel来测试：
用make： 40分16秒
用make -j4：23分16秒
用make -j8：22分59秒
由此看来，在多核CPU上，适当的进行并行编译还是可以明显提高编译速度的。但并行的任务不宜太多，一般是以CPU的核心数目的两倍为宜。
不过这个方案不是完全没有cost的，如果项目的Makefile不规范，没有正确的设置好依赖关系，并行编译的结果就是编译不能正常进行。如果依赖关系设置过于保守，则可能本身编译的可并行度就下降了，也不能取得最佳的效果。
ccache
ccache工作原理：
ccache也是一个编译器驱动器。第一趟编译时ccache缓存了GCC的“-E”输出、编译选项以及.o文件到$HOME/.ccache。第二次编译时尽量利用缓存，必要时更新缓存。所以即使"make clean; make"也能从中获得好处。ccache是经过仔细编写的，确保了与直接使用GCC获得完全相同的输出。
ccache用于把编译的中间结果进行缓存，以便在再次编译的时候可以节省时间。这对于玩Kernel来说实在是再好不过了，因为经常需要修改一些Kernel的代码，然后再重新编译，而这两次编译大部分东西可能都没有发生变化。对于平时开发项目来说，也是一样。为什么不是直接用make所支持的增量编译呢？还是因为现实中，因为Makefile的不规范，很可能这种“聪明”的方案根本不能正常工作，只有每次make clean再make才行。
安装完ccache后，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，链到/usr/bin/ccache上。总之确认系统在调用gcc等命令时会调用到ccache就可以了（通常情况下/usr/local /bin会在PATH中排在/usr/bin前面）。
安装的另外一种方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路径加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
这样每次启动g++的时候都会启动/usr/lib/ccache/bin/g++，而不会启动/usr/bin/g++
效果跟使用命令行ccache g++效果一样
这样每次用户登录时，使用g++编译器时会自动启动ccache
继续测试：
用ccache的第一次编译(make -j4)：23分38秒
用ccache的第二次编译(make -j4)：8分48秒
用ccache的第三次编译(修改若干配置，make -j4)：23分48秒
看来修改配置（我改了CPU类型...）对ccache的影响是很大的，因为基本头文件发生变化后，就导致所有缓存数据都无效了，必须重头来做。但如果只是修改一些.c文件的代码，ccache的效果还是相当明显的。而且使用ccache对项目没有特别的依赖，布署成本很低，这在日常工作中很实用。
可以用ccache -s来查看cache的使用和命中情况：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，显然只有第二编次译时cache命中了，cache miss是第一次和第三次编译带来的。两次cache占用了81.7M的磁盘，还是完全可以接受的。
distcc
一台机器的能力有限，可以联合多台电脑一起来编译。这在公司的日常开发中也是可行的，因为可能每个开发人员都有自己的开发编译环境，它们的编译器版本一般是一致的，公司的网络也通常具有较好的性能。这时就是distcc大显身手的时候了。
使用distcc，并不像想象中那样要求每台电脑都具有完全一致的环境，它只要求源代码可以用make -j并行编译，并且参与分布式编译的电脑系统中具有相同的编译器。因为它的原理只是把预处理好的源文件分发到多台计算机上，预处理、编译后的目标文件的链接和其它除编译以外的工作仍然是在发起编译的主控电脑上完成，所以只要求发起编译的那台机器具备一套完整的编译环境就可以了。
distcc安装后，可以启动一下它的服务：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默认的3632端口允许来自同一个网络的distcc连接。
然后设置一下DISTCC_HOSTS环境变量，设置可以参与编译的机器列表。通常localhost也参与编译，但如果可以参与编译的机器很多，则可以把localhost从这个列表中去掉，这样本机就完全只是进行预处理、分发和链接了，编译都在别的机器上完成。因为机器很多时，localhost的处理负担很重，所以它就不再“兼职”编译了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然后与ccache类似把g++，gcc等常用的命令链接到/usr/bin/distcc上就可以了。
在make的时候，也必须用-j参数，一般是参数可以用所有参用编译的计算机CPU内核总数的两倍做为并行的任务数。
同样测试一下：
一台双核计算机，make -j4：23分16秒
两台双核计算机，make -j4：16分40秒
两台双核计算机，make -j8：15分49秒
跟最开始用一台双核时的23分钟相比，还是快了不少的。如果有更多的计算机加入，也可以得到更好的效果。
在编译过程中可以用distccmon-text来查看编译任务的分配情况。distcc也可以与ccache同时使用，通过设置一个环境变量就可以做到，非常方便。
总结一下：
tmpfs： 解决IO瓶颈，充分利用本机内存资源
make -j： 充分利用本机计算资源
distcc： 利用多台计算机资源
ccache： 减少重复编译相同代码的时间
这些工具的好处都在于布署的成本相对较低，综合利用这些工具，就可以轻轻松松的节省相当可观的时间。上面介绍的都是这些工具最基本的用法，更多的用法可以参考它们各自的man page。
5.还有提速方法是把屏幕输出重定向到内存文件或/dev/null,因对终端设备(慢速设备)的阻塞写操作也会拖慢速度。推荐内存文件，这样发生错误时，能够查看。
‘伍’ 请问有android开发环境的cpp编译器吗
编译bootloader和Linux Kernel是采用的是独立的ARM交叉编译器，可以在 \10.4.69.249androidepoarm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 获得。编译Android根文件系统和SDK使用的是Android系统自带的交叉编译环境。
使用如下命令安装交叉编译器，建议安装在 /usr/local/ 目录下(需具有root权限)。
[root]$ cd /usr/local/
[root]$ tar xjvf /arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
将交叉编译器的路径添加到对应用户名的.bash_profile 文件中。
[root]$ cd
[root]$ vim .bash_profile
修改其中的PATH一行，在末尾增加交叉编译器的路径，例如：
PATH=$PATH:/usr/local/bin/arm-2008q3/bin
运行如下命令检查交叉编译器是否安装成功，得到如下结果表示安装已经成功。
[root]$ arm-none-linux-gnueabi-gcc ?version
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2008q3-72) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for ing conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
‘陆’ 求在安卓设备上运行的Android程序编译器，可以是可视化编程，最好编程语言是C ，编译器占用资源
如你所愿，终端模拟器，完全符合你的要求，不过我的手机是系统自带的，名称就叫终端模拟器，你可以网络搜搜下。
‘柒’ Android平台有可以的运行C++编译器吗
是这样，在pc上通过模拟器进行编程的
而android本身平台里面，没有运行的编译器之类的东西
‘捌’ arm-linux-androideabi 编译器版本是否和android version有关
api版本和android几点几是对应的，列出来一些 平台版本API Level Android 3.2 13 Android 3.1 12 Android 3.0 11 Android 2.3.3 10 Android 2.3 9 Android 2.2 8 Android 2.1 7 Android 2.0.1 6 Android 2.0 5 Android 1.6 4 Android 1.5 3 Andr...
‘玖’ android apk反编译软件哪个好用
Android反编译的目的无非就是为了看到APK的xml、资源和代码:
得到代码的方式：直接解压APK文件 --> 得到classes.dex文件 --> 使用 dex2jar
classes.dex classes.jar生成jar文件 --> [可选的解压jar文件]
-->使用XJad或者JDCompiler查看源代码
得到XML的方式：
方式1：直接解压APK文件 --> 通过axmlprinter工具查看XML文件(这种方式查看的XML文件的id都是数字--即R文件中id对应的值)
方式2：使用APKTool工具解压APK文件可以直接查看XML文件
Android反编译常常使用如下的一些工具：
1、反编译命令：
apktool d D:\\Developer\androidDecode\Test0201.apk D:\\Developer\androidDecode\test0201
D:\\Developer\androidDecode\Test0201.apk：要反编译的APK文件
D:\\Developer\androidDecode\test0201：反编译文件的保存目录，必须为空目录
2、从反编译的文件编译成APK apktool b D:\\Developer\androidDecode\test0201 D:\\Developer\androidDecode\test020101.apk
D:\\Developer\androidDecode\test0201:保存编译后文件的目录
D:\\Developer\androidDecode\test020101.apk：生成的新的APK文件的保存的绝对路径
3、签名APK文件：
singedAPK.bat文件
java -jar "%~dp0signapk.jar" "%~dp0testkey.x509.pem" "%~dp0testkey.pk8" %1 signed.apk
执行singedAPK.bat命令
singedAPK D:\\Developer\androidDecode\test020101.apk 生成一个singed.apk文件和test020101.apk在同一个目录
4、使用baksmali.jar把一个dex文件转换为一个smali文件
java -jar D:\\Developer\ApkTool\baksmali.jar -o
D:\\Developer\androidDecode\baksmaliout
D:\\Developer\androidDecode\Hello.dex
D:\\Developer\ApkTool\baksmali.jar：baksmali.jar文件所存在的全路径
D:\\Developer\androidDecode\baksmaliout：生成的smali文件的保存目录
D:\\Developer\androidDecode\Hello.dex：要转成smali文件的路径
5、使用ddx.jar把一个dex文件转换为ddx文件
java -jar D:\\Developer\ApkTool\ddx.jar -d D:\\Developer\androidDecode\ddxout D:\\Developer\androidDecode\Hello.dex
D:\\Developer\ApkTool\ddx.jar：ddx.jar文件的绝对路径
D:\\Developer\androidDecode\ddxout:要保存ddx文件的路径
D:\\Developer\androidDecode\Hello.dex：要转换的dex路径
6、Android自带dexmp工具：dex文件转为smali文件 dexmp -d xxxx.dex > xxxx.smali
7、dex2jar.jar:dex2jar XXX.dex YYY.jar