编译优化架构

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

Android.mk文件用来告知NDK Build 系统关于Source的信息。 Android.mk将是GNU Makefile的一部分，且将被Build System解析一次或多次。
所以，请尽量少的在Android.mk中声明变量，也不要假定任何东西不会在解析过程中定义。

Android.mk文件语法允许我们将Source打包成一个"moles". moles可以是：
静态库
动态库。

只有动态库可以被 install/到应用程序包(APK). 静态库则可以被链接入动态库。
可以在一个Android.mk中定义一个或多个moles. 也可以将同一份source 加进多个moles.

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提供的功能宏：
GNUMake 提供的功能宏，只有通过类似： $(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 mole include $(LOCAL_PATH)/foo/Android.mk LOCAL_PATH := $(call my-dir) declare another mole
则第二次返回的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-mole：
允许寻找并inport其它moles到本Android.mk中来。 它会从NDK_MODULE_PATH寻找指定的模块名。 $(call import-mole,<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:
moles名。在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 Moles而提供的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 += -I<path>。 这个方法比使用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并不完全相同）

⑵ 编译器采用什么软件体系结构风格

软件架构:整个软件系统的各个模块之间的结构设计，是软件工程范畴的概念，就象设计一栋房子由几个什么样的板块组成一样。
软件体系结构:是软件编程风格范畴的一个通俗概念，比如说用C++、PoworBuild、Delphi等来进行软件设计是面向对象的编程语言体系结构，而Basic、C、Foxbase的软件体系结构特点是面向任务流程的(不是面向对象的编程语言)。

⑶ 如何加快xcode编译速度

1. 增加XCode执行的线程数
可以根据自己Mac的性能，更改线程数设置5：defaults write com.apple.Xcode 5
另外也有一个设置可以开启：defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES
XCode默认使用与CPU核数相同的线程来进行编译，但由于编译过程中的IO操作往往比CPU运算要多，因此适当的提升线程数可以在一定程度上加快编译速度。
2.将Debug Information Format改为DWARF
在工程对应Target的Build Settings中，找到Debug Information Format这一项，将Debug时的DWARF with dSYM file改为DWARF。
这一项设置的是是否将调试信息加入到可执行文件中，改为DWARF后，如果程序崩溃，将无法输出崩溃位置对应的函数堆栈，但由于Debug模式下可以在XCode中查看调试信息，所以改为DWARF影响并不大。这一项更改完之后，可以大幅提升编译速度。
比如在目前本人负责的项目中，由于依赖了多个Target，所以需要在每个Target的Debug Information Format设置为DWARF。顺便提一下，如果通过Cocoapod引入第三方则Debug Information Format默认就是设置为DWARF的。
SDWebImage通过Cocoapod``Debug Information Format的默认设置
注意：将Debug Information Format改为DWARF之后，会导致在Debug窗口无法查看相关类类型的成员变量的值。当需要查看这些值时，可以将Debug Information Format改回DWARF with dSYM file，clean（必须）之后重新编译即可。
3.将Build Active Architecture Only改为Yes
在工程对应Target的Build Settings中，找到Build Active Architecture Only这一项，将Debug时的NO改为Yes。
664334-fa1eb995c140ce0f.png
这一项设置的是是否仅编译当前架构的版本，如果为NO，会编译所有架构的版本。需要注意的是，此选项在Release模式下必须为NO`，否则发布的ipa在部分设备上将不能运行。这一项更改完之后，可以显着提高编译速度。
4.设计编译优化等级
不要再项目中或者静态库中使用-O4，因为这会让Clang链接Link Time Optimizations (LTO)使得编译更慢，通常使用-O3。
注意：在设置编译优化之后，XCode断点和调试信息会不正常，所以一般静态库或者其他Target这样设置。
4.资源整合
4.1 将常用的代码及文件打包成静态库
4.2 添加预编译文件，把常用的头文件放到预编译文件里面
4.3 能用@class就用@class

⑷ 操作系统跟cpu架构de关系

这么简单的跟你说吧：

操作系统都是用高级语言编写的，无论是Windows还是安卓或者Linux。在系统编程的时候是不用怎么太考虑硬件的，用高级语言编写的程序交给具体的硬件执行的时候，硬件是不能直接识别的，还需要机器语言进行翻译(编译)，不同架构的处理器对应的机器语言是有差异的，同一种操作系统专门针对不同的机器语言和处理器架构进行必要的优化和编译之后，都是可以执行的。

当然，由于指令集不同，在优化和编译的过程中，必要的调整，甚至重写编码是必须的。

⑸ 编译器的组成及各部分的功能及作用

1. 词法分析 词法分析器根据词法规则识别出源程序中的各个记号（token），每个记号代表一类单词（lexeme）。源程序中常见的记号可以归为几大类：关键字、标识符、字面量和特殊符号。词法分析器的输入是源程序，输出是识别的记号流。词法分析器的任务是把源文件的字符流转换成记号流。本质上它查看连续的字符然后把它们识别为“单词”。 2. 语法分析 语法分析器根据语法规则识别出记号流中的结构（短语、句子），并构造一棵能够正确反映该结构的语法树。 3. 语义分析 语义分析器根据语义规则对语法树中的语法单元进行静态语义检查，如果类型检查和转换等，其目的在于保证语法正确的结构在语义上也是合法的。 4. 中间代码生成 中间代码生成器根据语义分析器的输出生成中间代码。中间代码可以有若干种形式，它们的共同特征是与具体机器无关。最常用的一种中间代码是三地址码，它的一种实现方式是四元式。三地址码的优点是便于阅读、便于优化。 5. 中间代码优化 优化是编译器的一个重要组成部分，由于编译器将源程序翻译成中间代码的工作是机械的、按固定模式进行的，因此，生成的中间代码往往在时间和空间上有很大浪费。当需要生成高效目标代码时，就必须进行优化。 6. 目标代码生成 目标代码生成是编译器的最后一个阶段。在生成目标代码时要考虑以下几个问题：计算机的系统结构、指令系统、寄存器的分配以及内存的组织等。编译器生成的目标程序代码可以有多种形式：汇编语言、可重定位二进制代码、内存形式。 7 符号表管理 符号表的作用是记录源程序中符号的必要信息，并加以合理组织，从而在编译器的各个阶段能对它们进行快速、准确的查找和操作。符号表中的某些内容甚至要保留到程序的运行阶段。 8 出错处理用户编写的源程序中往往会有一些错误，可分为静态错误和动态错误两类。所谓动态错误，是指源程序中的逻辑错误，它们发生在程序运行的时候，也被称作动态语义错误，如变量取值为零时作为除数，数组元素引用时下标出界等。静态错误又可分为语法错误和静态语义错误。语法错误是指有关语言结构上的错误，如单词拼写错、表达式中缺少操作数、begin和end不匹配等。静态语义错误是指分析源程序时可以发现的语言意义上的错误，如加法的两个操作数中一个是整型变量名，而另一个是数组名等。

⑹ 编译器 同一架构cpu 通用吗

http://www.cnblogs.com/loleng/archive/2011/06/14/2080447.html

⑺ 不谈架构，看看如何从代码层面优化系统性能

太多了..
拿c++来说吧， Test t = Test（）；和 Test t（）；的效率不一样。写循环，最好是连续内存能够利用缓存。 减少系统调用多用buffer。常用函数内联， 还有很多编译器的优化，比如分支预测， 优化级别，内存对齐什么的。

⑻ 通过编译器对程序优化来改进cache性能的方法有哪几种

你的程序可能太短，看不出区别来，你比对一下她们生成的汇编码就知道了

CPU 缓存是为了提高程序运行的性能，CPU 在很多处理上内部架构做了很多调整，比如 CPU 高速缓存，大家都知道因为硬盘很慢，可以通过缓存把数据加载到内存里面，提高访问速度，而 CPU 处理也有这个机制，尽可能把处理器访问主内存时间开销放在 CPU 高速缓存上面，CPU 访问速度相比内存访问速度又要快好多倍，这就是目前大多数处理器都会去利用的机制，利用处理器的缓存以提高性能。

就算优化带来的效果非常有限，但是经过长年累月的持续优化，效果也是非常明显的，比如当年的Chrome浏览器就是靠打开网页非常快从而打败微软系统自带的IE浏览器。电脑手机等硬件的性能是有限的，不同的算法会产生不同的效率，今天我们就简单说一个选择问题，开发程序时是节省内存还是节省计算量。

⑼ 怎么区别软件架构，系统架构，解决方案架构，企业架构

不同的架构方法论，会将架构分为不同视图，每个视图侧重某一个方面、领域的问题。
比如希赛推的ADMEMS架构体系，分为以下几种视图：
1. 数据架构：描述数据的存储结构、格式等方面。
2. 物理架构：描述机器的物理部署、网络拓扑方面。
3. 运行架构：描述运行期线程、进程间的交互工作机制。
4. 逻辑架构：指如何将代码分成不同模块、组件，以及之间的职责分配、交互行为。
5. 开发架构：主要指开发工具的选择，程序单元的划分，开发管理规范流程等方面。例如分为哪些工程、项目，源代码管理，自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系，他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图，可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念，不知道是出于调侃还是无知。埃及的金字塔、神庙的建设，不是几个平常的泥瓦匠聚在一起就能够造出来的。像SAP、Oracle ERP，国内的金蝶等大规模的系统，以及空间站、火箭的控制系统等，没有系统性的架构方法、规范、流程，结果只能是悲剧。
当规模、复杂度没有达到一定程度，比如在一些小的团队、产品中，架构过程可能融入到老板、经理、组长、资历较深的一些开发者中，融入在大家的日常工作中，以至于感觉不到架构的存在。就算遇到一些问题，因规模不大、复杂度不高，也比较容易调整。当这些前提条件发生变化时，架构的作用和必要性就逐步的体现出来。
总的来说，一说到架构，如果你懂软件，那么你会了解为一个软件系统，这个软件设计的组成结构，如哪些是基础支持组件，哪些是完成A业务，哪些完成B业务。。。但说道企业架构的时候，就会问，该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构，以及他们如何链接在一起。我倒觉得，一个企业确实需要这样的架构，但不要神话它，最主要的是业务如何最终体现到软件中和流程中。而采取分离式设计时，最容易的错误就是各自为政，集成困难。那么以数据为中心的架构设计，会自然提供集成的基础。我提到过，企业最重要的资产是数据，甚至不是信息，是数据。企业的业务流程会变，IT系统会变，所需要的信息与知识会变，唯有数据能够积淀下来。这有点象自然演进，考古那种，啥都会消失，唐朝可以无比先进，但都会变，我们唯有找到反映当时情况的数据，才可以把握当思的面貌。

⑽ 一个典型的编译程序通常由哪些部分组成

1、词法分析

词法分析的任务是对由字符组成的单词进行处理，从左至右逐个字符地对源程序进行扫描，产生一个个的单词符号，把作为字符串的源程序改造成为单词符号串的中间程序。执行词法分析的程序称为词法分析程序或扫描器。

2、语法分析

编译程序的语法分析器以单词符号作为输入，分析单词符号串是否形成符合语法规则的语法单位，如表达式、赋值、循环等，最后看是否构成一个符合要求的程序，按该语言使用的语法规则分析检查每条语句是否有正确的逻辑结构，程序是最终的一个语法单位。

3、中间代码生成

中间代码是源程序的一种内部表示，或称中间语言。中间代码的作用是可使编译程序的结构在逻辑上更为简单明确，特别是可使目标代码的优化比较容易实现。中间代码即为中间语言程序，中间语言的复杂性介于源程序语言和机器语言之间。

4、代码优化

代码优化是指对程序进行多种等价变换，使得从变换后的程序出发，能生成更有效的目标代码。所谓等价，是指不改变程序的运行结果。所谓有效，主要指目标代码运行时间较短，以及占用的存储空间较小。这种变换称为优化。

5、目标代码生成

目标代码生成是编译的最后一个阶段。目标代码生成器把语法分析后或优化后的中间代码变换成目标代码。

(10)编译优化架构扩展阅读：

编译程序把用高级程序设计语言书写的源程序，翻译成等价的机器语言格式目标程序的翻译程序。编译程序属于采用生成性实现途径实现的翻译程序。它以高级程序设计语言书写的源程序作为输入，而以汇编语言或机器语言表示的目标程序作为输出。

编译出的目标程序通常还要经历运行阶段，以便在运行程序的支持下运行，加工初始数据，算出所需的计算结果。

编译程序的实现算法较为复杂。这是因为它所翻译的语句与目标语言的指令不是一一对应关系，而是一多对应关系；同时也因为它要处理递归调用、动态存储分配、多种数据类型，以及语句间的紧密依赖关系。

但是，由于高级程序设计语言书写的程序具有易读、易移植和表达能力强等特点，编译程序广泛地用于翻译规模较大、复杂性较高、且需要高效运行的高级语言书写的源程序。