• 版本编译时间的长短，对开发效率影响比较大，本系列文章将对编译时间这个话题做一阐述。

• 本博客地址，https://blog.csdn.net/qxhgd，欢迎各位关注，转发请注明出处。

编译分类及对应场景

全量编译

• 全量编译，实际上就是下载全代码之后的第一次make；

• 适用于系统版本的构建、DailyBuild、CI等场景。

增量编译

• 增量编译，实际上是版本之前已编译过，修改某些文件后的再次编译；

• 适用于开发人员的开发调试、CI（既可使用全量也可使用增量）等场景。

需要考虑哪些因素

具体需求

• 编译效率的提升，首先要明确具体的需求、具体的场景，是对某一模块优化还是对整个版本做优化；

• 全量编译和增量编译的优化的方法论是不同的，对某一模块的策略和对整个版本的策略也是有区别的；

意识问题

• 以笔者的经验看，项目上对结果的关心远甚于对过程的关心，这种现象实际上是存在很大漏洞的；

• 曾经笔者做的几次编译优化，或大或小都出了一些问题，事后复盘，发现跟项目管理者的意识不到位有一定关系；

• 编译优化，事情可大可小，出了问题就是大问题，所以要对编译优化引起足够的重视，不能说把任务扔给开发人员之后，项目就不管了，至少几个层面要关注：

– 需求明确后，要评估大概的工作量（人天）（含后续其他步骤）；

– 修改的范围，涉及到的模块及对应功能、设计用例等；

– 修改之后的测试（自动化测试、针对修改的功能测试）

– 是一次合库还是多次合库，如果是多次，中间是否会出版本等；

如何评价

• 通常对编译速率的考量指标就是时间，比如CI的时间要缩短到xx分钟之内；

• 但实际上的编译速度和编译服务器配置、CPU的忙闲是挂钩的，有的时候，优化可能在某台服务器上有很大提升，在另一台服务器上可能没什么变化；

• 这点可能需要项目协调资源的，比如要求在CI服务器上提升，那么测试编译时间要在CI服务器上进行验证；

• 另外，编译时间受CPU忙闲等因素影响，所以取某一次的时间，意义不大，建议取平均值，这个也是需要CI维护人员配合支持的；

质量问题

• 所谓质量问题，就是等价性，如何确认当前版本和以前版本（编译优化之前）是等价的？这点实际上很难确认。

• 这里仅提几点供各位参考：

– 从功能角度看，修改影响分析、用例设计、测试覆盖等，需要项目协调资源；

– 从代码角度看，功能宏的开关要保持一致、目标文件（.o、.bin、ko）的数量、大小（不一定完全相同，仅供参考）等；