问题:编译策略之代码逻辑顺序不正确(Optimization Level)

问题

曾经遇到过一个问题, 运行一段代码发现执行的逻辑顺序不正确, 而且在添加了其他语句后, 还会有不同的顺序, 但是都是不正确的.
如下:

Debug 一下发现, 逻辑顺序为: 1> – 2> – 1> – 3>,而且在其中的添加 NSLog 后顺序还会发生变化

分析

在过程中 test 的值打印会正常显示,但在下方po test 打印会显示:
(lldb) po now
error: warning: couldn’t get cmd pointer (substituting NULL): extracting data from value failed
Couldn’t materialize: couldn’t get the value of variable now: no location, value may have been optimized out
Errored out in Execute, couldn’t PrepareToExecuteJITExpression

解决方案

其实这是由于你工程编译策略的问题,需要将 release 下的变异策略修改:
Project > App target > Build Settings > Optimization Level > Release 将选项 fastest,Smallest[-Os]改为 None .
在 debug 下不会发生此错误,是因为 debug 下的变异策略默认为 None

编译策略介绍

关于优化级别：GCC_OPTIMIZATION_LEVEL 描述如下
None: Do not optimize.
[-O0]With this setting, the compiler’s goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code.Fast: Optimizing compilation takes somewhat more time, and a lot more memory for a large function.
[-O, -O1]With this setting, the compiler tries to reduce code size and execution time, without performing any optimizations that take a great deal of compilation time. In Apple’s compiler, strict aliasing, block reordering, and inter-block scheduling are disabled by default when optimizing.Faster: The compiler performs nearly all supported optimizations that do not involve a space-speed tradeoff.
[-O2]With this setting, the compiler does not perform loop unrolling or function inlining, or register renaming. As compared to the ‘Fast’ setting, this setting increases both compilation time and the performance of the generated code.Fastest: Turns on all optimizations specified by the ‘Faster’ setting and also turns on function inlining and register renaming options. This setting may result in a larger binary.
[-O3]Fastest, smallest: Optimize for size. This setting enables all ‘Faster’ optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.

编译策略资料:
https://gcc.gnu.org/onlinedocs/gnat_ugn/Optimization-Levels.html

拓展问题

1.今天在测试app时，发现app store上版本有奔溃现象，但是直接用xcode跑本地程序没问题。猜测release&debug版本造成的，后发现targets的 optimization level设置问题，将release版本的optimization level改为none后程序不再崩溃

2.问答
问：写了个程序。但在release模式下真机测试 ，不能正常工作。例如界面从网络上获取的图片等等。 但当optimization level设置成NONE后所有问题都正常了。
发布到APPSTORE上的程序编译时必须设置optimization level为 [-Os] 吗？如果设置为NONE会不会不通过审核？

答：Optimization Level 应该是编译器的优化程度。
比较早期的时候，硬件资源是比较缺乏的。为了提高性能，开发编译器的大师们，都会对编译器(从c到汇编的编译过程)加上一定的优化策略。优化后的代码效率比较高，但是可读性比较差，且编译时间更长。
优化是指编译器一级的措施，与机器指令比较接近，所以很可能会导致硬件不兼容，进而产生了你目前遇到的软件装不上的问题。
他是编译器的行为，与你代码理论上不相关的。 苹果的检查应该是检查你的代码一级的规范程度，隐私侵权相关的问题。 应该是与编译的过程是无关的。请放心。