关于ios:Wakeup-in-XNU

本文作者：段家顺

苹果在 iOS13 的时候，在内核中退出了一个新的性能掂量指标wakeup，同时因为这个指标而被零碎杀死的利用不可胜数，其中也包含咱们罕用的微信淘宝等。而这个指标齐全是由 XNU 内核统计的，所以咱们很难通过日志等一般伎俩去精确的定位问题，所以这里通过另一种思路去解决这个问题。

为什么要统计 wakeup

要定位这个问题，首先咱们须要晓得这个指标的目标是什么。

XNU 中，对性能的指标有 CPU、内存、IO，而 wakeup 属于 CPU 的性能指标，同时属于 CPU 指标的还有 CPU 使用率，上面是 XNU 中对其限度的定义。

/*
 * Default parameters for CPU usage monitor.
 *
 * Default setting is 50% over 3 minutes.
 */
#define         DEFAULT_CPUMON_PERCENTAGE 50
#define         DEFAULT_CPUMON_INTERVAL   (3 * 60)

#define TASK_WAKEUPS_MONITOR_DEFAULT_LIMIT              150 /* wakeups per second */
#define TASK_WAKEUPS_MONITOR_DEFAULT_INTERVAL   300 /* in seconds. */

/*
 * Level (in terms of percentage of the limit) at which the wakeups monitor triggers telemetry.
 *
 * (ie when the task's wakeups rate exceeds 70% of the limit, start taking user
 *  stacktraces, aka micro-stackshots)
 */
#define TASK_WAKEUPS_MONITOR_DEFAULT_USTACKSHOTS_TRIGGER        70

总结来说，当 CPU 使用率在 3 分钟内均值超过 50%，就认为适度应用 CPU，当 wakeup 在 300 秒内均值超过 150 次，则认为唤起次数过多，同时在阈值的 70% 水位内核会开启监控。

CPU 使用率咱们很容易了解，使用率越高，电池寿命越低，而且并不是线性减少的。那么 wakeup 又是如何影响电池寿命的呢？

首先咱们须要看看 ARM 架构中对于 CPU 功耗问题的形容：

Many ARM systems are mobile devices and powered by batteries. In such systems, optimization of power use, and total energy use, is a key design constraint. Programmers often spend significant amounts of time trying to save battery life in such systems. 

因为 ARM 被大量应用于低功耗设施，而这些设施往往会由电池来作为驱动，所以 ARM 在硬件层面就对功耗这个问题进行了优化设计。

Energy use can be divided into two components: 

- Static 
Static power consumption, also often called leakage, occurs whenever the core logic or RAM blocks have power applied to them. In general terms, the leakage currents are proportional to the total silicon area, meaning that the bigger the chip, the higher the leakage. The proportion of power consumption from leakage gets significantly higher as you move to smaller fabrication geometries. 

- Dynamic 
Dynamic power consumption occurs because of transistor switching and is a function of the core clock speed and the numbers of transistors that change state per cycle. Clearly, higher clock speeds and more complex cores consume more power. 

功耗能够分为 2 种类型，即动态功耗与动静功耗。

动态功耗指的是只有 CPU 通上电，因为芯片无奈保障相对绝缘，所以会存在“漏电”的状况，而且越大的芯片这种问题越重大，这也是芯片厂家为什么拼命的钻研更小尺寸芯片的起因。这部分功耗因为是硬件自身决定的，所以咱们无奈去管制，而这种类型功耗占比不大。

动静功耗指的是 CPU 运行期间，接通时钟后，执行指令所带来的额定开销，而这个开销会和时钟周期频率相干，频率越高，耗电量越大。这也就阐明了苹果为什么会管制 CPU 使用率，而相干钻研（Facebook 也做过）也表明，CPU 在 20 以下和 20 以上的能耗简直是成倍的减少。

CPU 使用率曾经可能从肯定水平上限度电池损耗问题了，那么 wakeup 又是什么指标呢？

wakeup 是什么

要理解 wakeup 是什么，首先要晓得 ARM 低功耗模式的 2 个重要指令 WFI 和WFE。

ARM assembly language includes instructions that can be used to place the core in a low-power state. The architecture defines these instructions as hints, meaning that the core is not required to take any specific action when it executes them. In the Cortex-A processor family, however, these instructions are implemented in a way that shuts down the clock to almost all parts of the core. This means that the power consumption of the core is significantly reduced so that only static leakage currents are drawn, and there is no dynamic power consumption. 

通过这 2 个指令进入低功耗模式后，时钟将会被敞开，这个 CPU 将不会再执行任何指令，这样这个 CPU 的动静能耗就没有了。这个能力的实现是由和 CPU 外围强绑定的空转线程 idle thread 实现的，有意思的是 XNU 中的实现较为简单，而 Zircon 中则十分间接暴力：

__NO_RETURN int arch_idle_thread_routine(void*) {for (;;) {__asm__ volatile(“wfi”);
  }
}

在 XNU 中，一个 CPU 外围的工作流程被概括为如下状态机：

/*
 *           -------------------- SHUTDOWN
 *          /                     ^     ^
 *        _/                      |      \
 *  OFF_LINE ---> START ---> RUNNING ---> IDLE ---> DISPATCHING
 *         \_________________^   ^ ^______/           /
 *                                \__________________/
 */

而 wakeup 则示意的是，从低功耗模式唤起进入运行模式的次数。

wakeup 如何统计的

ARM 异样零碎

CPU 时钟被敞开了，那么又要怎么唤起呢？这就波及到 CPU 的异样零碎。

在 ARM 中，异样和中断的概念比拟含糊，他把所有会引起 CPU 执行状态变更的事件都称为异样，其中包含软中断，debug 中断，硬件中断等。

从触发机会上能够辨别为同步异样与异步异样。这里指的同步异步并不是应用程序的概念，这里同步指的是领有明确的触发机会，比方零碎调用，缺页中断等，都会产生在明确的机会，而异步中断，则齐全忽视指令的逻辑，会强行打断指令执行，比方 FIQ 和 IRQ，这里比拟典型的是定时器中断。

异样零碎有很多能力，其中一个重要的能力就是内核态与用户态切换。ARM 的执行权限分为 4 个等级，EL0，EL1，EL2，EL3。其中 EL0 代表用户态，而 EL1 代表内核态，当用户态想要切换至内核态的时候，必须通过异样零碎进行切换，而且异样零碎只能向等同或更高等级权限进行切换。

那么这么多类型的异样，又是如何响应的呢？这里就波及到一个异样处理表（exception table），在系统启动的时候，须要首先就去注册这个表，在 XNU 中，这个表如下：

    .section __DATA_CONST,__const
    .align 3
    .globl EXT(exc_vectors_table)
LEXT(exc_vectors_table)
    /* Table of exception handlers.
         * These handlers sometimes contain deadloops. 
         * It's nice to have symbols for them when debugging. */
    .quad el1_sp0_synchronous_vector_long
    .quad el1_sp0_irq_vector_long
    .quad el1_sp0_fiq_vector_long
    .quad el1_sp0_serror_vector_long
    .quad el1_sp1_synchronous_vector_long
    .quad el1_sp1_irq_vector_long
    .quad el1_sp1_fiq_vector_long
    .quad el1_sp1_serror_vector_long
    .quad el0_synchronous_vector_64_long
    .quad el0_irq_vector_64_long
    .quad el0_fiq_vector_64_long
    .quad el0_serror_vector_64_long

wakeup 计数

那么咱们回过头来看看 wakeup 计数的中央：

/*
 *  thread_unblock:
 *
 *  Unblock thread on wake up.
 *  Returns TRUE if the thread should now be placed on the runqueue.
 *  Thread must be locked.
 *  Called at splsched().
 */
boolean_t
thread_unblock(
    thread_t                thread,
    wait_result_t   wresult)
{
      // . . .
    boolean_t aticontext, pidle;
    ml_get_power_state(&aticontext, &pidle);

     /* Obtain power-relevant interrupt and“platform-idle exit" statistics.
     * We also account for“double hop”thread signaling via
     * the thread callout infrastructure.
     * DRK: consider removing the callout wakeup counters in the future
     * they’re present for verification at the moment.
     */

    if (__improbable(aticontext /* . . . */)) {// wakeup ++}
    // . . .
}

而这里的 aticontext 则是通过 ml_at_interrupt_context 获取的，其含意则是是否处于中断上下文中。

/*
 *  Routine:        ml_at_interrupt_context
 *  Function:   Check if running at interrupt context
 */
boolean_t
ml_at_interrupt_context(void)
{
    /* Do not use a stack-based check here, as the top-level exception handler
     * is free to use some other stack besides the per-CPU interrupt stack.
     * Interrupts should always be disabled if we’re at interrupt context.
     * Check that first, as we may be in a preemptible non-interrupt context, in
     * which case we could be migrated to a different CPU between obtaining
     * the per-cpu data pointer and loading cpu_int_state.  We then might end
     * up checking the interrupt state of a different CPU, resulting in a false
     * positive.  But if interrupts are disabled, we also know we cannot be
     * preempted. */
    return !ml_get_interrupts_enabled() && (getCpuDatap()->cpu_int_state != NULL);
}

那么 cpu_int_state 标记又是在什么时候设置下来的呢？只有在 locore.S 中，才会更新该标记：

str        x0, [x23, CPU_INT_STATE]            // Saved context in cpu_int_state

同时发现如下几个办法会配置这个标记：

el1_sp0_irq_vector_long
el1_sp1_irq_vector_long
el0_irq_vector_64_long
el1_sp0_fiq_vector_long
el0_fiq_vector_64_long

联合上述的异样处理表的注册地位，与 ARM 官网文档的地位进行比照，能够发现：

这几个中断类型均为 FIQ 或者 IRQ，也就是硬中断。由此咱们能够判断，wakeup必然是由硬中断引起的，而像零碎调用，线程切换，缺页中断这种并不会引起wakeup。

过程统计

由上能够看出，wakeup其实是对 CPU 外围唤起次数的统计，和应用层的线程与过程仿佛毫不相干。但从程序执行的角度思考，如果一个程序始终在运行，就不会进入期待状态，而从期待状态唤醒，必定是因为某些异常中断，比方网络，vsync 等。

在 CPU 外围被唤醒后，在以后 CPU 外围执行的线程会进行 wakeup++，而零碎统计维度是利用维度，也就是过程维度，所以会累计该过程上面的所有线程的wakeup 计数。

queue_iterate(&task->threads, thread, thread_t, task_threads) {
        info->task_timer_wakeups_bin_1 += thread->thread_timer_wakeups_bin_1;
        info->task_timer_wakeups_bin_2 += thread->thread_timer_wakeups_bin_2;
}

所以在咱们代码中，如果在 2 个不同线程启用用同样的定时器，wakeup是同一个线程起 2 个定时器的 2 倍（同样的定时器在底层其实是一颗树，注册同样的定时器理论只注册了一个）。

用户层获取该统计值则能够通过如下形式：

#include <mach/task.h>
#include <mach/mach.h>

BOOL GetSystemWakeup(NSInteger *interrupt_wakeup, NSInteger *timer_wakeup) {struct task_power_info info = {0};
    mach_msg_type_number_t count = TASK_POWER_INFO_COUNT;
    kern_return_t ret = task_info(current_task(), TASK_POWER_INFO, (task_info_t)&info, &count);
    if (ret == KERN_SUCCESS) {if (interrupt_wakeup) {*interrupt_wakeup = info.task_interrupt_wakeups;}
        if (timer_wakeup) {*timer_wakeup = info.task_timer_wakeups_bin_1 + info.task_timer_wakeups_bin_2;}
        return true;
    }
    else {if (interrupt_wakeup) {*interrupt_wakeup = 0;}
        if (timer_wakeup) {*timer_wakeup = 0;}
        return false;
    }
}

wakeup 治理

从以上剖析来看，咱们只须要排查各种硬件相干事件即可。

从理论排查后果来看，目前只有定时器或者领有定时能力的类型是最广泛的场景。

比方 NSTimer，CADisplayLink，dispatch_semaphore_wait，pthread_cond_timedwait 等。

对于定时器，咱们尽量复用其能力，防止在不同线程去创立同样的定时能力，同时在回到后盾的时候，敞开不须要的定时器，因为大部分定时器都是 UI 相干的，敞开定时器也是一种规范的做法。

对于 wait 类型的能力，从计划抉择上防止轮询的计划，或者减少轮询间隔时间，比方能够通过 try_wait，runloop 或者 EventKit 等能力进行优化。

监控与防劣化

一旦咱们晓得了问题起因，那么对问题的治理比较简单，而后续咱们须要建设继续的管控等长效措施才能够。

在此咱们能够简略的定义一些规定，并且嵌入线下监控能力中：

• 定时器工夫周期小于 1s 的，在进入后盾须要进行暂停
• wait 类型提早小于 1s，并且继续应用 10 次以上的状况须要进行优化

总结

wakeup因为是 XNU 内核统计数据，所以在问题定位排查方面特地艰难，所以从另一个角度去解决这个问题反而是一种更好的形式。

同时从 XNU 中对 CPU 功耗的管制粒度能够看出，苹果在极致的优化方面做的很好，在本身的软件生态中要求也比拟高。电量问题在短时间内应该不会有技术上的冲破，所以咱们本身也须要多思考如何缩小电池损耗。

本文公布自 网易云音乐大前端团队，文章未经受权禁止任何模式的转载。咱们长年招收前端、iOS、Android，如果你筹备换工作，又恰好喜爱云音乐，那就退出咱们 grp.music-fe(at)corp.netease.com！