关于嵌入式（移动）软件的性能问题

核心提示：连续解决了些性能问题，一般大家可能认为性能问题比较棘手，关于嵌入式（移动）软件的性能问题，需要非常有经验的人并且对系统非常了解的人来完成，其实谁也不可能对系统的所有的代码都了如指掌，因为它不是由某个单点引发的，是结构性的或算法性的，性能问题也是有一些一般性的方法可以采用的，分享一些基本的经验

连续解决了些性能问题，一般大家可能认为性能问题比较棘手，需要非常有经验的人并且对系统非常了解的人来完成。其实谁也不可能对系统的所有的代码都了如指掌，性能问题也是有一些一般性的方法可以采用的。

分享一些基本的经验。

首先当然是性能分析，必须找到真正的瓶颈，不要做无谓的优化(西医方法)。

性能分析

先说工具：

最基本的：

打log(到屏幕或者文件)，这是最直接最有效的方法，不过需要有耐心，很耗时间，你不可能一次在所有地方打上log，要用点二分法排除法，有足够的耐心不断地试，这就是《代码大全》里说的“蛮力调试”——乏味、费神、耗时，但却可以解决问题。

专用工具：

PC上有很多profile工具，如vcprofile,oprofile,vtune等。不幸得是，很多嵌入式设备上都没有太有效的profile工具(oprofile有android版本)，这也是受多数嵌入设备本身的资源所限。

对我们现在的架构来说，这个环境要好得多，我们一开始就架构了PC/Embedded统一架构，PC版本与嵌入版本永远同步，我这段时间解决的这些问题基本上也都是在PC版本上分析解决的，PC上有丰富的perf工具，Deploy的速度是Embedded的上百倍，节省了大量的时间。

然后说说方法和策略：

有了PC平台，要首先争取问题是否能在PC上重现，节省时间。但PC的速度是嵌入式设备的10倍，肉眼经常无法感觉出性能问题，所以，我们把数据打印在屏幕上(为什么不log到磁盘?因为需要实时的观察和跟踪)，观察数据的浮动，找到问题。怀疑一个函数的性能问题，可以打印它所有子函数的 TickCount，还可以打印io，内存碎片数，分配次数(前提是你设计了能钩住它们的方法)，层层递进，反复的试。

大部分的BUG类性能问题都可以这样被剥离出来，比如一个UI页面经过不断的操作后过一段时间会变得很慢，最后我们发现是底层的字体Cache在碰到某个字后导致Cache失效，再比如另外的由IO写入导致的性能问题，这些都是通过观察IO和函数TickCount值发现的问题。

另外一种性能问题就要麻烦些了，因为它不是由某个单点引发的，是结构性的或算法性的。

需要更多的数据和更深入的分析：

PCProfile

分析一个特定的模块/函数，关注下面几种数据：