文件编译时间过长
1. Xcode 构建速度优化（一）衡量编译时间
随着项目不断迭代，工程文件越来越多，引用的三方库也越来越多，这些直接导致编译时间的不断增加，完整编译一次项目动辄需要五分钟以上时间，实在有些影响开发效率，是时候来一波提速了。
为编译和构建提速，首先我们需要对速度有一个衡量标准：准确获得构建用时
首先，我们需要定义要衡量和优化的内容。 有两种选择：
xcode默认情况下会跟踪所有构建，我们可以通过更改xcode相关设置，来在活动查看器中显示出构建时间，通过命令行：
每次编译成功后，会在Successed之后显示出所用时间:
Xcode Build Timing Summary是Xcode10中加入的用于查看获取构建时间和发现用时瓶颈方面的最有利工具。 可以通过Proct->Perform Action->Build With Timing Summary来开启：这样在 Build Log 的末尾就会添加 Timing Summary Log。我们可以通过这个 log 看到哪个阶段是耗时的，便于我们进行优化。
如上图中: xib阶段的编译耗时明显是比普通c文件要多的，意味着我们可以通过减少xib方式来优化提升速度
而c文件的编译用时比总时间还要长，是因为c文件是并行编译的
在命令行中同样可以开启这个功能：
常用的第三方工具有 BuildTimeAnalyzer 、 xcode-build-times-rendering 、 XCLogParser 。
BuildTimeAnalyzer可以统计可以得出某个文件的类型检查时长，每个表达式的类型检查时长。
xcode-build-times-rendering是一个Ruby编写的第三方工具，可以方便地分别测量目标的构建时间并在图表上显示它们，使用gem安装
接下来使用这个工具自带命令配置项目
然后构建项目并生成报告：
这个工具使用上比较简单，缺点是只能从宏观上生成各个target编译的整体图标，无法详细列出各个内部编译明细
XCLogParser可以详细列出各个Target和内部每个文件的编译耗时，对我们分析编译时间瓶颈非常有帮助，它的工作原理主要是做为解析器，通过解析xcode编译生成的xcactivitylog日志来记录
安装：
编译项目后，进行安装
安装成功后通过命令：
会自动在当前目录的 build/xclogparser/reports/ 路径下生成报告，其中--project参数需要设置为待分析项目的名字，并注意当前在终端切换到希望写入日志的目录。
报告截图：
这个工具将作为我们后面分析提升编译构建速度的主要使用工具。
经过我多次在不同时间段，不同电脑上不断尝试编译，
我发现编译耗时是一个比较玄的东西，及时在同一台电脑，同一个项目， 同一套环境配置下，编译用时也会随着电脑当前状态（包括同时打开进程、散热等等）上下大幅跳动，就像算法时间复杂度一样，有时候我们明明做了一些细微的优化，但是结果反而是编译耗时增加了，这是很正常的事情
所以，衡量这个标准需要我们取多次试验中的平均值作为参考。
2. C语言多充循环，运算次数多，编译时间很长，又无法估计最终需要多久，怎么办
如果要减少时间 那么优化代码，或者直接改进算法
如果要预测时间，那么大致估计一下循环的次数，然后在固定的某个循环中加一个打印，通过打印频率来估算总时间
3. Visual Studio编译很慢，什么原因
Visual Studio编译很慢解决办法：
打开vs2010的工具选项，环境>常规之下 查看”视觉体验”配置，它默认选择了”基于客户端性能自动调整视觉体验”并启用硬件图形加速，取消选择这个选择。
4. 一个C++工程中，许多个文件都include某一个类，当该类更新时，编译速度太慢，怎么办
这是个好问题，虽然老生常谈，但真正知道解决方案的人很少。《EffectiveC++》有介绍，同时推荐这本书给所有C++er。
一个组织有问题的大型项目中，影响编译速度的最大问题就是头文件形成庞大的依赖网络，其中一个头文件修改就导致一大堆间接依赖的源代码文件需要重新编译。a.h包含b.h，b.h包含c.h，c.h又包含d.h，即使a.h和d.h似乎没什么关系，修改d.h的时候还是无可避免a.cc被重新编译。
首先得知道C++一个特性，函数分为声明和实现两部分是人所皆知，但类也可以分为前置声明和定义可能知道的人就比较少了，知道能怎么用就更少了，其实就是可以用来解决编译速度问题的。
5. 用Keil编译程序时数据段过长怎么办
程序DATA区空间已超过指定单片机的DATA区空间，可以用keil C编译的时候压缩。
6. tomcat部署的应用将jsp页面转换为java文件后编译该java文件成class文件耗时很长大概有3分钟。求解！
不可能的事，tomcat做这些操作只需几秒钟
7. Android studio 编辑build.gradle文件时卡顿时间过长是什么原因
方法1：
1、在C:\User\<用户名>\.gradle 目录下新建一个gradle.properties文件，并在里面添加一行：org.gradle.daemon=true
2、打开AS，在Settings中设置Gradle的工作模式为offline，如下图：
这样就可以解决一直在running的问题了
方法2：
找到路径C:\Users\admin\.gradle\wrapper\dists，在此文件夹下有一个gradle版本文件夹，打开后是一个名字很长的文件夹，
例如我的C:\Users\admin\.gradle\wrapper\dists\gradle-2.4-all\6r4uqcc6ovnq6ac6s0txzcpc0 然后下载对应版本的gradle，将下载的压缩包直接放进名字很长的文件夹中即可，不需要解压
方法3：
需要在android studio 中配置gradle的代理，当然是用goagent了。
打开setting->gradle->Gradle VM Options：
-Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=8087
设置生成功后，重启androidstudio ，速度会非常快。
方法4：
1）进入刚安装的Android Studio目录下的bin目录。找到idea.properties文件，用文本编辑器打开。
2）在idea.properties文件末尾添加一行： disable.android.first.run=true ，然后保存文件。
3）关闭Android Studio后重新启动，便可进入界面。
方法:5：
可能是由于国内的某些杀毒软件禁用了aapt.exe进程导致的。aapt即Android Asset Packaging Tool，在SDK的build-tools目录下。该工具可以查看，创建， 更新ZIP格式的文档附件(zip, jar, apk)。也可将资源文件编译成二进制文件，尽管你可能没有直接使用过aapt工具，但是build scripts和IDE插件会使用这个工具打包apk文件构成一个Android 应用程序。
解决办法：
网上有个解决的方法，是通过延长aapt.exe的启动时间来解决的，在系统变量中加上“SLAVE_AAPT_TIMEOUT”，并设置值为30，同时也要在用户变量中加上"JAVA_HOME"的设置，不过相信只要是做java或者android开发的人都会设置好"JAVA_HOME"吧
8. keil4每次build target 都是全编译是怎么回事啊每次花很长时间啊，谢谢！！！
尝试以下几种解决方法：
方法1：project--option for target 'xxx' ---Listing---将C Preprocessor Listing:.\Listings*.I 的勾选去掉。
方法2：project--option
for target 'xxx' ---target---Code Generation-- 将Use Cross-Mole Optimization勾选去掉
方法3：project--option for target 'xxx' ---Output---将Create Batch File的勾选去掉。
我的是方法1解决的
9. keil4每次build target 都是全编译是怎么回事啊每次花很长时间啊，谢谢!!!
全编译，顾名思义，就是把工程里所有的文件都编译一遍，不管这个文件是否有过改动，所以时间很长，因为这个过程是编译--链接---生成HEX文件，所以，如果你文件很多，代码很多，时间就很长。
而半编译是只对你改动过的文件进行重新的编译，所以，过程是
编译部分文件--重新链接--生成HEX.
如果你不是把Keil的优化等级调到了8级及以上，用半编译完全没问题。
10. myeclipse 编译时间很长，项目很大，全编要2个小时。
方法1：将其他模块打包，编译自己所在的模块；或自己写个脚本变异这个路径下的这个文件，因为最后生成的都是.Class类的可执行文件。
方法2：网上找个ant之类的脚本文件，直接修改路径，变异这个文件