問題

曾經遇到過一個問題, 運行一段代碼發現執行的邏輯順序不正確, 而且在添加了其他語句后, 還會有不同的順序, 但是都是不正確的.
如下:

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到匯編的編譯過程)加上一定的優化策略。優化后的代碼效率比較高，但是可讀性比較差，且編譯時間更長。
優化是指編譯器一級的措施，與機器指令比較接近，所以很可能會導致硬件不兼容，進而產生了你目前遇到的軟件裝不上的問題。
他是編譯器的行為，與你代碼理論上不相關的。 蘋果的檢查應該是檢查你的代碼一級的規范程度，隱私侵權相關的問題。 應該是與編譯的過程是無關的。請放心。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。