使用instrument-＞Time Profiler进行性能优化

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

另外在开始性能分析前另外一件重要的事情是，应用程序运行一定要发布配置 而不是调试配置.

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

注意手机或模拟器上要有运行过的app： 

Build Settings->Build Options->Debug Information Format->Debug->DWARF with dSYM File，如果没有配置检测结果显示地址而不是函数名, 根本无法看到具体的调用信息.

 Xcode–> Product–> Profile (command ＋ i 快捷键)调出instrument，选择Time Profiler，我们可以跟踪哪个方法最耗时间，以此来优化

Time Profiler分析原理：它按照固定的时间间隔来跟踪每一个线程的堆栈信息，通过统计比较时间间隔之间的堆栈状态，来推算某个方法执行了多久，并获得一个近似值。其实从根本上来说与我们的原始分析方法异曲同工，只不过其将各个方法消耗的时间统计起来。

和使用 Instruments的其他工具一样，点击XCode的Product菜单Profile启动Instruments  然后选择TimeProfiler

首先，确保右手边工具栏上的视图选择器的每一个选项都被选中，如下：

这样就确保所有的面板都被打开。现在看一下下面的截图和每一部分的说明。

1、这里控制记录过程，点击红色的"记录"按钮可以停止或开始当前正在分析的app（在记录和停止按钮之间切换），暂停键，如你所想，暂停当前正在运行的app。

2、这里是执行计时器（run timer），计时器记录着正在分析的app执行了多长时间、执行了多少次。如果你使用记录控制按钮来停止你的app，然后重启，这将创建一个新的运行记录，同时会显示"Run 2 of 2"。

3、这里被称作路径（track），就你选择的Time Profiler工具而言，因为只有一个工具，所以这里只有一条路径，关于这里显示的图标的详情，一会你就会在接下来的教程中了解更多。

4、这里是详情面板，展示的是你正在使用的工具的主要信息。就现在而言，这里展示的是最"笨重（hottest）"的方法--换句话说，占用CPU时间最长的方法。点击上方的bar会看到Call Tree（左手边的那个）并选中Sample List，然后你会看到数据的不同视图。视图展示了每一个示例。点击其中几个，你会在Extended Detail inspector中看到被捕获的堆栈跟踪。

5、这里是检查器（inspector）面板，一共有三个检查器：record setting（记录设置），display setting（展示设置），还有extends detail（扩展详情）。

从详情面板Call Tree与相关内容扩展详情面板对应的关系图：

详情面板更多的信息选项

样本列表（Sample List）

Timestamp：采样的开始时间

Dep：堆栈深度

CPU：线程运行在那一个CPU上

Process：进程名称

Thread：所在的线程名称

Hot Frame：采样中调用最多的函数

Responsible Library：调用该函数的库

Responsible Caller：调用该函数的函数

下面解释了每一个选项中数据的显示起了什么作用:

Separate by Thread：每个线程被单独考虑。这能让你知道哪一个线程占用CPU最多。

Invert Call Tree：选中该选项后，调用栈会自上至下显示。这通常是你需要的，因为你想知道CPU花费时间的那个最深的方法。

Hide System Libraries：选中该选项后，只有你自己app中出现的符号会被显示出来。通常选中该选项是有用的，因为你只关心CPU在你自己的代码中的哪一部分花费时间，你没法对系统库使用CPU做多少改变。

Flatten Recursion：该选项将每一个调用栈中的递归函数（调用它们自身的函数）视作单一入口，而不是多入口。

Top Functions：选上这一选项让Instruments将花费在一个函数中的总时间视作在该函数中直接花费的时间加上调用的其他函数花费的时间。所以如果函数A调用了函数B，那么函数A花费的总时间被记为A花费的时间加上B花费的时间。这一选项非常有用，因为它能让你在每次进入调用栈时找到花费最长的时间，瞄准你最耗时的方法。

四.使用技巧

1.图标为黑色头像的就是Time Profiler给我们的提示，有可能存在性能瓶颈的地方

2.按着option键在主界面6中通过拖动鼠标来选择需要过滤的时间段

3.Command+F查找过滤的函数名或者类名

4.关联代码

下面我们来开始分析原因，这是应用第一次进入首页的详情面板：

好嘛，占整个首页加载时间的13% 而且确实也是商城问题导致的，这一块是解压缩文件用的，是个耗时的操作，不知有没有放在后台线程里操作，这里只是一个具体的方法，我们看看都有谁调用了它，点击那一行的左箭头就可以展开查看所有调用者：

展开后看一下最后三行，它在首页的 viewdidLoad 方法中在初始化首页底部时，加载商城数据时，调用的解压缩操作，双击可以

查看具体代码实现，我们选中双击［Mall initMallConfig:］进去后看一下

这是一个拷贝资源的方法，我们跟进去看一下：

并没有发现任何开启子线程的操作，那么这个方法也就是在首页  viewdidload 方法里面调用的，代表就是在UI线程进行的文件copy

毋庸置疑，肯定会导致页面卡顿。

那我们把它放到子线程进行操作看看效果：

耗时的资源压缩复制放到后台执行 首页加载从851ms降到了 70ms ，加载速度显著提升.

总结：性能优化是在所有更能实现完成时要做的事，使用Time Profile工具分析app每个流程的执行情况，发现耗时的地方，合理优化，提升用户体验，切记，优化后要做一遍详细的测试，要不然别修了东墙坏了西墙。