1 工具使用
1.1 Leaks查找泄漏点步骤
使用Xcode和Instruments调试解决iOS内存泄露
http://blog.csdn.net/totogo2010/article/details/8233565
????????作为一名iOS开发攻城狮，在苹果没有出ARC(自动内存管理机制)时，我们几乎有一半的开发时间都耗费在这么管理内存上。后来苹果很人性的出了ARC，虽然在很大程度上，帮助我们开发者节省了精力和时间。但是我们在开发过程中，由于种种原因，还是会出现内存泄露的问题。内存泄露是一个很严重的问题。下面就简单介绍下怎么使用Xcode7自带的Instruments中的Leaks检测我们的程序有没有内存泄露和定位内存泄露的代码。(分析内存泄露不能把所有的内存泄露查出来，有的内存泄露是在运行时，用户操作时才产生的)。
????????第一步:打开Xcode7自带的Instruments
或者:
????????按上面操作，build成功后跳出Instruments工具，选择Leaks选项
????????选择之后界面如下图:
????????到这里之后,我们前期的准备工作做完啦，下面开始正式的测试!
????1.选中Xcode先把程序（command + R）运行起来
????2.再选中Xcode，按快捷键（command + control + i）运行起来,此时Leaks已经跑起来了
????3.由于Leaks是动态监测，所以我们需要手动操作APP，一边操作，一边观察Leaks的变化，当出现红色叉时，就监测到了内存泄露，点击右上角的第二个，进行暂停检测(也可继续检测，当多个时暂停，一次处理了多个)。如图所示：
????4.下面就是定位修改了,此时选中有红色柱子的Leaks，下面有个"田"字方格，点开，选中Call Tree
????显示如下图界面
? ? 5.下面就是最关键的一步，在这个界面的右下角有若干选框，选中Invert Call Tree 和Hide System Libraries,（红圈范围内）显示如下：
????????到这里就算基本完成啦，这里显示的就是内存泄露代码部分，那么现在还差一步：定位!
????6.选中显示的若干条中的一条，双击，会自动跳到内存泄露代码处，如图所示：
????7.找到了内存泄露的地方，那么我们就可以修改即可
1.2 Zombies查找和解决僵尸对象
????Instruments的Zombies模板
1.3 Time Profiler
????????时间都去哪儿啦？ Time Profiler 可以回答。它会按照设定的时间间隔（默认 1 毫秒）来跟踪每一线程的堆栈信息（stack trace），并通过比较时间间隔之间的堆栈状态，来推算出某个方法执行了多久，给出一个近似值。
????????在演示应用头一项「Time Profiler: System Methods」中，我用插入排序（Insertion Sort）和冒泡排序（Bubble Sort）两种算法来做性能比较，下面是 Swift 代码：
/* 引用自：http://waynewbishop.com/swift/sorting-algorithms/ */
func insertionSort() {
??? var x, y, key: Int
??? for (x = 0; x < numberList.count; x++) {
??????? key = numberList[x]
??????? for (y = x; y > -1; y--) {
??????????? if key < numberList[y] {
???????????????numberList.removeAtIndex(y +1)
???????????????numberList.insert(key, atIndex: y)
?????????? ?}
??????? }
??? }
}
func bubbleSort() {
??? var x, y, z, passes, key : Int
??? for (x = 0; x < numberList.count; ++x) {
??????? passes = (numberList.count -1) - x;
??????? for (y = 0; y < passes; y++) {
??????????? key = numberList[y]
??????????? if (key > numberList[y + 1]) {
??????????????? z = numberList[y +1]
? ? ? ? ? ? ? ? numberList[y +1] = key
??????????????? numberList[y] = z
??????????? }
??????? }
??? }
}
????????这段代码主要是对数组的添加和删除，两种方法执行起来耗时不多，但后台发生的系统动作却多得让人眼晕。
????????可以发现，代码用到了很多间接依赖，这些都是支撑代码运行的系统库文件。因为处理大数据集比较消耗系统资源，所以要尽可能地把繁重的操作放到后台去做，上面的代码就走的后台线程。在上图的 Call Tree 中可以看到，被调用的堆栈名是 dispatch_worker_thread3。如果把它放到主线程去执行，程序肯定会挂起。不信你注释掉 dispatch_async 调用看一下。
????????再来个图片加载的例子。
????????这儿有三种图片加载方法：
????? loadSlowImage1：从指定 URL 下载一张图片（加载速度慢）
????? loadImage2：从本地资源库加载一张图片（注意：没用系统缓存）
????? loadFastImage3：从系统缓存中加载一张图片（加载速度快）
????????我们来看看 Time Profiler 算出的结果是不是跟预想的一样。
????????进入演示应用第二项「Time Profiler: Our Methods」，点击「Reload」十次来重复加载图片，这样能产生足够的数据来分析。然后在 Time Profiler 图表中通过拖拉鼠标选中要放大查看的区域，从 Call Tree 中双击调用了 .reload 方法那一行（上图中加亮选中那一行），就会跳转到对应的代码行，所用时间也标注出来了。
????????看到谁最花时间了吧。虽然代码没什么可优化的地方，但大家应该认识到缓存能发挥的作用。所以即使有时还得调用 loadSlowImage，多数情况下把图片缓存下来，还是能省些资源占用。
????????此外，我想再说说 Call Tree 的选项设置。
????????这些选项默认是不选的，但把它们勾选上可以帮你更快定位到关键的代码上，往往这也是问题的源头。
??????Separate by Thread：按线程分开做分析，这样更容易揪出那些吃资源的问题线程。特别是对于主线程，它要处理和渲染所有的接口数据，一旦受到阻塞，程序必然卡顿或停止响应。
????? Invert Call Tree：反向输出调用树。把调用层级最深的方法显示在最上面，更容易找到最耗时的操作。
????? Hide Missing Symbols：隐藏缺失符号。如果 dSYM 文件或其他系统架构缺失，列表中会出现很多奇怪的十六进制的数值，用此选项把这些干扰元素屏蔽掉，让列表回归清爽。
????? Hide System Libraries：隐藏系统库文件。过滤掉各种系统调用，只显示自己的代码调用。
????? Flattern Recursion：拼合递归。将同一递归函数产生的多条堆栈（因为递归函数会调用自己）合并为一条。
????? Top Functions：找到最耗时的函数或方法。
????需要添加其他工具的话：
1.4 Allocations
????????我们经常需要从服务器下载大量图片，特别是开发照片类的应用。但往往稍不注意，内存使用就会暴增，所以得保证把这些图片缓存下来以便重复使用。下面来看看演示程序中内存分配的例子。
????????从图中可以看到，每次点击「Reload」重新载入图片时，内存都会出现使用峰值。应用先分配大量内存来替换原有图片，然后再释放掉这部分内存，可想而知这样的操作效率高不了，而且如果要下载更大的文件，呃，局面大概会失控吧。
????????看一下堆栈列表第四行，ImageIO_PNG_Data 里有 9 张处于活动状态的图片，占用了12.38 MB 内存，这些都是没被系统释放或缓存的内存，所以导致堆内存分配升高。接下来再看看使用缓存后的效果。
????????使用了缓存库（Swift Haneke）后，点「Reload」五次，这回在 Allocations 列表中却看不到 ImageIO_PNG_Data 对象了，这说明它是空的，没有任何图像数据。同时，All Heap Allocations 的大小已从刚才的 14.61 MB 降到了 2.51 MB。Anonymous VM（匿名虚拟内存）是系统为程序预留的、可能会立即被重复使用的一部分可用内存。要防止程序崩溃，就别让堆的尺寸增长太快。
????????还有就是，例子用的是异步方式来加载图片，这样用不着等到所有图片下载完才能在界面中显示。大多数图像缓存库都会把加载工作放到后台，以避免延长主线程的响应周期。
2 常见问题
2.1 配置使用
2.1.1 Thisapplication's application-identifier entitlement does not match that of theinstalled application. These values must match for an upgrade to be allowed.
可以修改profile的scheme
设为Debug模式
3 参考链接
(最新)使用Xcode7的Instruments检测解决iOS内存泄露
http://www.cnblogs.com/iOSv587country/p/4862989.html
iOS性能优化
http://08643.cn/p/9e1f0b44935c
「原创译文」iOS性能优化：Instruments工具的救命三招
http://segmentfault.com/a/1190000002568993
IPhone测试工具-Instruments教程
Instruments概述
http://08643.cn/p/2f850a774fca
iOS性能优化：Instruments使用实战
