直接上干货。
个人感觉，性能问题有40%以上是代码逻辑的问题，剩下50%instrument 可以帮你定位，剩下的10%就是经验和能力的沉淀了。
注意事项：
（1）性能问题，一定要用真机来调试；
（2）debug时，切记edit scheme选择profile将里面的build config由release改为debug；
（3）build setting里面将debug information format里面的debug下的选项改为：
“with dsYM File”
一、启动阶段耗时：
神器：TIME PROFILE
1.cmd＋ｉ，运行，走起，处理黑名单方法。
2.代码逻辑方面：
（1）是否启动有不合理的耗时操作（发请求，ｉｏ读写操作），是否一定要放在启动阶段。
（2）启动时的发包如果过多，考虑将过多的、没有必要的发包ｈｏｌｄ住，留在进入启动后的界面后再发包。
二、图片加载耗时：
1.比较基础的用法：
uiimage imageNamed：自带缓存功能，用于大量加载的图片调用
uiimage imagewithcontenfile：适用于大图，加载一次的调用
2.一些比较耗时的图片，比较tableView上的头像，可以考虑加载到calayer层，calayer层有GPU加速，对性能提升有比较大的改善，缺点是可能会导致view层上动画失效，所以方案上，可以把一些耗时的图片，放在layer的层。
3.clearColor问题
再介绍一下instruments神器：
大量图片没原因的被设置为clearColor，以及opqque ＝ NO，
会导致图片渲染耗时。（看了下原理，我的理解是，本来两个图层各渲染一次就好，然是设置为透明之后，各渲染一次之后，还是渲染一次叠加的效果）。
而且，苹果官方文档也对opaque这一属性的描述中提到：
当置为YES时，会提升性能。
4.另外就是考虑，图片的缓存方式(bitmap位图缓存，但是比较占内存空间)，
内存映射mmap等方式，具体可以参考下path新开源的图片优化库FastImageCache，是Path团队开发的一个开源库，用于提升图片的加载和渲染速度。
三、读写、网络请求
耗时操作尽量放在子线程（最好有独立的数据库线程和网络请求线程）中去操作。
四、内存泄漏问题
1.静态分析
2.instrument 又闪亮登场：
如果刚才是静态分析，那么现在就动态分析了。
过多的内存泄漏问题（注意instrument的红线了）以及不必要的单例问题也会造成性能的恶化。
五、多说一句UseDefault
NSUserDefault 以比较便捷的存储方式著称为大多数开发人员所喜爱，但是，你可知道，不加以节制的大量的使用NSUserDefault（尤其在中大型项目中），会使得性能恶化。
原理上，NSUserDefault每新存入一个新的对象，会将内部所有的对象全部重新保存一遍，所以也就是NSUserDefault不能用于海量存储的根本原因。
文件的io耗时，instrument中的
也有一定的功效，定位到耗时的io操作，以及耗时时间。
6、
for(size_t y =0; y < height; ++y) {
for(size_t x =0; x < width; ++x) {
//Dosomething with xandy here
}
}
小小的改动或许就可以让它运行的更快：
dispatch_apply(height, dispatch_get_global_queue(0,0), ^(size_t y) {
for(size_t x =0; x < width; x +=2) {
//Dosomething with xandy here
}
});
