编译的速度优化
Ⅰ vue编译打包速度优化
1、首先在config文件夹下配置webpack.dll.config.js(内容如下)，要打包的模块的数组可以将一些较大的依赖放进vendor中
2、在package.json的scripts加上
3、运行npm run dll就可以生成vendor-manifest.json和vendor.dll.js
4、然后在index.html中引入vendor.dll.js
然后就可以正常的进行编译打包，会发现将更多的依赖放到vendor，打包速度越快
优化前
优化后
大概平均可以节省三分之一的时间。参考 webpack中文网
Ⅱ 如何加快Android Studio 编译app 的速度
以下几个方法可以提高Android Studio的编译速度：
使用Gradle 2.4。
Gradle 2.4对执行性能有很大的优化，要手动让Android Studio使用Gradle 2.4，在项目根目录下的 build.grade中加入。
Ⅲ 提高c语言代码效率
C语言7种提高效率
1、位运算替代乘除
位运算是C语言中的最小数据单元，移位运算或位处理基本上是每个MCU或者处理器的指令集中直接支持的所以C代码编译成汇编以后基本上简单的几条汇编指令即可完成运算。
然而对于乘除法CPU一般无法直接运行，当然现在高端的芯片一般支持FPU等等之类的处理，相对而言速度得到了显着提升;但是大部分还是会比移位运算处理耗时，特别是有些编译器直接把乘除法编译成函数调用来处理。所以像n/8这样的处理直接使用n>>3即可替代，这样效率会更高。
2、变量的使用
使用全局变量相对局部变量效率更高，函数的局部变量一般处于函数内部，在调用过程中存在入栈与出栈野孝的情况，这样就增加了函数调用的耗时，而全局变量直接访问效率更高。当然全局变量是程序中要非常小心使用的，滥用全局变量的行为确实会增加系统各模块之间的耦合，所以在程席中要规范全局的统一接口使用。
同时对于变量类型的使用也是大家需要注意的，数据类型不是越大越好，比如uint64_t的处理汇编生成代码就相对比较多，执行效率一般比短数据类型要低，尽量选择芯片相同位数的数据类型处理，当然大部分更小的数据长度也是合适的。
3、指针替代数组
相对数组索引，指针运算效率更快，数组是一片连续的内存空间，那么通过指针移动进行数组数据的索引也是合适的。
比如我们遍历数组array[i]，任意一次的循环都需要对其进行下 “i”值的标记与计算，而当指针“p”位于array数组位置的时候，循环仅只需要对“p”进行增量的操作，这样指针耗时会比数组访问小很多。
4、算法优化
一些数据的处理明明可以通过更加简洁的算法，可是没脊侍大部分程序员非要以最傻瓜的方式进行运算，最容易理解的就是高斯求和，1~100累加，还是选择高斯求和算法，当然还有很多算法有多种形式，各有优劣，根据自身需求进行合理选择。特别是一些应用根本没有必要用使用高精度耗时的数据处理算法，选择一些低精度快速的算法更加合适。
5、优化分支语句
我们都知道if-else语句是最常用的分支语句，其特点就是逐一判断，既然是判断就会消耗时间，然而对于一些处理并不是每个分支都是均匀执行的，如果你把频繁执行的相应分支放到后面，势必就需要执行较多前面的逐一判断，从而降低代码执行效率。
所以我们要对各个分支的执行频率进行评估，把最有可能执行的放在判断语句前面执行。同样对于分支语句多级嵌套的情况，我们需要把频率性对较高的放到外层，频率低的放内层，这样减枯吵少不必要的外层判断。
6、循环语句的优化
在系统的多重循环过程中，需要程序员将最长的循环内容设置在系统的最内层，同时需要将最短的循环内容设置在系统的最外层。
这样，能够有效提升CPU的运行效率，减少循环次数。另外，如果在系统的循环过程中需要进行逻辑判断，且循环的次数相对较大，就需要将循环判断从系统内部转移到系统的外部。
7、无敌” 宏"的利用
宏在C语言中是灵活度非常高的语法特性，宏代码片段的使用其代码表现形式上与函数差异并不是很大，大伙有学习C++语言模板的经验，应该会觉得两者有颇多相似之处。
在对函数进行调用的过程中，需要通过栈对其进行储存，而且CPU在函数调用的过程中还要做好对数据的恢复准备，有效进行出栈和进栈的操作。所以占用CPU时间除了代码本身之外，对函数进行调用也需要占据一定的时间。而宏就能节省参数压栈、返回参数、C语言call调用以及执行return的操作步骤，从而提高程序的运行效率。
Ⅳ 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参数需要设置为待分析项目的名字，并注意当前在终端切换到希望写入日志的目录。
报告截图：
这个工具将作为我们后面分析提升编译构建速度的主要使用工具。
经过我多次在不同时间段，不同电脑上不断尝试编译，
我发现编译耗时是一个比较玄的东西，及时在同一台电脑，同一个项目， 同一套环境配置下，编译用时也会随着电脑当前状态（包括同时打开进程、散热等等）上下大幅跳动，就像算法时间复杂度一样，有时候我们明明做了一些细微的优化，但是结果反而是编译耗时增加了，这是很正常的事情
所以，衡量这个标准需要我们取多次试验中的平均值作为参考。Ⅳ 如何加快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
