前篇中讲了一些自己关于Coroutine的理解，后来陆陆续续的又想到了一些，在此简单记录一下，内容不多，故作“小”续吧 ：）
之前的示例程序基本实现了一个自己的WaitForSeconds，功能上及使用上都与Unity自建的WaitForSeconds类似，另外的，如果我们进一步考虑WaitForFixedUpdate和WaitForEndOfFrame这类的YieldInstruction，我们是否也可以自己实现？其中的原理又是什么呢？
先让我们来看一张MonoBehaviour的生命周期图（外国友人所做，原帖在这里）：
从图中我们可以看到，Unity对于MonoBehaviour中Coroutine的处理，实际上并不是简单的单一步骤，而是采取了类似分阶段处理的方式：即在每次FixedUpdate之后进行WaitForFixedUpdate的处理，每次Update之后进行WaitForSeconds的处理，而在每一帧结束之前，进行WaitForEndOfFrame的处理。那么依此而看，先前示例中简单的LateUpdate模拟就有些捉襟见肘了：WaitForSeconds可能勉强还可以应付，但是像WaitForFixedUpdate以及WaitForEndOfFrame这类YieldInstruction，这种方式便应付不来了……
不过如果从原理上来讲的话，上面的那些YieldInstruction还是相似的，问题都集中于何时调用IEnumerator的MoveNext()操作而已，如WaitForSeconds，就是在其延时结束之后调用MoveNext()，而像WaitForFixedUpdate，便是在每次FixedUpdate之后才调用MoveNext()，另外的WaitForEndOfFrame，则是在每帧结束之前调用对应的IEnumerator的MoveNext()。如果需要实际实现的话，目前想到的一种方法便是创建几种不同类型的CoroutineManager，譬如WaitForSecondsCoroutineManager、WaitForFixedUpdateCoroutineManager等等，用于在不同更新时刻处理其中的IEnumerator，原理上都是控制IEnumerator MoveNext()的实际，在此我并没有加以实现，一是自己懒惰了些（……），二是Unity本身也未明显提供用以实现这类处理的回调方法，不过有兴趣的朋友倒是可以试试 ：）
另外想到的一个问题就是StartCoroutine的嵌套问题，即在某一个Coroutine中又以yield return的方式开启了另一个Coroutine，例如以下代码：
void Start() {
// start unity coroutine
StartCoroutine(UnityCoroutine());
}
IEnumerator UnityCoroutine() {
Debug.Log("Unity coroutine begin at time : " + Time.time);
yield return new WaitForSeconds(2);
yield return StartCoroutine(InnerUnityCoroutine());
Debug.Log("Unity coroutine end at time : " + Time.time);
}
IEnumerator InnerUnityCoroutine() {
Debug.Log("Inner Unity coroutine begin at time : " + Time.time);
yield return new WaitForSeconds(2);
Debug.Log("Inner Unity coroutine end at time : " + Time.time);
}
那么“外层”的UnityCoroutine只有在“内层”的InnerUnityCoroutine“执行”完毕之后才会继续“执行”，程序结果大概是这个样子：
在此简单一提，必须要采用yield return的方式才可以实现这种嵌套执行效果，简单的一个StartCoroutine只能创建一个“平行”的Coroutine，并不会产生嵌套效果，譬如如下代码：
void Start() {
// start unity coroutine
StartCoroutine(UnityCoroutine());
}
IEnumerator UnityCoroutine() {
Debug.Log("Unity coroutine begin at time : " + Time.time);
yield return new WaitForSeconds(2);
StartCoroutine(InnerUnityCoroutine());
Debug.Log("Unity coroutine end at time : " + Time.time);
}
IEnumerator InnerUnityCoroutine() {
Debug.Log("Inner Unity coroutine begin at time : " + Time.time);
yield return new WaitForSeconds(2);
Debug.Log("Inner Unity coroutine end at time : " + Time.time);
}
那么最终的执行结果便会是这个样子：
OK，那么如果我们需要自己实现这种嵌套机制，应该怎么做呢？实际上还是在特殊类型判断上做文章！在Unity中，每次调用StartCoroutine都会返回一个特殊的Coroutine类型，而这个类型便是我们实现嵌套Coroutine的突破口！好了，首先让我们实现一下自己的Coroutine类型：
//
// <maintainer>Hugo</maintainer>
// <summary>coroutine simple class</summary>
//
using UnityEngine;
using System.Collections.Generic;
public class CoroutineSimple {
public Stack<System.Collections.IEnumerator> innerEnumeratorStack;
public CoroutineSimple(Stack<System.Collections.IEnumerator> enumeratorStack) {
innerEnumeratorStack = enumeratorStack;
}
}
此处的Stack<System.Collections.IEnumerator>可能有些奇怪，实际上也确实如此（汗……），使用这种方式也仅是为了降低一点代码复杂度，因为我们现在要支持嵌套的Coroutine，于是使用了Stack<System.Collections.IEnumerator>这种类型，即每次我们都仅是处理某个Stack<System.Collections.IEnumerator>顶部的IEnumerator，一旦发现有嵌套的Coroutine产生，那便直接将对应的IEnumerator压栈，可能这么说还是有些许模糊，看一下新的CoroutineManager代码应该会更清晰一些：
//
// <maintainer>Hugo</maintainer>
// <summary>simple coroutine manager class</summary>
//
using UnityEngine;
using System.Collections.Generic;
public class CoroutineManager : MonoBehaviour {
public static CoroutineManager Instance {
get;
private set;
}
List<Stack<System.Collections.IEnumerator>> m_enumerators = new List<Stack<System.Collections.IEnumerator>>();
List<Stack<System.Collections.IEnumerator>> m_enumeratorsBuffer = new List<Stack<System.Collections.IEnumerator>>();
void Awake() {
if (Instance == null) {
Instance = this;
}
else {
Debug.LogError("Multi-instances of CoroutineManager");
}
}
void LateUpdate() {
for (int i = 0; i < m_enumerators.Count; ++i) {
// handle CoroutineYieldInstruction here
if (m_enumerators[i].Peek().Current is CoroutineYieldInstruction) {
CoroutineYieldInstruction yieldInstruction = m_enumerators[i].Peek().Current as CoroutineYieldInstruction;
if (!yieldInstruction.IsDone()) {
continue;
}
}
// do normal move next
if (!m_enumerators[i].Peek().MoveNext()) {
m_enumerators[i].Pop();
if (m_enumerators[i].Count <= 0) {
m_enumeratorsBuffer.Add(m_enumerators[i]);
}
continue;
}
if (m_enumerators[i].Peek().Current is CoroutineSimple) {
// here we just push new enumerator
CoroutineSimple coroutineSimple = m_enumerators[i].Peek().Current as CoroutineSimple;
m_enumerators[i].Push(coroutineSimple.innerEnumeratorStack.Peek());
// NOTE: very tricky
// TODO: clear
m_enumerators.Remove(coroutineSimple.innerEnumeratorStack);
}
// other special enumerator here ...
}
// remove end enumerator
for (int i = 0; i < m_enumeratorsBuffer.Count; ++i) {
m_enumerators.Remove(m_enumeratorsBuffer[i]);
}
m_enumeratorsBuffer.Clear();
}
public CoroutineSimple StartCoroutineSimple(System.Collections.IEnumerator enumerator) {
Stack<System.Collections.IEnumerator> newEnumeratorStack = new Stack<System.Collections.IEnumerator>();
newEnumeratorStack.Push(enumerator);
m_enumerators.Add(newEnumeratorStack);
return new CoroutineSimple(newEnumeratorStack);
}
}
代码味道不是很好，还有不少Tricky，但是也算基本实现了嵌套的Coroutine处理，写个简单的“单元测试”：
void Start() {
// start unity coroutine
StartCoroutine(UnityCoroutine());
// start self coroutine
CoroutineManager.Instance.StartCoroutineSimple(SelfCoroutine());
}
IEnumerator UnityCoroutine() {
Debug.Log("Unity coroutine begin at time : " + Time.time);
yield return new WaitForSeconds(5);
yield return StartCoroutine(InnerUnityCoroutine());
Debug.Log("Unity coroutine end at time : " + Time.time);
}
IEnumerator SelfCoroutine() {
Debug.Log("Self coroutine begin at time : " + Time.time);
yield return new CoroutineWaitForSeconds(5);
yield return CoroutineManager.Instance.StartCoroutineSimple(InnerSelfCoroutine());
Debug.Log("Self coroutine end at time : " + Time.time);
}
IEnumerator InnerUnityCoroutine() {
Debug.Log("Inner Unity Coroutine begin at time : " + Time.time);
yield return new WaitForSeconds(5);
yield return StartCoroutine(DeepUnityCoroutine());
Debug.Log("Inner Unity Coroutine end at time : " + Time.time);
}
IEnumerator DeepUnityCoroutine() {
Debug.Log("Deep Unity Coroutine begin at time : " + Time.time);
yield return new WaitForSeconds(5);
Debug.Log("Deep Unity Coroutine end at time : " + Time.time);
}
IEnumerator InnerSelfCoroutine() {
Debug.Log("Inner Self Coroutine begin at time : " + Time.time);
yield return new CoroutineWaitForSeconds(5);
yield return CoroutineManager.Instance.StartCoroutineSimple(DeepSelfCoroutine());
Debug.Log("Inner Self Coroutine end at time : " + Time.time);
}
IEnumerator DeepSelfCoroutine() {
Debug.Log("Deep Self Coroutine begin at time : " + Time.time);
yield return new CoroutineWaitForSeconds(5);
Debug.Log("Deep Self Coroutine end at time : " + Time.time);
}
执行结果基本如人所料：
不过平心而论，虽然上面的示例实现了类似的Coroutine效果，但是从很多方面来看，Unity自建的Coroutine控制都更好更细致，自己实现的Coroutine则相对粗糙了不少，而且不要忘了，我们目前还不支持WaitForFixedUpdate、WaitForEndOfFrame、WWW这类的特殊类型呢！当然我们可以继续精化程序，但是我毕竟不是一个热爱重造车轮的人，上面的那些个代码也仅是为了学习一下Coroutine的原理，仅此而已，那么就让我们暂时到此为止吧~ ：）
下次再见了~~~
在优势方面，Android平台首先就是其开发性，开发的平台允许任何移动终端厂商加入到Android联盟中来。显著的开放性可以使其拥有更多的开发者，随着用户和应用的日益丰富，一个崭新的平台也将很快走向成熟。本文档为大家整理了一些广大网友喜欢的Android文档，希望对大家学习android开发有所帮助。
《大话企业级android开发》完整版电子书
Android开发教程笔记
《Android 2.0游戏开发实战宝典》清晰影印版
《深入浅出Android--google手持设备应用程序设计》
Android应用框架原理与程序设计(第三简中版)
Android最佳学习路线图
《Android高级编程》中文高清电子版
《andbook》中文版【学习Android的入门级书】
Android 中文API合集（50篇）【chm】
[免豆下载]7本Android编程电子书合集
《Android入门到精通详解》清晰电子版
《Google Android手机游戏设计达人讲座》1-16章电子书
大话企业级android开发全14篇[中文书签高清版pdf]
Android终极开发教程 [PDF电子书]
Android开发问题集锦第1—6期
Android应用开发必备Java基础知识【电子书】
《Android基础教程》PDF电子书（影印版）
android应用开发详解源码下载
Android开发基础教程整理版【PDF】
Android应用框架原理与程序设计36技【PDF】
Android从入门到精通教程（PDF）
Android中文版教程集（exe电子书）
黑马程序员2013年Android培训教程（125集）
经典Android开发源代码大全
Android开发基础视频教程
窗口对象使用点击检测（hit-testing）以及响应链（responder chain） 来查找接收该触摸事件的视图.
iOS系统检测到手指触摸(Touch)操作时会将其放入当前活动Application的事件队列，
UIApplication会从事件队列中取出触摸事件并传递给key window(当前接收用户事件的窗口)处理,window对象首先会使用hitTest:withEvent:方法寻找此Touch操作初始点所在的视图(View),
即需要将触摸事件传递给其处理的视图,称之为hit-test view。
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event; // recursively calls -pointInside:withEvent:. point is in the receiver's coordinate system
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event; // default returns YES if point is in bounds
window对象会在首先在view hierarchy的顶级view上调用hitTest:withEvent:，此方法会在视图层级结构中的每个视图上调用pointInside:withEvent:,如果pointInside:withEvent:返回YES,则继续逐级调用，直到找到touch操作发生的位置，这个视图也就是hit-test view。
The implementation of hitTest:withEvent: in UIResponder does the following:
It calls pointInside:withEvent: of self
If the return is NO, hitTest:withEvent: returns nil. the end of the story.
If the return is YES, it sends hitTest:withEvent: messages to its subviews. it starts from the top-level subview, and continues to other views until a subview returns a non-nil object, or all subviews receive the message.
If a subview returns a non-nil object in the first time, the first hitTest:withEvent: returns that object. the end of the story.
If no subview returns a non-nil object, the first hitTest:withEvent: returns self
This process repeats recursively, so normally the leaf view of the view hierarchy is returned eventually.
However, you might override hitTest:withEvent to do something differently. In many cases, overriding pointInside:withEvent: is simpler and still provides enough options to tweak event handling in your application.
hitTest:withEvent: ===>调用pointInside:withEvent: ===> (point函数返回NO，结束分支，返回nil) // 返回YES ===> (当前view没有subview，hitTest返回self) // 当前view有subviews ===>从subviews的最上层view开始遍历，递归调用hitTest:withEvent:，直到hitTest返回第一个非nil对象 ===>(hitTest:withEvent:)
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
}
这个函数的用处是判断当前的点击或者触摸事件的点是否在当前的view中。
它被hitTest:withEvent:调用，通过对每个子视图调用pointInside:withEvent:决定最终哪个视图来响应此事件。如果 PointInside:withEvent:返回YES，然后子视图的继承树就会被遍历（遍历顺序中最先响应的为：与用户最接近的那个视图。 it starts from the top-level subview），即子视图的子视图继续调用递归这个函数，直到找到可以响应的子视图（这个子视图的hitTest:withEvent:会返回self，而不是nil）；否则，视图的继承树就会被忽略。
当我们需要重写某个UIView的继承类UIViewInherit的时候，如果需要重写hitTest:withEvent:方法，就会出现是否调用[super hitTest:withEvent:]方法的疑问？究竟是否需要都是看具体需求，这里只是说明调与不调的效果。
如果不调用，那么重写的方法hitTest:withEvent:只会调用重写后的代码，根据所重写的代码返回self或nil，如果返回self那么你的这个UIViewInherit类会接受你的按键，然后调用touches系列方法；否则返回nil那么传递给UIViewInherit类的按键到此为止，它不接受它的父view给它的按键，即不会调用touches系列方法。这时，PointInside:withEvent:几乎没有作用。
如果调用，那么[super hitTest:withEvent:]方法首先是根据PointInside:withEvent:的返回值决定是否递归调用所有子View的hitTest:withEvent:方法。对于子View的hitTest:withEvent:方法调用也是一样的过程，这样一直递归下去，直到最先找到的某个递归层次上的子View的hitTest:withEvent:方法返回非nil，这时候，调用即结束，最终会调用这个子View的touches系列方法。
如果我们不想让某个视图响应事件，只需要重载 PointInside:withEvent:方法，让此方法返回NO就行了。