【精品博文】jihceng0622：浅谈Codewarrior局部优化技巧

　　程序优化在很多工程应用中都会用得到，但是归根结底优化的目的是什么呢？在我看来，觉着无非是硬件平台资源限制的问题，其中硬件平台资源限制我指的是两个，即处理速度（Speed）和存储空间大小（Size）的限制。举个很形象的例子，如果要在ARM平台上跑51的代码，我根本不会去考虑代码优化的问题，因为要ARM去实现51的功能代码，资源是冗余的，没有必要花费精力去做优化，但是如果涉及到一些复杂的应用也肯定会遇到这样的问题（要么处理速度不够，要么存储空间不够）。

　　再举个常被拿来对比软件优化重要性的例子，目前手机操作系统两大阵营的Android和iOS，搭载Android的厂商每年都在拼硬件，从单核512M RAM到如今8核2G/3G RAM，App也是越做越绚丽越庞大，导致Android的手机更新换代的频率越来越快（感觉消费者完全是被迫去换手机），而反观iOS平台，由于其软件优化做的好，目前最强的iPhone5s也不过是双核1G RAM，而且昨天还看到一则新闻苹果至今还在给早期的iPhone 3GS维护和更新iOS6。咳咳，有点跑题了，话题扯远了，今天主要是想说说局部优化的问题，开发环境就以FSL自己的Codewarrior为例吧，因为这也是我在帮一个客户解决问题的时候想到一种方法。

　　前面说到代码优化的目的，一个满足Speed的要求，一个是满足Size的需求，我这里重点说下Size的问题。我们在选定好一个硬件平台之后，其主频、RAM和Flash空间也就固定下来了，但是如果由于前期需求分析不足或者以后功能升级造成代码量已经超出既有的硬件平台存储空间的话，这样就会有两种选择方案，一种是代码量超出既有存储空间很多那就只能考虑替换存储空间更大的芯片（得综合考虑成本的问题），另一种是代码量超出不多，这时就可以考虑对软件进行恰当的优化来化解这个问题。现在一般的IDE开发环境的编译器都是支持对代码进行不同等级的优化（有的编译器也可以设置优先考虑Speed还是Size的需求），当然这种设置是全局的，它会对整个工程的代码进行优化，但是有一个很严肃的问题需要考虑，一般来说软件的优化一定程度上来说也会造成功能上的不稳定或者引入不可预知的隐患bug，甚至可能会造成功能上的逻辑错误导致程序不能正常运行，而且优化等级越高这个风险就越大，需要有足够经验的高手才能游刃有余，所以一般来说代码空间足够的话是不建议优化的。这里我给大家分享的一种折衷的办法，局部优化，即实现单独对代码中某个函数或者某个C文件进行优化，这样就可以保证对优化带来的风险进行有效的控制。

　　FSL的开发环境Codewarrior针对ARM平台提供了可选的两种编译器供开发者选择，一种是freescale自己的编译器，一个是耳熟能详的GCC，要实现在这两种编译器中对代码进行局部定制化的优化需要使用预编译指令#pragma，如下（左侧围Freescale自己的编译器指令，右侧围GCC编译器指令）：

　　具体的使用方法，以GCC为例，如下：

　　#pragma GCC push_options

　　#pragma GCC optimize ("O0") //可选O0(不优化), O1, O2, O3, O4

　　//insert your code here

　　#pragma GCC pop_options

　　其实前面说了那么多，实际上就是为上面四行代码做铺垫，呵呵，所以说写篇分享真是有点累的慌，希望对大家有所帮助，不然亏的慌，哈哈。

◆ ◆ ◆ ◆ ◆◆ ◆ ◆ ◆ ◆◆ ◆ ◆ ◆ ◆◆ ◆ ◆ ◆ ◆