React Native 分析（二）事件驱动

为什么 GUI 是单线程事件驱动的？
不是没人尝试多线程的GUI 框架，只是最终都由于死锁导致的稳定性问题重新回到单线程的事件列队模型。
多线程GUI 框架中更容易发生死锁的一部分原因，是输入事件的处理过程与GUI 组件的面相对象模型之间会存在互相冲突的交互，导致锁定顺序死锁。
另外，一般 MVC 模式中model 和 view 之间的变化消息相互传递，也很容易造成锁定顺序死锁。

一般来讲，一个线程一次只能执行一个任务，执行完成后线程就会退出。如果我们需要一个机制，让线程能随时处理事件但并不退出

function loop() {
    initialize();
    do {
        var message = get_next_message();
        process_message(message);
    } while (message != quit);
}

我们需要一个事件循环，在不同系统中这个循环叫做不同名字，有称呼其为 EventLoop, Looper(Android),RunLoop(iOS)，我们下面拿 iOS中的 RunLoop 继续讲述。

iOS

RunLoop 实际上就是一个对象，这个对象管理了其需要处理的事件和消息，并提供了一个入口函数来执行上面的逻辑。
线程执行了这个函数后，就会一直处于这个函数内部 "接受消息->等待->处理" 的循环中，直到这个循环结束（比如传入 quit 的消息），函数返回。
线程和 RunLoop 之间是一一对应的，其关系是保存在一个全局的 Dictionary 里。线程刚创建时并没有 RunLoop，如果你不主动获取，那它一直都不会有。
RunLoop 的创建是发生在第一次获取时，RunLoop 的自动销毁是发生在线程结束时。

iOS 的显示系统是由 VSync 信号驱动的，VSync 信号由硬件时钟生成，每秒钟发出 60 次。iOS 图形服务接收到 VSync 信号后，会通过 IPC 通知到 App 内。

App 的 Runloop 在启动后会注册对应的 CFRunLoopSource 通过 mach_port 接收传过来的时钟信号通知，随后 Source 的回调会驱动整个 App 的动画与显示。（1秒60次）
在 VSync 信号到来后，系统图形服务会通过 CADisplayLink 等机制通知 App，App 主线程开始在 CPU 中计算显示内容，比如视图的创建、布局计算、图片解码、文本绘制等。随后 CPU 会将计算好的内容提交到 GPU 去，由 GPU 进行变换、合成、渲染。随后 GPU 会把渲染结果提交到帧缓冲区去，等待下一次 VSync 信号到来时显示到屏幕上。由于垂直同步的机制，如果在一个 VSync 时间内，CPU 或者 GPU 没有完成内容提交，则那一帧就会被丢弃，等待下一次机会再显示，而这时显示屏会保留之前的内容不变。这就是界面卡顿的原因。

Core Animation 在 RunLoop 中注册了一个 Observer，监听了 BeforeWaiting 和 Exit 事件。这个 Observer 的优先级是 2000000，低于常见的其他 Observer。
当一个触摸事件到来时，RunLoop 被唤醒，App 中的代码会执行一些操作，比如创建和调整视图层级、设置 UIView 的 frame、修改 CALayer 的透明度、为视图添加一个动画；这些操作最终都会被 CALayer 捕获，并通过 CATransaction 提交到一个中间状态去。当上面所有操作结束后，RunLoop 即将进入休眠（或者退出）时，关注该事件的 Observer 都会得到通知。这时 CA 注册的那个 Observer 就会在回调中，把所有的中间状态合并提交到 GPU 去显示；如果此处有动画，CA 会通过 DisplayLink 等机制多次触发相关流程。
和安卓一样,都是先处理 input 相关事件

系统实现中使用
事件响应
苹果注册了一个 Source1 (基于 mach port 的) 用来接收系统事件，其回调函数为 __IOHIDEventSystemClientQueueCallback()。
当一个硬件事件(触摸/锁屏/摇晃等)发生后，首先由 IOKit.framework 生成一个 IOHIDEvent 事件并由 SpringBoard 接收。这个过程的详细情况可以参考这里。SpringBoard 只接收按键(锁屏/静音等)，触摸，加速，接近传感器等几种 Event，随后用 mach port 转发给需要的App进程。随后苹果注册的那个 Source1 就会触发回调，并调用 _UIApplicationHandleEventQueue() 进行应用内部的分发。
_UIApplicationHandleEventQueue() 会把 IOHIDEvent 处理并包装成 UIEvent 进行处理或分发，其中包括识别 UIGesture/处理屏幕旋转/发送给 UIWindow 等。通常事件比如 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的。

手势识别
当上面的 _UIApplicationHandleEventQueue() 识别了一个手势时，其首先会调用 Cancel 将当前的 touchesBegin/Move/End 系列回调打断。随后系统将对应的 UIGestureRecognizer 标记为待处理。
苹果注册了一个 Observer 监测 BeforeWaiting (Loop即将进入休眠) 事件，这个Observer的回调函数是 _UIGestureRecognizerUpdateObserver()，其内部会获取所有刚被标记为待处理的 GestureRecognizer，并执行GestureRecognizer的回调。
当有 UIGestureRecognizer 的变化(创建/销毁/状态改变)时，这个回调都会进行相应处理。

界面更新
当在操作 UI 时，比如改变了 Frame、更新了 UIView/CALayer 的层次时，或者手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，这个 UIView/CALayer 就被标记为待处理，并被提交到一个全局的容器去。(取代了安卓中的 RootViewImpl角色)
苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件，回调去执行一个很长的函数：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面。这里是生产者,CADisplayLink 是消费者。
函数调用栈:

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
    QuartzCore:CA::Transaction::observer_callback:
        CA::Transaction::commit();
            CA::Context::commit_transaction();
                CA::Layer::layout_and_display_if_needed();
                    CA::Layer::layout_if_needed();
                        [CALayer layoutSublayers];
                            [UIView layoutSubviews];
                    CA::Layer::display_if_needed();
                        [CALayer display];
                            [UIView drawRect];

定时器
CADisplayLink 是一个和屏幕刷新率一致的定时器（其内部实际是操作了一个 Source）。如果在两次屏幕刷新之间执行了一个长任务，那其中就会有一帧被跳过去（和 NSTimer 相似），造成界面卡顿的感觉。在快速滑动TableView时，即使一帧的卡顿也会让用户有所察觉。Facebook 开源的 AsyncDisplayLink 就是为了解决界面卡顿的问题，其内部也用到了 RunLoop。

Android

Android 中的 VSync信号处理，是由Choreographer 来实现的。
Choreographer是线程单例的，而且必须要和一个Looper绑定，因为其内部有一个Handler需要和Looper绑定。
DisplayEventReceiver是一个abstract class，其JNI的代码部分会创建一个IDisplayEventConnection的VSYNC监听者对象。这样，来自EventThread的VSYNC中断信号就可以传递给Choreographer对象了。由图8可知，当VSYNC信号到来时，DisplayEventReceiver的onVsync函数将被调用。
另外，DisplayEventReceiver还有一个scheduleVsync函数。当应用需要绘制UI时，将首先申请一次VSYNC中断，然后再在中断处理的onVsync函数去进行绘制。
Choreographer定义了一个FrameCallback interface，每当VSYNC到来时，其doFrame函数将被调用。这个接口对Android Animation的实现起了很大的帮助作用。以前都是自己控制时间，现在终于有了固定的时间中断。
Choreographer的主要功能是，当收到VSYNC信号时，去调用使用者通过postCallback设置的回调函数。目前一共定义了三种类型的回调，它们分别是：
CALLBACK_INPUT：优先级最高，和输入事件处理有关。
CALLBACK_ANIMATION：优先级其次，和Animation的处理有关。
CALLBACK_TRAVERSAL：优先级最低，和UI等控件绘制有关。

优先级高低和处理顺序有关。当收到VSYNC中断时，Choreographer将首先处理INPUT类型的回调，然后是ANIMATION类型，最后才是TRAVERSAL类型。
为什么 Input 优先级最高?因为 Input 事件最有可能引发界面变化.

Choreographer是Android 4.1中的新事物，下面将通过一个实例来简单介绍Choreographer的工作原理。
假如UI中有一个控件invalidate了，那么它将触发ViewRootImpl的invalidate函数，该函数将最终调用ViewRootImpl的scheduleTraversals

   void scheduleTraversals() {
        if (!mTraversalScheduled) {
            mTraversalScheduled = true;
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            if (!mUnbufferedInputDispatch) {
                scheduleConsumeBatchedInput();
            }
            notifyRendererOfFramePending();
            pokeDrawLockIfNeeded();
        }
    }

scheduleTraversals首先禁止了后续的消息处理功能，这是由设置Looper的postSyncBarrier来完成的。一旦设置了SyncBarrier，所有非Asynchronous的消息便将停止派发。
然后，为Choreographer设置了CALLBACK类型为TRAVERSAL的处理对象，即mTraversalRunnable。
最后调用scheduleConsumeBatchedInput，这个函数将为Choreographer设置了CALLBACK类型为INPUT的处理对象。
Choreographer的postCallback函数将会申请一次VSYNC中断（通过调用DisplayEventReceiver的scheduleVsync实现）。当VSYNC信号到达时，Choreographer doFrame函数被调用，内部代码会触发回调处理。

安卓的代码是开源的，如果感兴趣，可以点击这里scheduleTraversals去参看对应的逻辑