貫穿始終：launchd

當(dāng)你打開(kāi)Mac 或 i-設(shè)備的電源時(shí)，引導(dǎo)加載器（OS X：EFI， iOS: iBoot）開(kāi)始查找內(nèi)核并且啟動(dòng)內(nèi)核。不過(guò)內(nèi)核只是一個(gè)服務(wù)提供者，而不是具體的應(yīng)用程序，用戶態(tài)的應(yīng)用程序才是系統(tǒng)負(fù)責(zé)真正工作的實(shí)體，應(yīng)用程序構(gòu)建在內(nèi)核提供的原語(yǔ)之上，向用戶提供了豐富的用戶態(tài)環(huán)境，包括文件、多媒體和用戶交互。整個(gè)用戶環(huán)境都必須從某個(gè)地方啟動(dòng)，在 OS X 和 iOS 中，用戶環(huán)境始于 launchd。

launchd

OS X 和 iOS 中的 launchd 對(duì)應(yīng)于其他UN*X 系統(tǒng)中的init。 作為系統(tǒng)中的第一個(gè)用戶態(tài)進(jìn)程，負(fù)責(zé)直接或間接地啟動(dòng)系統(tǒng)中的其他進(jìn)程。此外， launchd 還有OS X 和 iOS 特有的特性。盡管launchd 是屬于蘋(píng)果的私有財(cái)產(chǎn)，但是仍然屬于 Darwin 的范疇，因此launchd 也是完全開(kāi)源的。

launchd 是有內(nèi)核直接啟動(dòng)的。負(fù)責(zé)加載 BSD 子系統(tǒng)的主內(nèi)核線程創(chuàng)建一個(gè)線程來(lái)執(zhí)行 bsdinit_task。這個(gè)線程獲得 PID 1，并且臨時(shí)命名為“init”，這是一項(xiàng)來(lái)自BSD的遺產(chǎn)。bsdinit_task 然后調(diào)用 load_init_program( ), 這個(gè)函數(shù)調(diào)用 execve( ) 系統(tǒng)調(diào)用（在內(nèi)核空間中執(zhí)行）執(zhí)行守護(hù)程序，init_program_name 變量的值被硬編碼為/sbin/launchd 這個(gè)名稱。

系統(tǒng)范圍和用戶范圍的launchd

• 系統(tǒng)范圍的lanuchd(PID 1)是不可終止的。事實(shí)上，這個(gè)lanuchd是系統(tǒng)上唯一不朽的進(jìn)程，這個(gè)進(jìn)程是不能被殺掉的。當(dāng)系統(tǒng)關(guān)閉是，launch 也是最后一個(gè)退出的進(jìn)程
• 用戶范圍的launchd 是用戶登錄的時(shí)候執(zhí)行的，通過(guò)SSH 遠(yuǎn)程登錄也會(huì)創(chuàng)建launchd(每登錄一個(gè)就創(chuàng)建一個(gè))。在iOS 上只有一個(gè)launchd實(shí)際，即系統(tǒng)范圍的實(shí)例

守護(hù)程序和代理程序

launchd 的核心職責(zé)是根據(jù)預(yù)定的安排或?qū)嶋H的需要加載其他應(yīng)用程序或作業(yè)，launchd 區(qū)分兩種后臺(tái)類(lèi)型的作業(yè)：

• 守護(hù)程序(deamon)：和傳統(tǒng)的UNIX 概念一樣，是后臺(tái)服務(wù)，通常和用戶沒(méi)有交互。守護(hù)程序由系統(tǒng)自動(dòng)啟動(dòng)，不考慮是否有用戶登錄進(jìn)系統(tǒng)
• 代理程序(agent)：是一類(lèi)特殊的守護(hù)程序，只有在用戶登錄的時(shí)候才啟動(dòng)，和守護(hù)程序不同之處在于：代理程序可以和用戶交互，有的代理程序還有GUI
• iOS 不支持用戶登錄的概念，因此只有 LaunchDaemon(不過(guò)存在一個(gè)空的/Library/LaunchAgents)
• 守護(hù)程序和代理程序都是通過(guò)自己的屬性列表文件（.plist）聲明的，Launchd使用/private/var/db 目錄保存運(yùn)行時(shí)配置文件，創(chuàng)建 com.apple.launchd[.peruser.%fd]文件覆蓋或禁用守護(hù)程序的配置

多面手 launchd

launchd 是用戶態(tài)出現(xiàn)的第一個(gè)進(jìn)程。當(dāng)系統(tǒng)還在啟動(dòng)初期的時(shí)候，launchd 是系統(tǒng)上唯一的進(jìn)程（盡管這個(gè)狀態(tài)很短暫）。這意味著系統(tǒng)啟動(dòng)和功能的方方面面都和launchd 直接或間接相關(guān)。在 OS X 和 iOS 中，launchd 要身兼數(shù)職，而其他UN*X 則會(huì)將這些職責(zé)委派給多個(gè)守護(hù)程序。

• ** init**
  launchd 的第一個(gè)也是最主要的職責(zé)是init 守護(hù)程序。 init 的職責(zé)是派生出各種各樣的后臺(tái)守護(hù)程序，設(shè)置好系統(tǒng)，然后轉(zhuǎn)入后臺(tái)，確保這些守護(hù)程序都活著。如果有程序死亡了，launchd 要負(fù)責(zé)重新派生出新的守護(hù)程序。

• 用戶范圍內(nèi)的初始化
  通過(guò)使用LaunchAgents，launchd 允許用戶加載指定的應(yīng)用程序。代理程序本身可以請(qǐng)求默認(rèn)所有會(huì)話中加載，或只在GUI會(huì)話中加載：將LimitLoadToSessionType 鍵設(shè)置為L(zhǎng)oginWindow或Aqua，或者Background。

• atf/crond
  UN*X 系統(tǒng)上包含兩個(gè)守護(hù)程序：atd 和 crond 來(lái)運(yùn)行定時(shí)作業(yè)。即在指定時(shí)間運(yùn)行指定的命令。第一個(gè)守護(hù)程序 atd 負(fù)責(zé)第一次運(yùn)行的作業(yè)， 是 at( ) 命令的后端引擎。第二個(gè)守護(hù)程序 crond 提供了重復(fù)執(zhí)行作業(yè)的支持。
  蘋(píng)果正在逐步廢棄 atd 和 crond 。 atd 再也不是一個(gè)獨(dú)立的守護(hù)程序，而是launchd 啟動(dòng)的程序。 這個(gè)服務(wù)通常都是禁用的。

• inetd/xinetd
  在 UN*X中，inetd（及其繼任 xinetd）的用途是啟動(dòng)網(wǎng)絡(luò)服務(wù)。這個(gè)守護(hù)程序的職責(zé)是綁定一些端口（TCP 端口 或 TCP 端口），當(dāng)有連接請(qǐng)求到達(dá)的時(shí)候，根據(jù)需要啟動(dòng)相應(yīng)的服務(wù)程序，并且將服務(wù)程序的輸入輸出描述符（stdin、stderr 和 stdout）連接帶對(duì)應(yīng)的套接字。
  launchd 將inetd 的功能結(jié)合到自身，允許守護(hù)程序和代理程序請(qǐng)求某個(gè)指定的套接字。守護(hù)程序只需要在其 plist 文件中設(shè)置Sockets 鍵即可。和inetd 不同之處在于：守護(hù)程序請(qǐng)求的套接字也可以UNIX domain 套接字。iOS 守護(hù)程序lockdownd 通過(guò)這種方式監(jiān)聽(tīng)TCP 端口 62078 和 UNIX 套接字/var/run/lockdownd.sock。

• mach_init
  由于OS X 來(lái)源于 NeXTSTEP，在 OS X 10.4 引入 lanunchd 之前，系統(tǒng)啟動(dòng)過(guò)程是由 mach_init 完成的。這個(gè)守護(hù)程序負(fù)責(zé)派生 BSD 風(fēng)格的init，后者是一個(gè)獨(dú)立的進(jìn)程，現(xiàn)在二者合二為一，成為了launchd。 launchd 繼承了 mach_init 文檔少，但是主要負(fù)責(zé)自舉服務(wù)管理器的職責(zé)。自舉服務(wù)器可以被系統(tǒng)中的所有進(jìn)程訪問(wèn)，其他進(jìn)程通過(guò)指定端口 bootstrap_port 和自舉服務(wù)器通訊。在launchd 出現(xiàn)之前，mach_init 就負(fù)責(zé) bootstrap_server 的職責(zé)。現(xiàn)在 launchd 接替了這個(gè)職責(zé)。在啟動(dòng)的時(shí)候聲明了相應(yīng)的端口（bootstrap_port）。如果服務(wù)端口可用，而且服務(wù)程序已經(jīng)完成登記，那么這個(gè)服務(wù)端口會(huì)返回給客戶程序，客戶程序可以通過(guò)這個(gè)端口發(fā)送和接收信息（利用mach_msg( )）。這個(gè)自舉機(jī)制現(xiàn)在是通過(guò) launchd 的 vproc 實(shí)現(xiàn)的。

• 事務(wù)支持
  launchd 比其他的init 更聰明。 init 只知道啟動(dòng)和停止守護(hù)程序，而 launchd 還支持事務(wù)。事務(wù)是 launchd 的 vproc 庫(kù)引入的新特性。
  守護(hù)程序通過(guò) vproc_transaction_begin 調(diào)用生成一個(gè)事務(wù)句柄，當(dāng)事務(wù)操作結(jié)束時(shí)對(duì)這個(gè)句柄調(diào)用 vproc_transaction_end, 這兩個(gè)調(diào)用之間包含的操作稱之為未決的事務(wù)。啟用事務(wù)的守護(hù)程序可以在 plist 中設(shè)置 EnalbeTransactions 鍵，如果設(shè)置了這個(gè)鍵，launchd 就會(huì)在系統(tǒng)關(guān)閉、用戶退出或超過(guò)指定時(shí)間后檢查未決 的事務(wù)。如果沒(méi)有未決的事務(wù)（進(jìn)程干凈），那么守護(hù)程序就會(huì)被直接殺掉（kill -9）, 而不是優(yōu)雅地終止（kill -15），從而加快關(guān)閉或退出的過(guò)程，或者在一定程度的不活動(dòng)狀態(tài)之后釋放掉系統(tǒng)資源。

• 資源限制和扼制（throttling）
  launchd 可以對(duì)其作業(yè)施行資源限制。一個(gè)作業(yè)（守護(hù)程序或代理程序）可以指定HardResourceLimits 或 SoftResourceLimits 字典，這樣會(huì)導(dǎo)致 launchd 調(diào)用 setrlimit(2)。Nice 鍵可以用于設(shè)置作業(yè)的nice 值，等同于調(diào)用 nice( )。此外，作業(yè)還可以指定LowProtityIO 鍵，導(dǎo)致launchd 調(diào)用iopolicysys，降低作業(yè)的I/O優(yōu)先級(jí)。最后，luanchd 還整合了iOS的Jetsam機(jī)制（也稱為memorystatus），Jetsam機(jī)制可以強(qiáng)制施行虛擬內(nèi)存使用率的限制，這項(xiàng)特性在沒(méi)有交換空間的iOS 中特別重要。

• Autorun模擬和文件系統(tǒng)觀察
  Windows 有一個(gè)著名（往往很惱人）的功能是autorun，在插入可以的媒體（例如：CD、U盤(pán)或硬盤(pán)）的時(shí)候自動(dòng)啟動(dòng)一個(gè)程序。launch 提供了StartOnMount 鍵，當(dāng)一個(gè)文件系統(tǒng)掛載的時(shí)候自動(dòng)觸發(fā)啟動(dòng)一個(gè)守護(hù)程序。這不僅能模擬Windows 的 autorun 功能，而且更加安全。launchd 的守護(hù)程序從持久化文件系統(tǒng)中運(yùn)行，而不是從可移除的文件系統(tǒng)中運(yùn)行。通過(guò)WatchPaths 或 QueueDiretories 鍵，launchd 還可以設(shè)置為觀察一個(gè)特定路徑的變化，這一項(xiàng)功能呢過(guò)非常有用，因?yàn)?launchd 可以實(shí)時(shí)響應(yīng)文件系統(tǒng)的變化。這一項(xiàng)功能是通過(guò)監(jiān)聽(tīng)內(nèi)核事件（kqueue）實(shí)現(xiàn)的。守護(hù)程序還可以進(jìn)一步支持FSEvents，方法是知道一個(gè) LaunchEvents 字典，其中帶有一個(gè)保存了匹配情況的 com.apple.fsevents.matching 字典。

• I/O Kit 整合
  Lion 中的一項(xiàng)新特性就是在 launchd 中整合了 I/O kit。 I/O Kit 是設(shè)備啟動(dòng)程序的運(yùn)行環(huán)境，守護(hù)程序或代理程序可以請(qǐng)求當(dāng)某個(gè)設(shè)備價(jià)值的時(shí)候運(yùn)行，方法是知道一個(gè)LaunchdEvents 字典，其中包含一個(gè) com.apple.iokit.maching 字典。

LunchDaemon 列表

在 OS X 和 iOS 中有大量的LaunchDaemon。所有的plist文件（包括Mach服務(wù)條目）都以com.apple作為前綴，二進(jìn)制可執(zhí)行文件通常放在/usr/libexec 目錄下。
在iOS 中有兩個(gè)特殊的守護(hù)程序：SpringBoard 和 lockdownd。

• lockdownd
  lockdownd 就行用戶態(tài)的獄警，是所有越獄者的頭號(hào)敵人。lockdownd 由 launch 啟動(dòng)，負(fù)責(zé)設(shè)備激活、備份、崩潰報(bào)告、設(shè)備同步以及其他服務(wù)。lockdownd 注冊(cè) com.apple.lockdown.host_watcher Mach 服務(wù)，監(jiān)聽(tīng) TCP 端口 62078 以及 UNIX domain 套接字 /var/run/lockdown.sock。還有一個(gè)小程序/usr/libexec/lockbot 輔助lockdownd。lockdownd 實(shí)際上是一個(gè)迷你launchd. lockdownd 在 /System/Library/Lockdown/Services.plist 文件中維護(hù)了一個(gè)自己要啟動(dòng)的服務(wù)列表。這個(gè)列表中有一個(gè)重要的服務(wù)：afc，這個(gè)服務(wù)負(fù)責(zé)在 iTunes 主機(jī)和 i- 設(shè)備之間傳遞文件。lockdown 和 luanchd一樣 以root 用戶權(quán)限預(yù)先，在運(yùn)行其他進(jìn)程之前，如果指定了UserName 鍵，則會(huì)降低進(jìn)程的權(quán)限。

• SpringBoard
  SpringBoard 是GUI Shell。
  GUI Shell 程序
  當(dāng)用戶在控制臺(tái)登錄（自動(dòng)登錄或通過(guò)輸入憑據(jù)登錄）的時(shí)候，系統(tǒng)會(huì)啟動(dòng)一個(gè)圖形shell婚假，OS X 使用Finder，而iOS 使用的是SpringBoard，不過(guò)這兩個(gè)程序其實(shí)不像表面上看上去差別那么大。從launchd 的角度看。Finder 和 SpringBoard 只不過(guò)是要處理的上百個(gè)守護(hù)程序和代理程序中的一兩個(gè)，但是從用戶的角度來(lái)看，這些程序就是它們和操作系統(tǒng)接觸的第一個(gè)界面（通常也是最后一個(gè)）。

• Finder(OS X )
  OS X 中的Finder 等同于 Windows 在的 Explorer：向用戶提供圖形shell 的功能。成功登錄之后，launchd 以代理程序的方式啟動(dòng)Finder。Finder 和系統(tǒng)的結(jié)合非常緊密，因此原生的文件系統(tǒng)HFS+也是基于Finder 構(gòu)建的。文件和文件夾數(shù)據(jù)，甚至宗數(shù)據(jù)本身都包含了特殊的Finder 信息字段。Finder 還利用擴(kuò)展屬性保存信息，例如色彩標(biāo)簽和替身（alias）。

• SpringBoard(iOS)
  iOS 中的SpringBoard 相當(dāng)于 OS X 中的Finder。在iOS 中不需要登錄系統(tǒng)，因此SpringBoard 自動(dòng)啟動(dòng)。SpringBoard 向用戶提供熟悉的圖標(biāo)界面。

XPC(Lion 和 iOS)

XPC是Lion 和 iOS 5 新引入的輕量級(jí)進(jìn)程間通訊原語(yǔ)，XPC 和 GCD 的結(jié)合非常緊密，XPC 允許開(kāi)發(fā)者將應(yīng)用程序分解為獨(dú)立的組件。這樣可以同時(shí)增強(qiáng)應(yīng)用程序的穩(wěn)定性和安全性，因?yàn)椴环€(wěn)定的功能可以包含在一個(gè)XPC服務(wù)中，而XPC服務(wù)可以在外部進(jìn)行管理，這是launchd非常適合承擔(dān)的另一個(gè)責(zé)任。
就想對(duì)待LaunchDaemons 一樣，launchd 承擔(dān)了按需啟動(dòng)、監(jiān)視（崩潰的時(shí)候重新啟動(dòng)）以及終止（服務(wù)完成或閑置的時(shí)候，通過(guò)粗暴的方式kill -9）XPC服務(wù)的任務(wù)。launchd 通過(guò)xpcd(8)、xpchelper(8) 和 xpcproxy(8) 輔助 XPC 的服務(wù)。launchd 和標(biāo)準(zhǔn)的 Mach 服務(wù)一起管理 XPC 服務(wù)， XPC 服務(wù)在獨(dú)立的XPC域中：per-user、private、singleton。
XPC 服務(wù)程序和客戶程序都鏈接了libxpc.dylib(有的是直接鏈接，有的是通過(guò) Cocoa 鏈接)，libxpc.dylib 提供了各種各樣的C語(yǔ)言層次的XPC 原語(yǔ)（例如Mountain Lion的 NSXPCConnection）。XPC 還依賴于兩個(gè)私有框架：XPCService 和 XPCObjects。前者負(fù)責(zé)處理XPC服務(wù)運(yùn)行時(shí)相關(guān)的事務(wù)，后者為XPC 對(duì)象提供編碼和解碼服務(wù)。iOS 還有一個(gè)包含私有框架 XPCKit。

• XPC 對(duì)象類(lèi)型
  XPC對(duì)各種數(shù)據(jù)進(jìn)行包裝盒序列化，這種方式類(lèi)似于CoreFoundation框架。任何類(lèi)型的XPC對(duì)象都可以處理為不透明的類(lèi)型 xpc_object_t, 并且通過(guò) xpc_object(3)文檔中描述的函數(shù)進(jìn)行操作。這些函數(shù)包括xpc_retain/release、xpc_get_type、xpc_hash（提供對(duì)象的散列值，可以用于數(shù)組索引）、xpc_equal(用于比較對(duì)象)和xpc_copy。

• XPC 消息
  對(duì)象可以通過(guò)消息來(lái)發(fā)送和接收。默認(rèn)情況下消息是異步發(fā)送的，并且通過(guò)分發(fā)隊(duì)列（GCD）處理。通過(guò)使用屏障（barrier），開(kāi)發(fā)人員可以指定一個(gè)代碼塊在某個(gè)連接上的所有消息都發(fā)生完成之后執(zhí)行。發(fā)出器的消息可以有應(yīng)答，應(yīng)答也是異步的，通過(guò)_reply_sync 函數(shù)可以阻塞直到收到應(yīng)答消息。XPC消息是通過(guò)Mach 消息機(jī)制實(shí)現(xiàn)的，并且使用了Mach Interface Genetator(MIG)實(shí)施。后者提供了xpc_domain子系統(tǒng)。xpc_domain 子系統(tǒng)包含用于登記、加載或添加服務(wù)以及獲得服務(wù)名稱的消息。 下面是xpc_connection_send_message 流程：

xpc_connection_sent_message 流程.png

• XPC 服務(wù)
  XPC 服務(wù)可以通過(guò)Objective-C 或C或C++創(chuàng)建。不管通過(guò)哪種語(yǔ)言創(chuàng)建，都需要調(diào)用 libxpc.dylib 庫(kù)的 xpc_main 函數(shù)開(kāi)始服務(wù)。C/C++ 的 服務(wù) mian 函數(shù)只不過(guò)是一個(gè)簡(jiǎn)單的包裝函數(shù)，它調(diào)用xpc_main，并傳入時(shí)間處理函數(shù)（xpc_connection_handler_t）。Objective-C服務(wù)也調(diào)用xpc_main，不過(guò)是通過(guò)NSXPCConnection_t的resume方法間接調(diào)用的。
  事件處理函數(shù)接受單獨(dú)一個(gè)參數(shù)：xpc_connection_t(Objective-C 將這個(gè)對(duì)象封裝為Foundation.framework 框架中的 NSXPCConnection)。XPC 連接是一個(gè)不透明的對(duì)象，需要通過(guò)xpc_connection_*函數(shù)進(jìn)行操作。
  XPC服務(wù)程序的一般架構(gòu)包括：調(diào)用dispatch_queue_create 創(chuàng)建一個(gè)隊(duì)列用于接收來(lái)接收自客戶程序的消息，然后通過(guò)xpc_connectiona_set_target_queue 將這個(gè)隊(duì)列分配給連接。服務(wù)程序還有設(shè)置連接的時(shí)間處理程序：調(diào)用 xpc_connection_set_event_handle 并提供一個(gè)表示處理程序的代碼執(zhí)行（代碼本身也可以包裝其他函數(shù)）。每當(dāng)服務(wù)程序收到一條消息的時(shí)候都會(huì)調(diào)用這個(gè)處理程序。服務(wù)程序可以創(chuàng)建一個(gè)應(yīng)答（通過(guò)調(diào)用 xpc_dictionary_create_reply）并將應(yīng)答消息發(fā)送出去。

• XPC 屬性列表
  XPC 的服務(wù)定義在自己的bundle 中，這個(gè) bundle 包含在其父應(yīng)用程序或框架的XPCServices 子目錄中。和所有的bundle 一樣，XPC 服務(wù)的bundle 也有一個(gè)Info.plist 文件，這個(gè)文件的作業(yè)是聲明各種服務(wù)屬性和需求：

• CFBundlePackageType 屬性定義為“XPC!”

• CFBundleIdentifier 屬性定義了XPCService的名稱。這個(gè)名稱設(shè)置為何bundle名稱一樣的值。

• ** XPCService** 屬性定義了一個(gè)字典，這個(gè)字典包含一個(gè)ServiceType 屬性（可取值為Applicaton、User和System）以及RunLoopType(可取值為dispatch_main和 NSRunLoop)，RunLoopType定義了xpc_main( ) 的運(yùn)行循環(huán)風(fēng)格。這個(gè)字典可能還包含一個(gè)JoinExit\stingSession布爾屬性，將XPC服務(wù)的審計(jì)重定向到應(yīng)用程序已有的審計(jì)會(huì)話。

• XPCService 字典還可以用于指定其他的屬性，采用下劃線作為前綴。其中包_SandboxProfile(允許指定XPC服務(wù)采用的一個(gè)沙盒profile)，_AllowedClients(指定允許連接到服務(wù)的應(yīng)用程序標(biāo)識(shí)符)