5c ios10系统，debug一切正常， adhoc 环境下就

5c ios10系统，debug一切正常， adhoc 环境下就崩溃，小伙伴查了很久发现是一个配置项引起

在buildsetting中， 找到optimization level ， debug环境设置的是none， a d ho c环境设置的是smallest fastest ，若把a d ho c 环境设置为none就解决了。 

这个编译策略呢，就是编译器的优化程度。早期因为硬件资源不够强大，编译器在编译过程中会对代码进行优化，提高代码的效率。不过这个优化过程，因为比较靠近硬件一层，所以可能导致一些不兼容的问题。

很多Release包有问题而Debug包没问题，就是因为Release默认的是Fastest,Smallest而Debug默认是None

作者：悟空没空

链接：https://www.jianshu.com/p/8637d95fe558

來源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

查了一下optimization level 代表的意义：

6.3.1.3 Optimization Levels

Without any optimization option, 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 subprogram and get exactly the results you would expect from the source code.

Turning on optimization makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program.

If you use multiple -O options, with or without level numbers, the last such option is the one that is effective.

The default is optimization off. This results in the fastest compile times, but GNAT makes absolutely no attempt to optimize, and the generated programs are considerably larger and slower than when optimization is enabled. You can use the -O switch (the permitted forms are -O0, -O1 -O2, -O3, and -Os) to gcc to control the optimization level:

* 

-O0

No optimization (the default); generates unoptimized code but has the fastest compilation time.

Note that many other compilers do substantial optimization even if ’no optimization’ is specified. With gcc, it is very unusual to use -O0 for production if execution time is of any concern, since -O0 means (almost) no optimization. This difference between gcc and other compilers should be kept in mind when doing performance comparisons.

* 

-O1

Moderate optimization; optimizes reasonably well but does not degrade compilation time significantly.

* 

-O2

Full optimization; generates highly optimized code and has the slowest compilation time.

* 

-O3

Full optimization as in -O2; also uses more aggressive automatic inlining of subprograms within a unit (Inlining of Subprograms) and attempts to vectorize loops.

* 

-Os

Optimize space usage (code and data) of resulting program.

Higher optimization levels perform more global transformations on the program and apply more expensive analysis algorithms in order to generate faster and more compact code. The price in compilation time, and the resulting improvement in execution time, both depend on the particular application and the hardware environment. You should experiment to find the best level for your application.

Since the precise set of optimizations done at each level will vary from release to release (and sometime from target to target), it is best to think of the optimization settings in general terms. See the `Options That Control Optimization' section in Using the GNU Compiler Collection (GCC) for details about the -O settings and a number of -f options that individually enable or disable specific optimizations.

Unlike some other compilation systems, gcc has been tested extensively at all optimization levels. There are some bugs which appear only with optimization turned on, but there have also been bugs which show up only in `unoptimized' code. Selecting a lower level of optimization does not improve the reliability of the code generator, which in practice is highly reliable at all optimization levels.

Note regarding the use of -O3: The use of this optimization level ought not to be automatically preferred over that of level -O2, since it often results in larger executables which may run more slowly. See further discussion of this point in Inlining of Subprograms.