代码调试与优化

这些天,有个朋友问我调试和优化方面的问题.正好这些天也解决了一个这方面的问题,顺便写出来,以期抛砖引玉.

 

我接到一个BUG,描述如下:

MTK6235平台某个项目,闹铃开机后,进入系统,在有些窗口,反应迟钝.延迟都在1秒和2秒之间.

 

由于他们提示我说,代码几乎没SP,这句不太准确的话,让我以为这是MTK平台固有的问题上.

如果是MTK平台固有问题,按照以往经验我就要做以下几个工作.

1.查找BUG的规律,并结果BUG推测问题的原因.

2.结合代码对照现象,把问题精确到单个模块或者单个函数,如果找不到,转到下面3,如果找到,转到5

3.跟踪开机过程,看一下闹铃开机和普通开机对系统初始化有什么不同

4.比较一下不存在该问题的项目与存在问题的项目软件打开的宏有什么区别

5.计算可能出现问题的代码的执行效率,把错误精确的某一行或者几行代码.

6.找出优化办法

 

整个过程是小大小,先从最可能出现的地方入手,找不到或者没有目标时,只能从大范围入手,然后再逐步缩小范围.但其实上面的流程有很多个变通的地方,如果这个项目是我从点到尾负责的,我几乎不用做前三步,如果找下出现问题的时间和那段时间代码修改的记录,然后在阅读修改的代码,找出可能出现问题的地方,计算效率,优化代码.但由于该项目我只是帮着寻找修改这个问题,所以只能一点一点排查.如果自已项目,可以从5开始.

 

第一步,经验研究发现,该问题只出现在返回IDLE窗口.这是一个很重要的规律.从这里我们大致可以推出三点:

A.该问题由待机窗口引起,

B.该问题由待机的前一窗口引起,退出速度太慢

C.其他程序修改了HISTORY管理函数,导致该函数效率降低.

 

由于该项目没有加SP,这使我放弃了第三种可能,然后我又研究了现在,发现不管哪个窗口,只要从他退到IDLE,速度必然很慢,而该窗口只要不和IDLE切换,速度就变的很快.这样就把问题转到了IDLE上.于是所有的焦点都集中在了EntryIdleScreen中.我阅读该函数代码,把注意力集中在非MTK代码上.然后我就发现IDLE里加了一些公司的工程师自己开发的功能.我几乎可以肯定问题就要解决了.我在函数EntryIdleScreen里找到了几个可能会引起效率低下的地方,当然非MTK的代码是重点关注的. 然后把该函数分割成几部分使用kal_get_time来打印TRACE数据.后来终于确认,公司的一个有关语音的初始化代码引起,该代码每次执行要花费300左右的TICK,转为秒是在一秒以上.把功能的初始化代码放在一个窗口里,这是需要尽量避免的.

然后我又TRACE了一下正常开机和闹铃开机对于这个初始化代码走的有什么不同.然后发现闹铃开机会导致该代码始终初始化不成,然后每次进入IDLE,都会重新初始化,检查代码时发现,如果是闹铃开机,且该功能初始化的信息文件在磁盘能找到时,才会导致初始化失败且重复执行.

修改了该问题的条件,T卡文件不存在时,让该功能不再初始化.

问题得以解决.