作者讲了一堆。。关于发现问题和定位根本原因的重要性。这里直接略过
这一章的主要内容有以下几点：
1如何通过profiler获取运行数据
2如何通过分析profiler数据进行性能瓶颈的分析
3如何分析性能问题和定位根本原因
之后介绍了profiler的功能，profiler的各个子系统的功能如下：
1查看cpu消耗
2关于渲染和gpu的基础和详细信息
3内存的申请情况以及整体的消耗
4音效资源/数据的使用情况
5网络消息传递和操作利用率
6视频播放利用率
7关于ui性能的基础和详细信息
8全局光照数据
然后作者介绍了两种观测性能的方式，一个是用监测工具，一个是进行基准测试。
检测工具可以很好地观测到程序的内部实现，函数的调用行为，以及内存是如何被申请的等运行数据。但是刚开始找性能问题的时候就用检测工具，并不是很好的方法，因为检测工具本身会有一些性能消耗。在开发模式编译游戏的时候，额外的编译选项会被开启，导致系统会调用一些特殊的事件。这些事件会在profiler上记录和保存。这会导致在运行时产生额外的cpu和内存的消耗。如果是在editor上进行性能检测，情况会变得更加糟糕。因为editor还需要渲染一些额外的窗口和处理后台任务。尤其是在大型项目，使用profiler可能会导致应用的运行表现不同。事件产生时机以及异步调用的变化会导致出现一些异常现象。这是在使用profiler进行性能排查时必须要付出的一些代价，所以在使用profiler的时候要尤其注意这一点。
在开始分析每一行代码之前，最好先在测试设备上运行，在特定的测试样例下，获取一些初步的运行数据。测试样例可以是正常玩几秒的游戏，过场动画的播放，或者在一些关卡内进行游戏。目的是得到一个大致的用户体验，并且要在性能变差时认真观察，这些问题有时候需要更进一步的分析。
这个过程通常称之为基准测试。我们需要关注的指标就是FPS，CPU的运行情况，CPU和GPU的温度等。这些都是比较好获取的性能指标。
在进行完基准测试，并且需要进行深度分析的时候，可以用profiler进行性能检测。并且要尽可能测试更多的机型来获取运行数据。并且不要用editor进行测试，因为会有额外的性能消耗。
这里有一个提示，就是有时候会发现editor上的运行指标反而比真机更好。原因是editor会缓存一些像音效，prefab这样的数据，导致运行会更快。
总结来说就是，先在真机上运行查看是否有性能瓶颈，然后再在Profiler上查找定位该问题。Development Build会产生额外的性能消耗，用Profiler查看的数据跟实际会有一些出入。还有就是尽量不要在Ediotr上进行性能检测，因为Editor本身也有性能消耗。