三类工具

基础工具（NSLog的方式记录运行时间）
性能工具，检测各个部分的性能表现，找出性能瓶颈
内存工具，检查内存正确性和内存使用效率

一、性能优化工具

可以衡量CPU的使用，时间的消耗，电池的消耗

1、Time Profile

启动Time Profile:Xcode -> Product -> Profo;e -> Time Profile
使用Time Profile调试程序，能获取到整个应用程序运行中所消耗的时间分布和百分比
使用Time Profile前有两点需要注意的地方：

（1）一定要使用真机调试

在开始进行应用程序性能分析的时候，一定要使用真机，因为模拟器运行在Mac上的CPU和iOS设备的完全不一样，模拟器不得已要在软件层面（CPU）模拟设备的CPU，这意味着CPU相关的操作在模拟器上运行的更慢，尤其是使用CAEAGLLayer来写一些OpenGL的代码时候，这就导致模拟器性能数据和用户真机使用性能数据相去甚远

（2）应用程序一定要使用发布配置

在发布环境打包的时候，编译器会引入一些列提高性能的优化，例如去掉调试符号或者移除并重新组织代码。另iOS引入一种“Watch Dog”【看门狗】机制，不同的场景下，“看门狗”会监测应用的性能，如果超出了该场所所规定的运行时间，“看门狗”就会强制终结这个应用的进程。开发者可以crashlog看到对应的日志，但Xcode在调试配置下会禁用“Watch Dog”

image.png

启动后如图

image.png

点击左上角红色按钮，开始调试

image.png

调试时注意右下方选项
Separate by Thread：每个线程应该分开考虑，只有这样你才能揪出那些大量占用CPU的"重"线程
Invert Call Tree：从上倒下跟踪堆栈，这意味着你看到的表中的方法，将已从第0帧开始取样，这通常你是想要的，只有这样你才能看到CPU中话费时间最深的方法，也就是说FuncA{FunB{FunC}} 勾选此项后堆栈以C->B-A 把调用层级最深的C显示在最外面
Hide System Libraries：勾选此项你会显示你app的代码，这是非常有用的。因为通常你只关心cpu花在你自己写的代码上的时间而不是花在系统代码上的时间
Flatten Recursion：递归函数, 每个堆栈跟踪一个条目
Top Functions：一个函数花费的时间直接在该函数中的总和，以及在函数调用该函数所花费的时间的总时间。因此，如果函数A调用B，那么A的时间报告在A花费的时间加上B花费的时间，这非常有用，因为它可以让你每次下到调用堆栈时挑最大的时间数字，归零在你最耗时的方法

image.png

最终调试界面如图

image.png

双击选中行查看代码
发现循环中的UIImage *image = [UIImage imageNamed:imageName];语句的时间消耗最长，度娘之：

UIImage初始化方法有两种
A：imagedNamed初始化
B：imageWithContentsOfFile初始化
二者不同之处在于，imageNamed默认加载图片成功后会内存中缓存图片，这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象，如果缓存中没有找到相应的图片对象，则从指定地方加载图片然后缓存对象，并返回这个图片对象
而imageWithContentsOfFile则仅只加载图片，不缓存
大量使用imageNamed方式会在不需要缓存的地方额外增加开销CPU的时间来做这件事，当应用程序需要加载一张比较大的图片并且使用一次性，那么其实是没有必要去缓存这个图片的，用imageWithContentsOfFile是最为经济的方式，这样不会因为UIImage元素较多情况下，CPU会被逐个分散在不必要缓存上浪费过多时间
使用场景需要编程时，应该根据实际应用场景加以区分，UIimage虽小，但使用元素较多问题会有所凸显

二、内存工具：

关心内存泄漏和内存垃圾问题
1、Analyze静态分析
（1）静态内存分析
a.所谓静态内存分析，是指在程序没有运行的时候，通过工具对代码直接进行分析

根据代码的上下文的语法结构，让编译器分析内存情况，检查是否有内存泄漏
b.作用
逻辑错误: 访问未初始化的变量或者野指针
声明错误: 声明了一个对象, 但是从未使用过
内存管理错误: 内存泄露
缺点: 静态内存分析由于是编译器根据代码进行的判断, 做出的判断不一定会准确, 因此如果遇到提示, 应该去结合代码上文检查一下
c.OC中的静态内存分析
曾经在MRC环境下, OC的代码需要手动管理内存, 任何对象的引用, 都要伴随一次release操作, 否则很容易发生内存泄露, 因此在MRC环境下, 使用静态内存分析很有必要
而在目前的ARC环境下, 很少会发生内存泄露, 但是也会有很少数的情况导致内存泄露
如Foundation对象与CoreFoundation对象的相互转化, CoreFoundation对象享用ARC机制, 所以容易发生内存泄露
d.swift的静态内存分析
Swift中, 使用了类型重映射机制, 他可以将对象转换成能够自动管理内存的对象, 不需要我们手动释放, 因此Swift在内存管理方面更为安全

三、内存分配

1、作用

查看当前运行情况的内存分配
查看使用过的内存有没有释放掉

2.关于APP中加载图片的注意点

imageNamed:

a.该方法用于加载小图片/使用频率高的图片
b.此方法加载过得图片, 在App运行期间, 始终会保有缓存, 这个缓存是由系统管理的, 无法通过代码销毁缓存
c.当系统察觉到内存消耗过高, 就会自动释放这部分内存

Search for an object whose name was set explicitly using the setName: method and currently resides in the image cache.
该方法首先会从图片内存中查找
Search the app's main bundle for a file whose name matches the specified string.
如果没有找到, 就在App的mainBundle中查找
Search the Application Kit framework for a shared image with the specified name.
如果bundle中也没有, 就会去framework的库中寻找

imageWithContentsOfFile:

a.该方法用于加载大图片/使用率较低的图片
b.它只是加载一次图片, 并且不会做缓存, 当对象释放的时候, 内存也就被释放掉了
c.因此对于不常用的图片应该使用这个方法
3.图片在沙河中的存在形式
（1）如果当前项目部署版本 <= 6.x: 那么所有图片就会直接暴露在沙盒的资源包中(main bundle), 不会进行压缩为Assets.car文件
（2）如果当前项目部署版本 >= 7.x

放在Images.xcassets中的所有图片, 都会被压缩为Assets.car文件, 不会直接暴露在沙盒的资源包中
而没有放在Images.xcassets的图片, 会直接暴露在沙盒的资源包中
（3）使用对比
压缩为Assets.car的文件:
a这些图片不会暴露在外, 但是无法或得到这些图片的路径, 只能通过图片名-imageName来加载图片, 并且会产生缓存
b小图片/使用频率高, 放在image.xcassets中
未压缩的图片:
a.图片暴露在外, 可以通过imageWithContentOfFile来获得图片的路径, 不会有缓存
b.大图片/使用频率低, 如新特性界面, 放在外面