iOS 中的手势传递（一）操作系统层

这是一篇在草稿箱里存了很久的文章，本来想写一个大而全的手势文章，可惜迟迟没有完结，索性还是先把前面写好的部分发出来了。

一般咱们处理手势是在 UIView 层级，直接运用 UIButton、UIGestureRecognizer 等来捕获手势，而本文要点讲的是在此之前，手势识别与传递的进程，在介绍整个进程的一起，也能对整个操作体系的工作方式有必定的了解。

别的附上 Github 本文地址 以及 我的其他文章合集

目录

第一步：I/O Kit

手机触屏原理

咱们首先来讲讲接触手势最开端在物理层面上是怎么被触发和检测的。

手机屏幕完结触屏的原理大约有分为两种，电容屏和电阻屏；其间电容屏尽管价格更为贵重，但精度更高，可完结多点触控，以及维护、清洁都更方便，因而也是主流的计划。

电容屏的大约原理简略来说，整块屏幕便是一个大的电容器。依据中学物理常识，电容器实际上便是一个贮存电荷的电子元件，人体也能够传导弱小的电流；当人的手指触碰到电容器，人的手指就会变成电容器的一极，部分的电荷就会从人的手指处丢失，然后被屏幕探测到接触动作。

注 1：这也是为什么冬天戴手套时无法运用接触屏幕的原因，因为绝大部分手套是绝缘体，无法成为电容器的一极，不会产生电荷的流动，因而无法被电容屏探测到接触操作。

注 2：而有些安卓手机设置有手套形式，戴着手套也能运用触屏。这个首要是因为当电压满足的情况下，电荷的传到也能穿透必定的绝缘电阻。因而敞开了手套形式后，电容屏功率加大，即使戴着较薄手套，也能产生电荷的搬运。

而 iPhone 采用的是投射电容（Projected-Capacitive）式电容屏，总共首要有四层，一层接触层，两层导电层，和一层隔离层，大致结构如下：

比较旧的论文里的信息，假如有最新的欢迎留言沟通~

其间最上层通明的 touch surface 是接触层，首要起维护作用，防止手指直接接触到基层结构。绿色 ITO 是导电玻璃层，中心黄色是绝缘层，这三层结构就构成了电容器。当手指触碰到接触层时，就会产生电荷从电容器到人手指的搬运，然后被屏幕捕获。

注：有些时分除了这些结构，最基层还会有额外的一层 ITO 导电玻璃层，首要用于减少显现屏的噪声（noise）。

而屏幕怎么捕获详细的接触坐标呢？实际上刚才说的两层 ITO 导电玻璃，别离担任探测接触点的横纵坐标：

参阅上图，两层别离都按横纵方向分布有联锁钻石（Interlocking Diamonds）形状，别离担任探测接触点的横纵坐标，两者结合之后能够计算出详细的接触点坐标。

CPU 架构与 I/O 总线

其实看完上一末节，咱们知道手机接触屏关于体系内核来说，实际上便是一个外接的物理设备。而这个设备是怎么与 CPU 衔接起来的呢，这就要从计算机组成与 I/O 总线说起。在现代 CPU 架构中有一个总线（Bus）的概念，用于数据的传输：

在物理层面上，总线能够被拆分为三条线路，别离是数据线（Data Bus）、地址线（Address Bus）和操控线（Control Bus）。别离用于数据的传输、地址的索引，以及详细传输操作的操控。在这样的结构支撑下，总线衔接的各个设备之间，经过”上下车“的机制，就能将需求数据在各个设备中传递。

而在现代 CPU 的架构中，存在多个总线结构，首要包括体系总线、内存总线和 I/O 总线，整体结构大约如下所示：

从图中能够看到，I/O 总线衔接了各个设备，关于计算机来说便是诸如键盘鼠标、显现器、硬盘等；另一方面它与 I/O 桥接器（I/O Bridge）相连，就能完结设备与 CPU、内存的数据连通了。

什么是 I/O Kit

经过了上面的说明，大约能知道 I/O Kit 的作用是什么了。

The I/O Kit is a collection of system frameworks, libraries, tools, and other resources for creating device drivers in OS X. It is based on an object-oriented programming model implemented in a restricted form of C++ that omits features unsuitable for use within a multithreaded kernel. By modeling the hardware connected to an OS X system and abstracting common functionality for devices in particular categories, the I/O Kit streamlines the process of device-driver development.

— Apple Documentation

依据 Apple 的官方文档，I/O Kit 简略来说便是衔接体系与硬件的中心结构。它能供给以及简化在 OS X 体系上依赖硬件的开发进程，以及支撑 iOS 的底层调用。尽管关于 iOS 来说经过 I/O Kit 进行内核编程的时机十分有限，可是也有经过其完结对电池电量监控的相关实践。

也因而可想而知，其实 I/O Kit 所处的方位应该坐落体系较为底层的当地。关于 iOS 体系（以及 OS X）来说，如图所示，大约能够分为下面四层。其间操作体系核心 Darwin 包括内核和 UNIX shell 环境，I/O Kit 也坐落其间。

IOHIDFamily

首先需求说明的是，I/O Kit 既适用于 OS X 也适用于 iOS，可是因为苹果对 iOS 运用 I/O Kit 的限制，因而在揭露文档中大部分都是针对 OS X 所写，和 iOS 有必定的区别。

I/O Kit 中一切类的祖先都是 OSObject 类，而苹果界说了一些设备的 Family（”族”），都继承于 OSObject，别离完结了一些通用的驱动程序。这样说起来还是有点笼统，说一些常见的族就大约能了解了：

参阅：IOKit Fundamentals – I/O Kit Family Reference

• IOUSBFamily：通用 USB 设备
• IOAudioFamily：一切音频设备
• IONetworkingFamily：供给对无线网络衔接的支撑
• IOGraphicsFamily：通用图形适配器，支撑屏幕显现

而咱们需求关注的是 IOHIDFamily，他的全称是 Human Interface Device。依据官方文档的说明，它担任衔接与用户交互的驱动设备，比方键盘鼠标等：

The Human Interface Device (HID) class is one of several device classes described by the USB (Universal Serial Bus) architecture. The HID class consists primarily of devices humans use to control a computer system’s operations.

Examples of such HID class devices include: Keyboards and pointing devices such as mice, trackballs, and joysticks…..

依据针对 OS X 的这些描述，咱们也能很容易地推断出，IOHIDFamily 在 iOS 体系上也担任了触屏事情的处理。实际上，IOHIDFamily 会创立一个 IOHIDEventSystem 方针，其间包括多个 IOHIDEventService，是用来向外分发事情的完结类：

参阅：IOHIDEventService – Apple

IOHIDEventService: The base class for implementing a device or operating system service that dispatches events to the system.

而在此基础之上，IOHIDFamily 界说了多种事情（实质是一个 IOHIDEvent 方针），全部都经过 IOHIDEventService 向外分发，包括键盘（dispatchKeyboardEvent）、鼠标准确点击（dispatchAbsolutePointerEvent）、鼠标滚轮（dispatchRelativeScrollWheelEvent）等，而其间咱们就能找到咱们所关怀的触屏点击事情：dispatchDigitizerTouchEvent。

进一步的，咱们能够看到 dispatchDigitizerTouchEvent 的声明：

virtual kern_return_t
dispatchDigitizerTouchEvent(uint64_t timeStamp, IOHIDDigitizerTouchData *touchData, uint32_t touchDataCount);

其间，touchData 是一个包括多个接触信息（IOHIDDigitizerTouchData）的数组，每个接触信息都对应屏幕上一个手指的接触，包括详细的接触点坐标、坐标变化等信息。看到这儿，已经有一种恍然大悟的感觉了，这不便是 UIEvent 和 UITouch 的联系在底层的对应吗？

所以总结一下，整个内核处理触屏的整个进程大约如图所示：

第二步：backboardd

SpringBoard 与 backboardd

Daemons 程序是 iOS/OS X 操作体系内的核心程序，这类程序一直在后台运转，一般拥有更长的生命周期。

SpringBoard 是 iOS 体系内一个特别的看护程序（Daemon），而 SpringBoard 首要担任 iOS 设备的 UI 支撑。当体系发动后，它会发动一个图形 Shell 环境，支撑丰富的 GUI，这在 OS X 上是 Finder，而在 iOS 上便是 SpringBoard。

SpringBoard 首要职责是担任展示 UI，比方每次创立 GUI 时 SpringBoard 都会遍历 var/mobile/Applications 中的一切应用，然后创立对应的图标展示在主屏幕上。与此一起，SpringBoard 也会担任 iOS 中每个类型的操作，担任将 UI 事情分发到应用程序。而假如 SpringBoard 被暂停，任何 UI 操作都不会被分发到应用程序；假如 SpringBoard 超过几分钟不呼应，体系将会被 watch dog 重启。

SpringBoard 大家可能相对了解，不过从 iOS 6 开端，关于点击事情相关的使命被移交给了另一个 Daemon 程序担任：backboardd（也便是 BackBoard），backboardd 就担任点击事情从硬件到 app 之间的衔接。

当然 backboardd 和 SpringBoard 也会有相互通讯的才干，经过 BackBoardServices.framework 简略封装就能够相互通讯。

backboardd 接纳事情

Mach 是 OS X 以及 iOS 中最核心的部分，仅处理最重要的使命，包括：进程和线程笼统、使命调度、进程间通讯和音讯传递、虚拟内存管理。在 Mach 中，音讯会在两个端口 Port 之间传递，方针之间经过各自注册、担任端口，再经过端口传递音讯来完结相互之间的通讯。

内核通讯都经过 Mach 音讯在 port 之间传递，这部分才干首要由 SpringBoard 供给，SpringBoard 会要求注册不少的 port，其间最重要的是 PurpleSystemEventPort 这个端口，这个端口会接纳硬件事情。

SpringBoard 能够接纳来自 I/OKit 的音讯，而接纳方式便是前文说到的 IOHIDEvent。IOHIDEvent 总共界说了 20 种事情，而 SpringBoard 只接纳其间的 4 种：

• keyboard：关于 iOS 设备来说，这个事情对应的不完全对应键盘输入，而是按钮事情，比方：静音按钮、锁屏按钮、音量键等。
• digitizer：包括上文说到的触屏事情
• accelerometer：加快计事情，包括转屏事情
• proximity：间隔事情，一般是需求搭配蓝牙设备，当间隔小于必定程度是触发事情，然后完结一些类似于主动解锁之类的功能。

而当 SpringBoard 经过 port 接纳到音讯之后，会进一步告诉到 backboardd，由 backboardd 来进行封装和分发。

backboardd 分发事情

backboardd 接纳到音讯后，会将事情封装为 GSEvent，然后经过传递 GSEvent 来传递 UI 事情。这儿的 GSEvent 当然也不只包括接触事情，也包括上一末节说到的按钮、加快计等事情，详细能够参阅 GSEvent 事情列表。

在封装时，backboardd 也会担任获取到当时的进程，然后完结将手势直接分发给方针 app 进程。

GSEvent 实际上是 GraphicsServices.framework 中关于 UI 事情的开始封装，也是 UIEvent 的基础。一个 GSEvent 会包括下面这些信息：事情的类别、事情的触发方位和时刻、触发事情的进程，以及应该接受 GSEvent 的进程。

总体而言，上一末节最终说到的 IOHIDEvent 会被传递到 backboardd 中，在此之后就会由 backboardd 封装成 GSEvent 来分发给应用程序。详细进程能够参照下图：

注：

网上之前有许多文章说 IOHIDEvent 经过 SpringBoard 中转后，仍是以 IOHIDEvent 被传递给当时的应用程序，但我对这一点表明怀疑，因为 SpringBoard 分发的 UI 事情应该是以 GSEvent 的方式（除了极少数如陀螺仪、磁力计事情）。

与此一起，GSEvent 也比 IOHIDEvent 包括更多的信息（参阅 IOHIDEvent.h 和 GSEvent.h），也包括直接计算 CGPoint 等的办法，所以推测它应该是更高一级的封装。

但实际上关于 IOHIDEvent 到 GSEvent 的封装，这儿我查了许多材料，可是没有找到特别清晰说明这个流程的文章，上述观念只是依据许多查阅到的材料归纳而成。大家假如有了解的，能够相互沟通~

第三步：Run Loop

RunLoop 机制

一般关于一个进程来说，一个线程一次只能对应一个使命，履行完结后线程就会退出。但这种单一事情的形式不适合体系关于手势的呼应，这时分就需求 Event Loop 的模型，在 iOS 中便是 Run Loop。

Event Loop 是一种常见的设计形式，Run Loop 实质上也是 event loop。

在 app 中，每一个线程都会依靠一个 Run Loop，而主线程的 Run Loop 便是所谓的 main event loop，而它的最首要特色之一在于它会接纳并处理底层操作体系产生的接触事情。底层接触事情会被操作体系分发进入一个事情处理行列 Event queue，依照先进先出 FIFO 的规则被主线程 Run Loop 处理。

一个 app 发动后，会敞开主线程 Run Loop，之后接触事情就会被 Run Loop 上的 input source 接纳，之后 app 会将这个接触事情转换成对应的方针，关于 iOS 是 UIEvent，而关于 OS X 是 NSEvent。

What distinguishes the main event loop is that its primary input source receives events from the operating system that are generated by user actions—for example, tapping a view or entering text using a keyboard.

而主线程 Run Loop 和其他线程 Run Loop 的最首要区别之一便是，主线程 Run Loop 上的 input source 能够接纳操作体系检测并生成的交互操作（比方点击 View 或者运用键盘）。

Run Loop 监听事情

Run Loop 中的 CFRunLoopSourceRef 类担任触发事情，它有两个版本，Source0 和 Source1：

• Source0 包括一个回调函数（实际上是一个指针），担任经过回调函数向应用层传递事情。它并不能主动触发事情，Source0 被标记后需求唤醒 RunLoop 才干处理这个事情。
• Source1 同样包括一个回调函数（指针），一起也包括一个 mach port 端口。因为内核通讯都经过 Mach 音讯在 port 之间传递，所以 Source1 会担任接纳内核的事情，一起经过回调函数唤醒 Run Loop。

假如咱们给 Xcode 添加一个 __IOHIDEventSystemClientQueueCallback 的符号断点，咱们就能够发现一些端倪：

实际上，app 发动后会敞开一个 com.apple.uikit.eventfetch-thread 的子线程，这个子线程会注册一个 source1，用于接纳来自 backboardd 的 GSEvent 事情。而他的回调函数名字便是：__IOHIDEventSystemClientQueueCallback。

而主线程 RunLoop 中注册了一个 source0 事情，其回调函数便是 __eventQueueSourceCallback，这个函数会担任将 GSEvent 包装转化成 UIEvent，成为后续一系列咱们熟知的流程的基础。

当咱们窥探 UIKitCore 的私有头文件，找到 UIEvent.h（xybp888/iOS-Header – UIEvent.h）时，咱们不难发现 UIEvent 中有一个初始化办法，也能佐证 GSEvent 与 UIEvent 之间的联系：

- (id)_initWithEvent:(struct __GSEvent *)arg1 touches:(id)arg2;

因而整个流程就较为清楚了，backboardd 会将 GSEvent 经过特定 port 告诉到当时 app 进程的 eventfetch-thread 子线程（source1），而 eventfetch-thread 会将主线程 RunLoop 中的 source0 事情标记为 pending 状况。而此 source0 担任 UIEvent 的封装与分发。

第四步：UIApplication

UIApplication 是一个 iOS app 的核心，app 发动时体系就会调用 UIApplicationMain 办法，然后创立一个 UIApplication 的单例（这也是第一个被创立的方针）。这个单例方针会处理最初的用户事情，分发音讯，以及管理 UIView 视图层级。

如下图所示，UIApplication 方针也担任管理 Main Event Loop，也便是前文第三步中担任接纳体系音讯的主线程 Run Loop，因而这儿便是衔接底层操作体系与上层 app 之间的纽带。UIApplication 中也有一个 sendEvent:，担任将 UIEvent 事情分发传递给最合适的呼应者，一切操作体系传递来的 UIEvent 接触事情，都会经过这个办法进行分发调度。

与此一起 UIApplication 也声明了一个协议 UIApplicationDelegate，当 app 接纳到一些体系层级的重要 runtime 事情，比方发动、低内存提醒、app 中止、体系告诉等，就会告诉到相关的办法。以及 UIApplication 会要求 app 供给一个 UIWindow，作为一切视图层级的根节点。

因而能够清晰的看到 UIEvent 从体系底层传递给 app 的详细途径：UIApplication 在 app 发动时被创立，一起敞开并管理了主线程 Run Loop，在接触事情产生时接纳 UIEvent 事情信息，调用 sendEvent: 办法，经过 UIApplicationDelegate 传递给根节点处的 UIWindow 以及基层其他的 UIView。

第五步：App 内的事情传递

这部分就到了大家了解的阶段了，本文也就先到此为止了~

最终，本文中有不少细节网上的材料相对较少，假如大家有更深化的了解，欢迎留言沟通。

参阅文献

• 计算机组成原理——原理篇 IO（上）- 小萝卜鸭
• Projected-Capacitive Touch Technology
• Apple – IOKit-fundamentals
• Apple – IOKit Fundamentals – I/O Kit Family Reference
• PhoneWiki – IOHIDFamily
• 浅显易懂iOS体系内核（1）— 体系架构 — darcy87)
• PhoneWiki – GSEvent
• PhoneWiki – backboardd
• Chapter 4. Event Handling and Graphics Services
• Apple – main event loop
• 深化了解RunLoop – ibireme
• xybp888/iOS-Header – UIEvent.h
• iOS App Life Cycle – Xiao Jiang
• iOS 从源码解析Run Loop (九)
• iOS RunLoop应用剖析—本来这些都在运用RunLoop