iOS通过sysctl获取应用线程启动时间为何有时远超实际时长？

我通过sysctl获取应用进程启动时间，用来计算应用后台启动（比如接到来电触发）时的preMain时长。大部分时候数据正常，在数百毫秒左右，但偶尔会出现时长极长的情况（比如数十秒），而且重启手机后测试，出现该问题的概率会更高。

现有实现代码 #

// Code in main.swift
let appStartLaunchTime: CFAbsoluteTime = CFAbsoluteTimeGetCurrent()

// Calculate preMain time
var preMain = appStartLaunchTime - appLaunchTime! + kCFAbsoluteTimeIntervalSince1970

public var appLaunchTime: Double? = {
    var processInfo = kinfo_proc()
    var size = MemoryLayout<kinfo_proc>.stride
    var mib: [Int32] = [CTL_KERN, KERN_PROC, KERN_PROC_PID, getpid()]
    guard sysctl(&mib, u_int(mib.count), &processInfo, &size, nil, 0) == 0 else {
        return nil
    }
    let startTime = processInfo.kp_proc.p_starttime
    let time = (Int64(startTime.tv_sec) * 1000) + Int64(startTime.tv_usec / 1000)
    return Double(time) / 1000.0
}()

问题根源 #

1. 进程创建时间≠实际执行时间：kp_proc.p_starttime是内核创建进程的时间，但后台启动场景下，系统可能先创建进程并将其挂起，直到触发事件（如来电）才调度进程执行代码。此时计算出的preMain会包含进程挂起等待的时间，导致数值异常偏大。
2. 重启后系统调度特性：重启手机后，系统后台进程较少，内核可能更频繁地创建进程后暂不调度，或者初始化阶段存在资源竞争，使得进程挂起等待的概率升高，进而更容易出现异常时长。

修正方案 #

要准确计算preMain时长，需聚焦进程真正开始执行代码的时间点，而非依赖内核的进程创建时间，优化方式如下：

1. 使用系统原生API获取准确启动时间（iOS 13+）

ProcessInfo提供了processStartTime属性，能直接获取进程开始执行的时间，避免sysctl的偏差：

// Code in main.swift
let mainEntryTime = CFAbsoluteTimeGetCurrent()

// 获取进程实际启动时间并计算preMain时长
if let processStartTime = ProcessInfo.processInfo.processStartTime {
    let preMainDuration = mainEntryTime - processStartTime
    print("preMain时长：\(preMainDuration * 1000) 毫秒")
}

2. 兼容低版本的替代方案

如果需要适配iOS 13以下版本，可在main函数第一行直接记录基准时间，以此作为进程执行的起始点计算preMain耗时。这种方式无法追踪系统触发启动到进程执行的等待时间，但能准确统计进程执行后的preMain阶段耗时。

关键说明 #

后台启动场景下，系统的进程调度策略是导致异常数值的核心原因——进程被创建后可能处于休眠状态，直到触发事件到来才被唤醒，p_starttime与实际执行时间的差值是休眠等待时间，并非真正的preMain耗时。

内容的提问来源于stack exchange，提问作者Jayden