今天项目上有用户反应进入我们iOS应用的某个功能时，出现了手机发烫的问题，事出反常必有妖，这时候Instruments这把斩妖剑就是时候登场了。
首先把我们项目build settings的 debug infomation format 设置成 DWARF with dsYM File, 这一步很重要，我通常把它放到第一步，以免后面又要来设置再编译，这么设置的必要性是为了后面使用time profile能够直接快速准确地定位到问题所在的具体函数方法。
既然能够让手机发烫，那么她的CPU的占有率一定非常高，把工程用真机跑起来，然后进入问题所在的功能页面，果然CPU简直爆表了，竟然达到了109%！
这个时候我们再打开Instruments中的time profile工具，选择好设备和应用，点击红色按钮进行监测，再进入有问题的功能页面，慢慢就会有检测到的线程记录，点击下面的call tree 选择Separate by Thread和Hide System Libraries，能够更加快速找到最耗性能的线程，然后点击weight值最大的线程，右侧就会显示相对应的函数方法，然后去项目里面搜索该方法，分析代码定位出问题
最后我发现在我定位到的ImageSpring方法中竟然有无限递归，导致无限执行这个方法，直接爆炸！！！
修复并且替换掉该方法后再次真机运行起来，这个时候再在Xcode上看到CPU的使用率仅仅为1%了，完美修复！
顺便说一句，引发这个bug的同事已经被抓起来扭送派出所了^_^
网友评论