原文链接：https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity3.html
协程的执行不用于脚本的其他代码。大多数的脚本代码只是简单的出现在一个Unity特定的回调函数调用位置的性能追踪数据中。然而，协程的CPU代码总是出现在追踪数据的两个位置。
一个协程的所有初始代码，也就是从协程函数开始起到第一次yield，出现在协程开始的追踪数据中。通常，它出现在StartCoroutine被调用的地方。从Unity回调函数中生成的协程（比如返回IEnumerator的Start回调函数），第一次会出现在各自的Unity回调中。
所有其余的协程代码，也就是从它第一次恢复执行直到其执行完毕，出现在Unity的主循环中的DelayedCallManager那一行中。
要理解为什么会发生这种情况，就要知道协程事实上是怎样被执行的。
协程被C#编译器自动生成的一个类的一个实例支持。这个对象需要穿过多个调用来追踪协程的状态，对于编程者来说它只是一个函数。由于协程中的局部变量必须存在到yield调用，这些局部变量被提到这个生成的类中，并且这样可以在协程期间保持托管堆对它们的引用。这个对象也跟踪协程的内部状态，它也会记住在yield后协程要在哪个点恢复。
由于这个原因，开启一个协程的内存压力等于一个固定的消耗加上其局部变量的大小。
开始一个协程的代码构造并执行这个对象，并且Unity的DelayedCallManager当协程的yield条件被满足时会再次执行它。由于协程通常在其他协程之外启动，所以它们执行的消耗被拆分到了上文说的两个地方。
（图片见原网页）
在上面的截图中可以观察到，DelayedCallManager正在恢复一些不同的协程：PopulateCharacters, AsyncLoad和LoadDatabase是一些值得注意的。
当可能的时候，最好尽量压缩一些操作到最小数量的独立的协程中。虽然内嵌的协程在代码清晰和可维护性上表现优秀，但因为协程追踪对象，它会消耗更多的内存。
如果一个协程几乎每帧都运行，并且在长时间的操作不会yield，那么使用Update或LateUpdate回调函数通常会更有可读性。这特别是适合于长时间运行的，或是无限循环的协程。
当禁用一个对象时协程不会被终止，而是当其明确被销毁时才会被终止。这允许协程持续运行，并且如果需要，例如再次启动对象。调用Destroy(this)会立即触发OnDisable回调，并且协程被执行。最后，OnDestroy回调会在这一帧的最后执行。（注：经过翻译者本人测试，在Unity2017.3版本中，协程会被Disable操作中断，然后重新Enable后可以再次启动此协程；Destroy函数如文中所述一致）
重要的是记住协程不是线程。运行在协程中的同步操作仍然执行在主线程。如果目标是减少主线程的CPU消耗时间，那么重点就是和和脚本中其他的代码一样，避免在协程中有阻塞操作。
协程最好用在处理长时间异步操作时，比如等待HTTP传输，资源加载或者是文件I/O完成。
