問題

曾經(jīng)遇到過一個(gè)問題, 運(yùn)行一段代碼發(fā)現(xiàn)執(zhí)行的邏輯順序不正確, 而且在添加了其他語句后, 還會(huì)有不同的順序, 但是都是不正確的.
如下:

Debug 一下發(fā)現(xiàn), 邏輯順序?yàn)? 1> – 2> – 1> – 3>,而且在其中的添加 NSLog 后順序還會(huì)發(fā)生變化

分析

在過程中 test 的值打印會(huì)正常顯示,但在下方po test 打印會(huì)顯示:
(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

解決方案

其實(shí)這是由于你工程編譯策略的問題,需要將 release 下的變異策略修改:
Project > App target > Build Settings > Optimization Level > Release 將選項(xiàng) fastest,Smallest[-Os]改為 None .
在 debug 下不會(huì)發(fā)生此錯(cuò)誤,是因?yàn)?debug 下的變異策略默認(rèn)為 None

編譯策略介紹

關(guān)于優(yōu)化級(jí)別：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時(shí)，發(fā)現(xiàn)app store上版本有奔潰現(xiàn)象，但是直接用xcode跑本地程序沒問題。猜測release&debug版本造成的，后發(fā)現(xiàn)targets的 optimization level設(shè)置問題，將release版本的optimization level改為none后程序不再崩潰

2.問答
問：寫了個(gè)程序。但在release模式下真機(jī)測試 ，不能正常工作。例如界面從網(wǎng)絡(luò)上獲取的圖片等等。 但當(dāng)optimization level設(shè)置成NONE后所有問題都正常了。
發(fā)布到APPSTORE上的程序編譯時(shí)必須設(shè)置optimization level為 [-Os] 嗎？如果設(shè)置為NONE會(huì)不會(huì)不通過審核？

答：Optimization Level 應(yīng)該是編譯器的優(yōu)化程度。
比較早期的時(shí)候，硬件資源是比較缺乏的。為了提高性能，開發(fā)編譯器的大師們，都會(huì)對(duì)編譯器(從c到匯編的編譯過程)加上一定的優(yōu)化策略。優(yōu)化后的代碼效率比較高，但是可讀性比較差，且編譯時(shí)間更長。
優(yōu)化是指編譯器一級(jí)的措施，與機(jī)器指令比較接近，所以很可能會(huì)導(dǎo)致硬件不兼容，進(jìn)而產(chǎn)生了你目前遇到的軟件裝不上的問題。
他是編譯器的行為，與你代碼理論上不相關(guān)的。 蘋果的檢查應(yīng)該是檢查你的代碼一級(jí)的規(guī)范程度，隱私侵權(quán)相關(guān)的問題。 應(yīng)該是與編譯的過程是無關(guān)的。請(qǐng)放心。

總結(jié)

以上是生活随笔為你收集整理的问题:编译策略之代码逻辑顺序不正确(Optimization Level)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。