起底 iOS 应用启动-内核篇

本文会主要讲述一下 App 启动过程，系统做的一些事情。

1 iOS 系统架构

iOS 系统可以分为四层，从下往上介绍：

第一层是 Darwin 层，是操作系统的核心，属于操作系统的内核态，包括了系统内核 XNU，驱动等，是开源的，可在 opensource.apple.com 找到。
第二层是核心框架层，包括 Metal、OpenGL 等。
第三层是应用框架层，比如 Cocoa Touch 框架。
第四层是用户体验层，包括用户能接触到的图形应用，如 SpringBoard（桌面系统，统一管理和分发系统接收到的触摸事件）、Spotlight。

iOS 系统架构-摘自戴铭博客

上面提到 Darwin 层属于操作系统的内核态，而其余的三层，核心框架层、应用框架层、用户体验层属于用户态。

Darwin 的内核是 XNU，全称'XNU’s Not UNIX'。下面会着重介绍一下 XNU。如上图所示，XNU主要由 Mach、BSD、IOKit 组成。

Darwin 层架构

3 Mach

3-1 Mach 基本介绍

Mach 是 XNU 内核的内环，属于微内核，只提供了处理器调度、进程间通信（IPC）、内存保护、虚拟内存管理、进程和线程的抽象等功能。

3-2 IPC

Mach 的核心功能是 IPC。此外在 Mach 中，所有东西都是属于对象范畴的，比如进程、线程、虚拟内存。对象间是不能直接相互调用的，必须通过消息传递的方式实现，消息会在两个端口之间传递。当处于用户态的核心框架层、应用框架层、用户体验层需要进行系统调用的时候，会调用 mach_msg_trap() 触发陷阱机制，切换到内核态，内核态中实现 mach_msg() 函数完成最后的工作。具体过程如下：

摘自YY大神博客

RunLoop 的核心就用到了 mach_msg()，当没有接收到 port 消息时，内核会将线程置为等待状态，节省资源。

又比如说，在 Xcode 中运行一个 App，点击调试栏中的暂停按钮，可以看到主线程调用栈停留在 mach_msg_trap()。

4 BSD

Mach 本身提供的 API 有限，额外功能需要 BSD 来实现，BSD 可以看做围绕 Mach 层的一个外环，提供了更高层次的抽象，提供了进程管理、文件系统、网络诸多功能。属于宏内核。

5 IOKit

IOKit 是硬件驱动程序的运行环境，包括电源、内存、CPU 等信息。为设备驱动提供了一个面向对象（C++）的框架。

这里简单讲一下 IOKit、SpringBoard 在触摸事件中起到的作用：

用户触摸屏幕，屏幕硬件将事件通过 mach port 发送给 IOKit
IOKit 将触摸事件封装成 IOHIDEvent 对象，通过 mach port （进程端口通信）传递给用户体验层的 SpringBoard
SpringBoard 会判断，如果在桌面，则触发 SpringBoard 主线程的 RunLoop 的 source0 回调
如果是在应用呢，将触摸事件通过 IPC 传递给应用（source1），source1 唤醒 RunLoop，将事件分发给 source0，_UIApplicationHandleEventQueue 将 IOHIDEvent 包装成 UIEvent 向下分发

6 Mach、BSD 和微内核、宏内核、混合内核

前面的内容提到 Mach 属于微内核，BSD 属于宏内核，那为什么要这样安排呢？这里简单解释一下。

在微内核中，用户服务和内核服务是在不同的地址空间实现的。因此在用户态如果要进行系统调用的话，需要通过消息传递的方式进行通信，随之带来的缺点是消息传递会造成执行速度变慢。

优点：

健壮性：用户服务和内核服务是相互独立的，用户服务的崩溃不会影响到内核服务。
扩展性强：添加新的功能，只需要建立一个新的服务到用户空间即可，内核空间不需要做出修改。
占用内存小：内核是常驻内存当中，因为内核服务只有一些最基本的功能，所占内存空间小。

而在宏内核中，用户服务和内核是在同一空间中实现的。因此不需要经过消息传递，执行速度比微服务快。但是微内核所拥有的优点，则变成了宏内核的劣势。

既然微内核和宏内核，各自有优点，那何不把两个结合一下，各取所长呢。这就是混合内核了。大致做法是，混合内核会把一些不经常使用的内核模块从内核中移出，从而降低了内核的复杂程度。

XNU 采用的就是微内核 Mach 和宏内核 BSD 的混合内核。

7 XNU 加载 App

介绍完 iOS 的系统架构以及 Darwin 的内核 XNU。我们就开始将 iOS 应用启动期间发生的那些事。

启动程序可以总体概括为以下几个步骤：

Kern 创建进程，并装载主程序和 dyld，设置栈环境，最后将启动的任务交给 dyld
根据栈环境，dyld 自举(bootstrap)，最后传递给 dyld 主函数
dyld 链接主程序，进行核心系统库、objc 自举，最后交给主程序的主函数
主程序进入 main 函数，开始主程序的运行

在这里，我们先讲讲在 App 启动过程中，Kernel 内核加载部分，也就是上面说到的第一个步骤。

XNU 首先加载作为可执行文件的 Mach-O 文件来完成的。Mach-O 文件可以在 ipa 中找到。

7-1 Mach-O

首先我们来看一下 Mach-O 文件的结构，可以使用 MachOView 解析。

MachOView 截图

Mach-O 文件主要包含了三部分信息，Header、Load Command、Data。

Header 里包含 CPU 信息，以及 Load Command 的信息，告诉你如何加载 Command。

Load Command 的作用是告诉操作系统应当如何加载文件中的 Data。系统内核 Kernel 和动态链接器 dyld 都会使用到。

7-2 加载过程

内核在加载过程中，主要干了下面这些事：

fork 新进程（UNIX 特性）
为 Mach-O 分配内存
加载解析 Mach-O 文件
读取 Mach-O Header
根据 Header 中关于 Command 的信息，遍历Command 并执行部分 Command（如分配虚拟内存，创建主线程，代码签名检查），将 Mach-O 映射到内存
从内核态切换至用户态的 Dyld 继续加载

从源码地址，可以找到入口函数 execve。

感兴趣的同学，可以依照下面的代码调用顺序，大致看一看每个函数的实现，这样子对整个过程会有更深刻的理解。

execve
__mac_execve
exec_activate_image
ex_imgact 调用 exec_mach_imgact
load_machfile
parse_machfile

这里，选择几段重要的源码来介绍一下，先来看看其中的 __mac_execve 函数。

int __mac_execve(proc_t p, struct __mac_execve_args *uap, int32_t *retval)
{
    // 1. 申请内存
    MALLOC(bufp, char *, (sizeof(*imgp) + sizeof(*vap) + sizeof(*origvap)), M_TEMP, M_WAITOK | M_ZERO);

    // 2. 根据入参 uap 的字段初始化 imgp 的参数
    imgp->ip_user_fname = uap->fname;
    ......

    // 3. fork 子进程
    imgp->ip_new_thread = fork_create_child(old_task,
                                        NULL,
                                        p,
                                        FALSE,
                                        p->p_flag & P_LP64,
                                        task_get_64bit_data(old_task),
                                        TRUE);
    // 4. 加载解析 Mach-O 文件
    error = exec_activate_image(imgp);

    // 5. 设置进程的主线程
    thread_t main_thread = imgp->ip_new_thread;
}

再看看 parse_machfile 函数。

static
load_return_t
parse_machfile(...)
{
    // 将 Mach-O 中 load commands 加载进 kernel
    addr = kalloc(alloc_size);
    ...

    // 遍历所有 commands，处理需要的部分
    while (ncmds--) {
        // 根据 header 的信息去获取 command， 进行加载
        ncmds = header->ncmds;
        // 通过一个起始地址加上偏移量来获取 command 指针
        lcp = (struct load_command *)(addr + offset);
        switch(lcp->cmd) {
        case LC_SEGMENT_64:
                  // 是最主要的加载命令，指导内核如何设置新运行的进程的内存空间
                  // 将文件中的段映射到进程地址空间
                  ......
                 load_segment(......);
                  ......
        case LC_MAIN:
                  // 初始化栈布局和寄存器
                  ......
                  load_main(......);
                  ......
        case LC_LOAD_DYLINKER:
                  // 注意这里只是通过强转获取 command 指针，没有 load
                  ......
                  dlp = (struct dylinker_command *)lcp;
                  ......
        case LC_UUID:
                  // Kernel 将 UUID 复制到内部表示 mach 目标的数据中
                  // 一个唯一的 128 位 ID，匹配一个二进制文件及对应的符号
                  ......
                  ret = load_uuid((struct uuid_command *) lcp,
                            (char *)addr + cmds_size,
                            result);
                  ......
        case LC_CODE_SIGNATURE:
                  // Mach-O 包含了代码签名，如果签名和代码本身不匹配，内核会立刻将进程杀死
                  ......
                  ret = load_code_signature(
                    (struct linkedit_data_command *) lcp,
                    vp,
                    file_offset,
                    macho_size,
                    header->cputype,
                    result,
                    imgp);
                  ......
          case LC_ENCRYPTION_INFO:
                  // 加密的二进制文件
                  ......
                  ret = set_code_unprotect(
                    (struct encryption_info_command *) lcp,
                    addr, map, slide, vp, file_offset,
                    header->cputype, header->cpusubtype);
                  ......
        }
    }

    if (ret == LOAD_SUCCESS) {
        ......
        // 当其他命令全部加载成功后，最后执行调用 dyld
        ret = load_dylinker(dlp, dlarchbits, map, thread, depth,
                        dyld_aslr_offset, result, imgp);
    }
}

接下来启动的任务，就交到 dyld 手上。下一篇文章会说说 dyld。