编译器android,编译器和解释器之间的区别是什么

新人求教，编译一个最简单的Android程序，提示下面的错误咋解决

注意以下事项：

成都创新互联是一家专注于网站设计、成都网站制作与策划设计,沈北新网站建设哪家好?成都创新互联做网站,专注于网站建设十余年,网设计领域的专业建站公司;建站业务涵盖:沈北新等地区。沈北新做网站价格咨询:18982081108

1、32位系统下的编译

如果需要在32位系统中编译android系统，在编译前需要对部分makefile进行修改

首先修改build/core/main.mk，修改的内容如下所示：

-ifneq (64,$(findstring 64,$(build_arch)))

+ifneq

(i686,$(findstring i686,$(build_arch)))

$(warning

************************************************************) $(warning You are attempting to build on a 32-bit system.)

$(warning Only 64-bit build environments are supported beyond froyo/2.2.)

其次修改如下四个文件：

external/clearsilver/cgi/Android.mk

external/clearsilver/java-jni/Android.mk

external/clearsilver/util/Android.mk

external/clearsilver/cs/Android.mk # This forces a 64-bit build for Java6

-LOCAL_CFLAGS += -m64

-LOCAL_LDFLAGS += -m64

+LOCAL_CFLAGS += -m32

+LOCAL_LDFLAGS += -m32即将LOCAL_CFLAGS和LOCAL_LDFLAGS由-m64改为-m32，从而指定使用32位系统进行编译如果使用 64bit 的操作系统编译，这些就都不用修改，但记得需要安装：For 64-bit servers the following extra packages may be needed:

"sudo apt-get install libc6-dev-i386" (libc6-dev-amd64 if AMD CPU)

"sudo apt-get install g++-multilib lib32ncurses5-dev lib32z1-dev"

还有 jdk64bit 的版本编译2 、build/core/base_rules.mk:128:*** frameworks/opt/emoji/jni:

.... libgl2jni already defined by framwworks/base/opengl/tests/gl2_jni/jni 停止

从编译规则上看：

# Make sure that this IS_HOST/CLASS/MODULE combination is unique.

module_id := MODULE.$(if \

$(LOCAL_IS_HOST_MODULE),HOST,TARGET).$(LOCAL_MODULE_CLASS).$(LOCAL_MODULE)

ifdef $(module_id)

$(error $(LOCAL_PATH): $(module_id) already defined by $($(module_id)))

endif

在framwworks/base/opengl/tests/gl2_jni/下面定义的android.mk定义了：

LOCAL_MODULE := libgl2jni

include $(BUILD_SHARED_LIBRARY)

导致生成的动态库重复，这是不对的，修改tests这个目录不参与编译即可，最直接的办法删除掉framwworks/base/opengl/tests/gl2_jni这个文件夹

3、AIDL 编译报couldn't find import for class原因

“AIDL服务只支持有限的数据类型，因此，如果用AIDL服 务传递一些复杂的数据就需要做更一步处理。AIDL服务支持的数据类型如下：

Java的简单类 型（int、char、boolean等）。不需要导入（import）。String和 CharSequence。不需要导入（import）。

List和 Map。但要注意，List和Map对象的元素类型必须是AIDL服务支持的数据类型。不需要导入（import）。AIDL自动生成 的接口。需要导入（import）。

实现 android.os.Parcelable接口的类。需要导入（import）。

其中后两种数据类 型需要使用import进行导入，传递不需要 import的数据类型的值的方式相同。传递一个需要import的数据类型的值（例如，实现android.os.Parcelable 接口的类）的步 骤略显复杂。除了要建立一个实现android.os.Parcelable接口的类外，还需要为这个类单独建立一个aidl文件，并使用parcelable关键字进行定义。”

没有加LOCAL_AIDL_INCLUDES += xxx ，所以找不到我的parcelable aidl文件。

修改android源码根目录下的build/core/pathmap.mk把你的目录加进去,此时再make update-api

4、老是提示 @Override错误 方法未覆盖其父类的方法

使 用JDK1.6编译没有问题，使用JDK1.5编译，会报@Override方法未覆盖其父类的方法。实际上这个方法是类实现的接口中方法，

但是，这个语 法的jdk1.6的下面是可以通过的，也就是说jdk1.6认为类覆盖父类方法与实现接口方法都叫override，而jdk1.5不

是这样认为的，不知 道这是当初jdk1.5的bug，还是当初就是认为覆盖父类方法与实现接口方法是不一样的，不得而知。但是从

OO角度来看，覆盖父类方法与实现接口方法都 可以认为override，因为他们目的都是一样的，都是为了重用，都是多态的一种

表现方式。

更改jdk版本为1.6即可

5、编译alsa-lib库错误

android系统开发移植alsa-lib库的过程中编译的时候出现了如下的错误

/tmp/cckyaR40.s: Assembler messages:

/tmp/cckyaR40.s:2763: Error: selected processor does not support `mrs ip,cpsr'

/tmp/cckyaR40.s:2764: Error: unshifted register required -- `orr r2,ip,#128'

/tmp/cckyaR40.s:2765: Error: selected processor does not support `msr cpsr_c,r2

字面的意思报的是汇编错误，选择的处理器不支持mrs和msr指令。

原来的ARM指令有32位和16位两种指令模式，16位为thumb指令集，thumb指令集编译出的代码占用空间小，

而且效率也高，所以android的arm编译器默认用的是thumb模式编译，问题在于alsa的代码中有部分的内容

用到了32位的指令，所以才会报如下的错误，修改的方法也很简单，在Android.mk中加入如下内容即可：

LOCAL_ARM_MODE := arm

android的编译系统中LOCAL_ARM_MODE变量的取值为arm或者thumb，代表32位和16位两种arm指令集，默认为thumb

prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: failed to set dynamic section sizes: Bad value

collect2: ld returned 1 exit status

make: *** [out/target/product/merlin/obj/SHARED_LIBRARIES/libasound_intermediates/LINKED/libasound.so] 错误 1

解决此问题将alsa-lib/include/config.h文件中的如下宏定义去掉即可：

#define VERSIONED_SYMBOLS

开发过程中碰到过很多错误，后续再一一总结记录下来，有些忘记了。。

在android.mk中编译：

include $(CLEAR_VARS)

$(call add-prebuilt-files, STATIC_LIBRARIES, libyfcdca.a)

出现提示需要定义：LOCAL_MODULE_TAGS := optional 一般修改方法是：

build\core\definitions.mk 中的宏定义变量：

define include-prebuilt

include $$(CLEAR_VARS)

LOCAL_SRC_FILES := $(1)

LOCAL_BUILT_MODULE_STEM := $(1)

LOCAL_MODULE_SUFFIX := $$(suffix $(1))

LOCAL_MODULE := $$(basename $(1))

LOCAL_MODULE_CLASS := $(2)

include $$(BUILD_PREBUILT)

endef

在这里增加一个LOCAL_MODULE_TAGS := optional

但是这需要修改android源码，如果不是自已的android系统，这么做就麻烦了，所以必须想其它办法解决：

#include $(CLEAR_VARS)

#$(call add-prebuilt-files, STATIC_LIBRARIES, libyfcdca.a)

include $(CLEAR_VARS)

LOCAL_SRC_FILES := libyfcdca.a

LOCAL_BUILT_MODULE_STEM := libyfcdca.a

LOCAL_MODULE_SUFFIX := lib

LOCAL_MODULE := yfcdca

LOCAL_MODULE_CLASS := STATIC_LIBRARIES

LOCAL_MODULE_TAGS := optional

include $(BUILD_PREBUILT)

如此即可了。

如何让编译器架构Android.mk动态

Android.mk文件用来告知NDK Build 系统关于Source的信息。 Android.mk将是GNU Makefile的一部分，且将被Build System解析一次或多次。

所以，请尽量少的在Android.mk中声明变量，也不要假定任何东西不会在解析过程中定义。

Android.mk文件语法允许我们将Source打包成一个"modules". modules可以是：

静态库

动态库。

只有动态库可以被 install/copy到应用程序包(APK). 静态库则可以被链接入动态库。

可以在一个Android.mk中定义一个或多个modules. 也可以将同一份source 加进多个modules.

Build System帮我们处理了很多细节而不需要我们再关心。例如：你不需要在Android.mk中列出头文件和外部依赖文件。

NDK Build System自动帮我们提供这些信息。这也意味着，当用户升级NDK后，你将可以受益于新的toolchain/platform而不必再去修改Android.mk.

1. Android.mk语法：

首先看一个最简单的Android.mk的例子：

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := hello-jni

LOCAL_SRC_FILES := hello-jni.c

include $(BUILD_SHARED_LIBRARY)

讲解如下：

LOCAL_PATH := $(call my-dir)

每个Android.mk文件必须以定义LOCAL_PATH为开始。它用于在开发tree中查找源文件。

宏my-dir则由Build System提供。返回包含Android.mk的目录路径。

include $(CLEAR_VARS)

CLEAR_VARS 变量由Build System提供。并指向一个指定的GNU Makefile，由它负责清理很多LOCAL_xxx.

例如：LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES等等。但不清理LOCAL_PATH.

这个清理动作是必须的，因为所有的编译控制文件由同一个GNU Make解析和执行，其变量是全局的。所以清理后才能避免相互影响。

LOCAL_MODULE := hello-jni

LOCAL_MODULE模块必须定义，以表示Android.mk中的每一个模块。名字必须唯一且不包含空格。

Build System会自动添加适当的前缀和后缀。例如，foo，要产生动态库，则生成libfoo.so. 但请注意：如果模块名被定为：libfoo.则生成libfoo.so. 不再加前缀。

LOCAL_SRC_FILES := hello-jni.c

LOCAL_SRC_FILES变量必须包含将要打包如模块的C/C++ 源码。

不必列出头文件，build System 会自动帮我们找出依赖文件。

缺省的C++源码的扩展名为.cpp. 也可以修改，通过LOCAL_CPP_EXTENSION。

include $(BUILD_SHARED_LIBRARY)

BUILD_SHARED_LIBRARY：是Build System提供的一个变量，指向一个GNU Makefile Script。

它负责收集自从上次调用 include $(CLEAR_VARS) 后的所有LOCAL_XXX信息。并决定编译为什么。

BUILD_STATIC_LIBRARY：编译为静态库。

BUILD_SHARED_LIBRARY ：编译为动态库

BUILD_EXECUTABLE：编译为Native C可执行程序

2. NDK Build System变量：

NDK Build System 保留以下变量名：

以LOCAL_ 为开头的

以PRIVATE_ ,NDK_ 或者APP_ 开头的名字。

小写字母名字：如my-dir

如果想要定义自己在Android.mk中使用的变量名，建议添加 MY＿　前缀。

2.1: NDK提供的变量：

此类GNU Make变量是NDK Build System在解析Android.mk之前就定义好了的。

2.1.1：CLEAR_VARS：

指向一个编译脚本。必须在新模块前包含之。

include $(CLEAR_VARS)

2.1.2：BUILD_SHARED_LIBRARY：

指向一个编译脚本，它收集自从上次调用 include $(CLEAR_VARS) 后的所有LOCAL_XXX信息。

并决定如何将你列出的Source编译成一个动态库。 注意，在包含此文件前，至少应该包含：LOCAL_MODULE and LOCAL_SRC_FILES 例如：

include $(BUILD_SHARED_LIBRARY)

2.1.3：BUILD_STATIC_LIBRARY：

与前面类似，它也指向一个编译脚本，

收集自从上次调用 include $(CLEAR_VARS) 后的所有LOCAL_XXX信息。

并决定如何将你列出的Source编译成一个静态库。 静态库不能够加入到Project 或者APK中。但它可以用来生成动态库。

LOCAL_STATIC_LIBRARIES and LOCAL_WHOLE_STATIC_LIBRARIES将描述之。

include $(BUILD_STATIC_LIBRARY)

2.1.4: BUILD_EXECUTABLE:

与前面类似，它也指向一个编译脚本，收集自从上次调用 include $(CLEAR_VARS) 后的所有LOCAL_XXX信息。

并决定如何将你列出的Source编译成一个可执行Native程序。 include $(BUILD_EXECUTABLE)

2.1.5：PREBUILT_SHARED_LIBRARY：

把这个共享库声明为 “一个” 独立的模块。

指向一个build 脚本，用来指定一个预先编译好多动态库。 与BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY不同，

此时模块的LOCAL_SRC_FILES应该被指定为一个预先编译好的动态库，而非source file. LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := foo-prebuilt # 模块名

LOCAL_SRC_FILES := libfoo.so # 模块的文件路径（相对于 LOCAL_PATH）

include $(PREBUILT_SHARED_LIBRARY) # 注意这里不是 BUILD_SHARED_LIBRARY

这个共享库将被拷贝到 $PROJECT/obj/local 和 $PROJECT/libs/abi (stripped) 主要是用在将已经编译好的第三方库

使用在本Android Project中。为什么不直接将其COPY到libs/armabi目录呢？因为这样做缺陷很多。下一节再详细说明。

2.1.6: PREBUILT_STATIC_LIBRARY:预先编译的静态库。 同上。

2.1.7: TARGET_ARCH: 目标CPU架构名。如果为　“arm” 则声称ARM兼容的指令。与CPU架构版本无关。

2.1.8: TARGET_PLATFORM: 目标的名字。

2.1.9：TARGET_ARCH_ABI

Name of the target CPU+ABI

armeabi For ARMv5TE armeabi-v7a

2.1.10：TARGET_ABI

2.2: NDK提供的功能宏：

GNU　Make 提供的功能宏，只有通过类似： $(call function) 的方式来得到其值，它将返回文本化的信息。

2.2.1: my-dir: $(call my-dir):

返回最近一次include的Makefile的路径。通常返回Android.mk所在的路径。它用来作为Android.mk的开头来定义LOCAL_PATH. LOCAL_PATH := $(call my-dir)

请注意：返回的是最近一次include的Makefile的路径。所以在Include其它Makefile后，再调用$(call my-dir)会返回其它Android.mk 所在路径。 例如：

LOCAL_PATH := $(call my-dir) declare one module include $(LOCAL_PATH)/foo/Android.mk LOCAL_PATH := $(call my-dir) declare another module

则第二次返回的LOCAL_PATH　为：$PATH/foo。 而非$PATH.

2.2.2: all-subdir-makefiles:

返回一个列表，包含'my-dir'中所有子目录中的Android.mk。

例如： 结构如下： sources/foo/Android.mk sources/foo/lib1/Android.mk sources/foo/lib2/Android.mk

在If sources/foo/Android.mk 中， include $(call all-subdir-makefiles) 那则自动include 了sources/foo/lib1/Android.mk and sources/foo/lib2/Android.mk。

2.2.3：this-makefile：

当前Makefile的路径。

2.2.4：parent-makefile：

返回include tree中父Makefile 路径。 也就是include 当前Makefile的Makefile Path。

2.2.5：import-module：

允许寻找并inport其它modules到本Android.mk中来。 它会从NDK_MODULE_PATH寻找指定的模块名。 $(call import-module,name)

2.3: 模块描述变量：

此类变量用来给Build System描述模块信息。在'include $(CLEAR_VARS)' 和 'include $(BUILD_XXXXX)'之间。必须定义此类变量。 include $(CLEAR_VARS) script用来清空这些变量。

include $(BUILD_XXXXX)收集和使用这些变量。

2.3.1: LOCAL_PATH:

这个值用来给定当前目录。必须在Android.mk的开是位置定义之。

例如： LOCAL_PATH := $(call my-dir) LOCAL_PATH不会被include $(CLEAR_VARS) 清理。

2.3.2: LOCAL_MODULE:

modules名。在include $(BUILD_XXXXX)之前，必须定义这个变量。此变量必须唯一且不能有空格。

通常，由此变量名决定最终生成的目标文件名。

2.3.3: LOCAL_MODULE_FILENAME:

可选。用来override LOCAL_MODULE. 即允许用户重新定义最终生成的目标文件名。 LOCAL_MODULE := foo-version-1 LOCAL_MODULE_FILENAME := libfoo

2.3.4：LOCAL_SRC_FILES：

为Build Modules而提供的Source 文件列表。不需要列出依赖文件。 注意：文件相对于LOCAL_PATH存放，

且可以提供相对路径。 例如： LOCAL_SRC_FILES := foo.c \ toto/bar.c

2.3.5: LOCAL_CPP_EXTENSION:

指出C++ 扩展名。(可选) LOCAL_CPP_EXTENSION := .cxx 从NDK R7后，可以写多个：

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

2.3.6：LOCAL_CPP_FEATURES：

可选。用来指定C++ features。 LOCAL_CPP_FEATURES := rtti

LOCAL_CPP_FEATURES := exceptions

2.3.7：LOCAL_C_INCLUDES：

一个可选的path列表。相对于NDK ROOT 目录。编译时，将会把这些目录附上。 LOCAL_C_INCLUDES := sources/foo LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo

2.3.8: LOCAL_CFLAGS:

一个可选的设置，在编译C/C++ source 时添加如Flags。

用来附加编译选项。 注意：不要尝试在此处修改编译的优化选项和Debug等级。它会通过您Application.mk中的信息自动指定。

也可以指定include 目录通过：LOCAL_CFLAGS += -Ipath。 这个方法比使用LOCAL_C_INCLUDES要好。因为这样也可以被ndk-debug使用。

2.3.9: LOCAL_CXXFLAGS: LOCAL_CPPFLAGS的别名。

2.3.10: LOCAL_CPPFLAGS:

C++ Source 编译时添加的C Flags。这些Flags将出现在LOCAL_CFLAGS flags 的后面。

2.3.11: LOCAL_STATIC_LIBRARIES:

要链接到本模块的静态库list。(built with BUILD_STATIC_LIBRARY)

2.3.12: LOCAL_SHARED_LIBRARIES:

要链接到本模块的动态库。

2.3.13：LOCAL_WHOLE_STATIC_LIBRARIES：

静态库全链接。 不同于LOCAL_STATIC_LIBRARIES，类似于使用--whole-archive

2.3.14：LOCAL_LDLIBS：

linker flags。 可以用它来添加系统库。 如 -lz: LOCAL_LDLIBS := -lz

2.3.15: LOCAL_ALLOW_UNDEFINED_SYMBOLS:

2.3.16: LOCAL_ARM_MODE:

缺省模式下，ARM目标代码被编译为thumb模式。每个指令16位。如果指定此变量为：arm。 则指令为32位。 LOCAL_ARM_MODE := arm 其实也可以指定某一个或者某几个文件的ARM指令模式。

2.3.17: LOCAL_ARM_NEON:

设置为true时，会讲浮点编译成neon指令。这会极大地加快浮点运算(前提是硬件支持)

只有targeting 为 'armeabi-v7a'时才可以。

2.3.18：LOCAL_DISABLE_NO_EXECUTE：

2.3.19: LOCAL_EXPORT_CFLAGS:

定义这个变量用来记录C/C++编译器标志集合，

并且会被添加到其他任何以LOCAL_STATIC_LIBRARIES和LOCAL_SHARED_LIBRARIES的模块的LOCAL_CFLAGS定义中 LOCAL_SRC_FILES := foo.c bar.c.arm

注意：此处NDK版本为NDK R7C.（不同NDK版本，ndk-build所产生的Makefile并不完全相同）

如何使用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编译慢、卡死和狂占内存怎么破？

在2020年，仍然使用2g内存的电脑，你可以改变职业。没有合适的设备，什么都没用。Android Studio是内存，设备烂卡死不可避免，要解决卡的问题，一定要升级硬件设备。另一些人则说，对修辞学的回答相当有力，在一定程度上，加快编译的速度，却不能解决卡死的问题，没有人能解释为什么会加快编译的速度。

至于加快编译，有一种方法，我认为一些主要适用性的答案并不强，实际上应该从gradle开始，什么不是正确的地方，也请轻喷，有什么问题可以留个信息。

我谈到了下面的所有步骤，建议在最后进行。在终端编译中有很多好处:

能观察整个编译过程，帮助理解层次构建过程;

可以看出哪些任务在编译过程中耗费时间，可以较慢地编写出适合的补救方案;

可以终止编译，如果在某个阶段被卡住，CTRL + c终止编译，Android也会终止在Studio中编译，但基本上九次会失败;

因为它最终会对Android Studio产生影响，基本不会导致Android Studio caton;不满足Android工作室的各种bug ?

让我们从gradle的生命周期开始。Gradle构建了一个被分成三个部分的项目(完成如下图，整个Gradle构建过程可以理解为10到8):

初始化阶段:主要是分析设置。Gradle文件(减少设置。所以有人提到了模块级的数量是合理的，但实际操作过程的限制，因为最终可以粗略的说);

读取配置阶段:主要解析构建下的所有项目。Gradle文件，包括rootProject和其他子项目(组件)，检查语法，确定任务依赖于创建任务必须没有循环图，任务文件目录中的引用存在，等等(这一步进一步验证也减少了设置。gradle中模块的数量可以加快编译速度，因为减少了一个模块，需要解析构建。gradle文件将会减少a，在步骤3中不会执行这属于模块的任务，但仍然说1个问题，限制了很多);

执行阶段:根据2所建立的，必须没有循环图来执行每一个任务，编译过程，这一步将会占用超过9个基本时间，特别是对于Android项目，一个Java的类。

CompileDebugJavaWithJavac / compileReleaseJavaWithJavac和类合并成敏捷

TransformClassesWithDexForDebug / transformClassesWithDexForRelease

这两个步骤是耗时的，第一步是可以的，第二步需要很长时间。在gradle.properties第一组。

Gradle。Jvmargs = -xmx4096m //越大越好，然后在构建的android节点下添加dexOptions配置。项目等级如下:

DexOptions {dexInProcess truepredexlibrary真正的javaMaxHeapSize增量true}“4g”//越大越好。

当您定义gradle的生命周期时，您可以看到加速编译的关键是从步骤3开始，并减少设置中模块的数量。让我们谈谈我们公司的做法吧。

项目插件改革，每个业务学生你只需要编译一个模块，这基本上就从根本上解决了编译慢的问题(我的大多数朋友没有插件规范可以看到下面的一些做法)，第一个设置。该模块仅在gradle自己的开发模块中，而任务的对应阶段只是这个任务的一个模块。

执行gradle构建,我们会发现,在这个过程中,实际上是执行的任务多次包装,在buildTypes配置了多个编译包类型,默认的调试和发布,我们也可以手动配置其他类型,而且在productFlavor多渠道,编译这将执行多个包装、正常发育过程中,只需要把调试调试,所以使用gradle assembleDebug可以,等待释放使用其他方法来玩多渠道包(如美丽的计划,)。

因为编译器是主要集中在第三步的时间gradle生命周期执行任务,然后我们可以给残疾人一些不重要的任务,如各种各样的测试,各种线头等等,只有这样的指令gradle - x线头可以暂时禁止线头,禁止- x测试可以测试任务,事实上,对于一个略大的项目线头也是很耗费时间的,,当然,也可以通过gradle脚本完全禁用线头和测试任务,我也分享代码在一个小信集团,但不建议这样做,因为有时可能非常有用的棉絮和测试;

Gradle本身可以加快编译的速度，提供一些指令参数，例如，守护进程，打开一个守护进程，——并行的、打开的并行编译等等，这也可以在Gradle中完成。propertites配置(使用JVM内存进行编译也可以在这里配置)。

定制级编译过程，使用官方API可以完全定制一个合适的编译过程，可以参考ctrip DynamicAPK/sub - project - build。在master CtripMobile/DynamicAPK lot中，有ctrip本身是一个完整的编译过程，脚本本身非常简单，总共只有两行代码。

如上所述，现有的环境可以通过这种方式进行(如果项目中存在交叉依赖，则使用一个特殊的注释，不要使用并行参数):

如果要直接安装在设备上，则可以用installDebug替换安装调试，并且可以缩写为asD，安装调试可以缩写为iD

最后，为什么要减少设置中模块的数量。Gradle实际上可以加速编译，但是有很多限制?

首先,我们认为编译过程,首先解析gradle配置,设置任务依赖于有向图,然后执行每个任务的模块,如果我们通过maven的依赖关系,使用模块的aar(单android库),如果我们想要改变文件在这个模块,不要再次修改上传下载,每次都是很好,但是有一个致命的问题:不修改版本号,快照通常不是做的想法。这可能导致一些不会生效的变化，并且需要时间来解决这个问题。但是，有一种方法可以在一定程度上解决这个问题，并添加以下脚本:

项目。配置。所有(新操作配置 ({@ Overridevoidexecute(配置文件){文件)。ResolutionStrategy。TimeUnit CacheDynamicVersionsFor(5。分钟)

文件。ResolutionStrategy。TimeUnit CacheChangingModulesFor(0。秒)} })

有人会问，插件，每个人都要开发一个模块，对于每个模块的维护都要打包到maven，每次我修改，甚至很小的改动，也要做一个上传，就会遇到快照不做同样的问题。嘿，嘿，这个问题，我们公司有一个等级插件，已经解决了，至于解决方案，是公司机密，我不会说。

一件事,我相信大多数开发人员共同发展是单一模块,该模块的情况并不多,所以最基本的也是依赖aar或罐子里,并不存在所谓的图书馆aar上传,所以一些答案的耶和华说并不意味着什么,这就是为什么我说影响编译速度的情况主要集中在它的生命周期的第三阶段,第三阶段的优化,看到我的答案。

如何使用华为方舟编译器

1、使用华为方舟编译器只需要在手机上安装应用程序即可全速运行程序，从而带来效率上的极大提升。使用华为方舟编译器，可以提升系统操作流畅度的24%，并且系统响应性能也能提升44%。

2、华为方舟编译器是华为公司为了提升Android系统的编译效率推出的一项系统及应用的编译和运行机制。

3、方舟编译器是基于GCC开发的交叉编译器套件，它包括了C、C++、Fortran的前端，也包括了这些语言的库（如libstdc++、libgcc等）。HCC运行在X86linux架构服务器上，生成的二进制运行在Aarch64架构服务器上。

4、2019年4月，在华为P30系列国内发布会上，华为首次宣布了该技术。8月31日，方舟编译器开源。

更多关于如何使用华为方舟编译器，进入：查看更多内容

一般开发安卓软件用的Java语言吗 需要使用哪种编译器？

一般开发安卓软件用的是Java语言，需要使用安卓官方推荐使用的编译器Android Studio，简称as。