耗电 on Last Stand

耗电-CPU与后台优化

Sat, 02 May 2026 22:32:27 +0800

CPU是App最容易"无意识"耗电的模块，而后台则是最容易"偷偷"耗电的场景。本文聚焦这两大问题域，给出具体的优化手段。

一、CPU耗电的根本原因

根据耗电-原理中的分析，CPU耗电由三部分构成：

活跃时间：CPU处于C0/P0的时间。
瞬时功率：和P-State频率相关。
唤醒次数：频繁从C-State唤醒无法进入深度休眠。

对应三条优化方向：

优化方向	策略
减少活跃	任务及时结束，该停就停
降低功率	避免无谓的满核满频，使用合适的QoS
合并唤醒	聚合Timer、聚合任务，让CPU能连续工作后进入深休眠

二、识别CPU耗电热点

从MetricKit入手

cumulativeCPUTime 是线上最直接的CPU指标。对比同版本前后、同机型前后的CPU时长，能快速定位回归。

Time Profiler的使用技巧

在Instruments中抓一份Time Profiler Trace后：

按"Heavy Stack"视图查看耗时函数。
关注后台的采样（通过Xcode的生命周期切换复现）。
查看线程调用频率——单次耗时低但高频调用的函数，同样是耗电大头。

代码层面的CPU异味

// 1. 死循环轮询
while isWaitingForData {
 if dataReady { break }
}

// 2. 主线程sleep循环
DispatchQueue.global().async {
 while true {
 checkStatus()
 Thread.sleep(forTimeInterval: 0.1)
 }
}

// 3. 密集Timer
Timer.scheduledTimer(withTimeInterval: 0.016, repeats: true) { _ in
 self.updateUI()
}

// 4. 无限制的CADisplayLink
displayLink = CADisplayLink(target: self, selector: #selector(tick))
displayLink.add(to: .main, forMode: .common)
// 页面隐藏后忘记invalidate

这些代码在Time Profiler中都会显示出异常高的调用频率。

耗电-原理

Sat, 02 May 2026 22:32:27 +0800

本文从硬件功耗模型、iOS系统的能效调度机制、以及各个硬件模块的功耗特性三个维度，系统性地讲解iOS App耗电的底层原理。

功耗的基本概念

功率、能量与电量

功率（Power）：单位时间内消耗的能量，单位为瓦特（W）。
能量（Energy）：功率在时间上的积分，单位为焦耳（J）或毫瓦时（mWh）。
电量（Battery Capacity）：电池能存储的总能量，单位为毫安时（mAh）。

\[ Energy = \int P(t)\,dt \]

对于一段时间内近似恒定的功率，可以简化为 \( E = P \times t \)。这也是所有耗电优化的起点——要么降功率（P），要么降时间（t）。

电池电压与电流

iPhone使用锂电池，标称电压约为3.7~3.8V。操作系统看到的电流则随着硬件负载实时变化。可以近似认为：

\[ P(t) = V \times I(t) \]

在App层面，我们无法直接测量V和I，但可以通过 UIDevice.current.batteryLevel 观察电量百分比，通过 IOKit 私有API读取更精细的电池状态（后面检测篇会详细讲）。

硬件功耗特性

不同硬件模块的功耗曲线差异非常大。理解每个模块的特性，才能找到最有效的优化点。

CPU：P-State与C-State

现代CPU（包括Apple Silicon）通过 动态电压频率调整（DVFS） 来平衡性能与功耗。

P-State（Performance State）

P-State描述CPU在工作时的电压/频率档位。以Apple A系列芯片为例，大核和小核都有多个P-State：

flowchart LR
subgraph P-State
P0["P0
最高频率
功耗最大"]
P1["P1
中高频率"]
P2["P2
中低频率"]
P3["P3
低频率
功耗小"]
end
P0 -.->|负载下降| P1
P1 -.-> P2
P2 -.-> P3
P3 -.->|负载上升| P0

CPU的功耗与频率大致呈 立方关系（电压随频率升高，功耗 ≈ V² × f ≈ f³）。这意味着：

耗电-定位与传感器优化

Sat, 02 May 2026 22:32:27 +0800

定位是iOS设备上公认的"耗电大户"，GPS冷启动一次动辄十几秒的高功耗；传感器（加速度计、陀螺仪等）虽然单次功耗不高，但高频采样会累积成可观的电量消耗；屏幕则是持续耗电的模块，其功耗和亮度、刷新率、像素颜色都强相关。本文聚焦这三类问题，给出工程化的优化方案。

一、定位精度与功耗的关系

iOS通过 CLLocationManager 提供定位服务，底层融合了 GPS、蜂窝基站、WiFi、蓝牙信标 等多源信号。精度越高，需要开启的硬件越多，功耗越高。

精度常量	精度范围	硬件使用	典型功耗
kCLLocationAccuracyBestForNavigation	<5m	GPS + 传感器融合（需插电）	极高
kCLLocationAccuracyBest	~10m	GPS持续	高
kCLLocationAccuracyNearestTenMeters	~10m	GPS + WiFi	高
kCLLocationAccuracyHundredMeters	~100m	WiFi + 基站	中
kCLLocationAccuracyKilometer	~1km	WiFi + 基站（低频）	低
kCLLocationAccuracyThreeKilometers	~3km	基站	极低

注：iOS 14+ 引入的 ReducedAccuracy 是用户授权层面的"粗略位置"，通过 CLAccuracyAuthorization.reducedAccuracy 体现，而不是 desiredAccuracy 常量。即使 App 申请了高精度，只要用户选择了"粗略位置"，系统就只会返回约5公里精度的数据，功耗也随之降到极低。

不同业务场景的精度选择

业务	推荐精度
导航	BestForNavigation（仅使用中 + 插电时）
打车、骑行记录	Best
外卖、附近的人	HundredMeters
天气、资讯推荐	Kilometer 或 ThreeKilometers
反欺诈、粗粒度风控	ReducedAccuracy（尊重隐私 + 省电）

常见反例

// Bad: 所有场景都用Best，页面打开就开，关闭不关
locationManager.desiredAccuracy = kCLLocationAccuracyBest
locationManager.startUpdatingLocation()

// Bad: distanceFilter用kCLDistanceFilterNone，每次都回调
locationManager.distanceFilter = kCLDistanceFilterNone

正确姿势：按需精度 + 距离过滤

class WeatherLocationClient: NSObject, CLLocationManagerDelegate {
 private let manager = CLLocationManager()
 private var completion: ((CLLocation) -> Void)?

 override init() {
 super.init()
 manager.delegate = self
 manager.desiredAccuracy = kCLLocationAccuracyKilometer
 manager.distanceFilter = 500 // 500米才更新
 }

 func requestOnce(_ completion: @escaping (CLLocation) -> Void) {
 self.completion = completion
 manager.requestLocation() // 一次性定位，完成后自动停止
 }

 func locationManager(_ manager: CLLocationManager, didUpdateLocations locs: [CLLocation]) {
 guard let loc = locs.last else { return }
 completion?(loc)
 completion = nil
 }

 func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) {
 completion = nil
 }
}

requestLocation()（iOS 9+）是最省电的一次性定位入口，系统会在获取到满足精度的定位后自动停止硬件。

耗电-检测

Fri, 08 May 2026 22:35:33 +0800

本文介绍iOS耗电问题的检测手段，从开发阶段的本地工具，到线上的监控体系，帮助团队形成一套完整的耗电可观测能力。

检测手段全景

flowchart TB
subgraph Dev["研发阶段"]
EG["Xcode Energy Gauge
实时能效评分"]
Inst["Instruments
Energy Log / Time Profiler"]
XCT["XCTest能效测试"]
end
subgraph Test["测试阶段"]
Thermal["热节流测试"]
Battery["真机电量消耗测试"]
IOKit["IOKit内部分析"]
LPM["低电量模式回归"]
end
subgraph Online["线上阶段"]
MK["MetricKit"]
Self["自建实时采集
电量 / CPU / Thermal / 生命周期"]
Report["埋点上报
数据看板"]
end
Dev --> Test --> Online

一、Xcode Energy Gauge

Xcode在真机调试时，“Debug Navigator → Energy Impact"提供了实时能效评估。

能效评分（Energy Impact）

Xcode将功耗分为5档：

等级	含义	典型值
Very Low / Low	正常使用	0~~3 / 4~~8
High	偏高，需要关注	9~16
Very High	严重，必须优化	17~20

评分由以下几个因素构成：

CPU：平均CPU使用率。
Network：网络活跃时间与流量。
Location：定位活跃时间与精度。
GPU：GPU活跃时间。
Background：后台活跃时间。
Overhead：系统唤醒代价。

典型使用流程

Xcode连接真机（模拟器的数据不准确）。
运行App，选择Debug Navigator → Energy Impact。
进行典型操作（刷Feed、看视频、聊天等），观察评分。
如果出现High/Very High，使用Instruments进一步定位。

二、Instruments Energy Log

Instruments中有多个和能效相关的工具：

耗电-治理

Thu, 07 May 2026 15:42:48 +0800

前面几篇分别讲了耗电的原理、检测、以及CPU/网络/定位/屏幕的具体优化手段。本文把这些内容整合起来，给出一套面向工程团队的 耗电治理体系：从研发规范、线上监控、问题排查到常态化运营。

耗电治理是 APM 资源子系的一部分，与稳定性、流畅性、启动指标共用同一套监控与告警基础设施。完整的 APM 建设方案见 APM 系列：数据采集、B端平台设计。

一、治理体系全景

一个成熟的iOS耗电治理体系通常由四个闭环组成：

flowchart TB
subgraph Dev["研发侧"]
R1["能效规范"]
R2["架构层能效约束"]
R3["Code Review清单"]
end
subgraph Test["测试侧"]
T1["XCTest能效基线"]
T2["真机续航测试"]
T3["极端场景矩阵"]
end
subgraph Online["线上侧"]
O1["MetricKit接入"]
O2["自建CPU/电量采样"]
O3["场景化埋点"]
O4["大盘 + 告警"]
end
subgraph Gov["运营侧"]
G1["版本耗电报告"]
G2["Top问题跟进"]
G3["复盘与规范迭代"]
end
Dev --> Test --> Online --> Gov --> Dev

二、研发阶段的能效规范

模块准入清单

每个新增模块在接入主App前，必须回答以下问题：

维度	问题
CPU	是否有常驻Timer？是否有轮询？是否在不可见时暂停？
网络	请求频率？是否合并？是否支持后台取消？
定位	是否申请定位？精度多少？后台策略？
传感器	是否开启传感器？采样率？视图生命周期？
后台能力	是否申请Background Mode？如何收敛？
动画/渲染	是否有长驻动画？是否适配ProMotion？
Low Power	低电量模式下的降级策略？
权限	涉及的用户权限？是否遵守最小权限原则？

架构层面的能效约束

一些通用能力可以在架构层统一管控，避免各业务重复踩坑：

耗电-网络优化

Sat, 02 May 2026 22:32:27 +0800

网络是iOS设备上仅次于屏幕的耗电大户。和其他模块不同，网络耗电的"坑"非常隐蔽——请求本身只持续几十毫秒，但无线电（Radio）会有10~20秒的"尾能耗"。本文从无线电能效模型出发，给出具体的网络优化手段。

一、无线电能效模型回顾

RRC状态机再看一眼

无线电不是"开就费电、关就不费电"这么简单。它在连接和空闲之间存在中间状态：

stateDiagram-v2
[*] --> Idle: 初始/长时间空闲
Idle --> Connected: 发送/接收
Connected --> ShortDRX: 空闲~1秒
ShortDRX --> LongDRX: 空闲~5秒
LongDRX --> Idle: 空闲~10秒
Connected --> Connected: 持续通信
ShortDRX --> Connected: 新请求
LongDRX --> Connected: 新请求

状态	功耗	说明
Connected	最高（12W）	数据传输中
Short DRX	中等	周期性监听页 paging，仍持有连接
Long DRX	低	周期变长，仍在空中接口
Idle	极低（~几mW）	完全释放

一次请求从发起到彻底回到Idle大约 12~20秒。这个尾巴就是"Tail Energy"。

能效启示

10次请求，每次间隔2秒：
- Radio持续处于Connected/DRX状态 ≈ 30秒
- 实际传输时间可能只有几百ms

10次请求合并成1次:
- Radio活跃时间 ≈ 15秒（主要是尾巴）
- 节省约50%~70%的Radio能耗

结论：网络能效的核心就是"减少Radio醒来的次数"。

耗电

Fri, 08 May 2026 22:35:33 +0800

耗电（Energy Consumption）是移动应用质量的重要指标之一。一款耗电过快的App会直接影响用户的续航体验，轻则被用户吐槽，重则被系统标记为"耗电大户"（在iOS的"设置 → 电池"中显示），最终被用户卸载。

本系列文章从iOS功耗模型入手，系统性地介绍耗电问题的原理、检测、优化与治理。

为什么要关注耗电

iOS设备的电池容量有限（iPhone通常在3000~5000mAh），而应用的功耗会直接影响续航时间。苹果在iOS 8之后提供了"电池用量"统计入口，用户可以清楚地看到每个App消耗的电量比例。

常见的耗电投诉场景：

场景	用户感知	典型原因
后台待机一晚电量掉20%	手机放着不用也掉电	后台定位、后台音频、后台Fetch未合理释放
App使用1小时电量掉30%	使用过程电量下降过快	CPU长时间高占用、高频网络请求、GPU密集渲染
手机发烫	设备温度异常升高	CPU/GPU长期满载、持续定位、频繁屏幕唤醒
被系统标记为"后台活动"过高	系统提示"此App正在消耗大量电池"	后台任务未合理调度，违反能效规则

苹果对"耗电"非常敏感——从iOS 9开始引入低电量模式（Low Power Mode），从iOS 13开始加强后台任务的能效审查（BackgroundTasks框架），从iOS 15开始通过MetricKit将功耗数据开放给开发者。

iOS功耗模型概述

iOS设备的功耗来源可以分为以下几大类：

flowchart TB
Battery["电池总功耗"]
Battery --> CPU["CPU
计算、编解码"]
Battery --> GPU["GPU
渲染、图层合成"]
Battery --> Screen["屏幕
显示、亮度、刷新率"]
Battery --> Network["网络
蜂窝、WiFi、BLE"]
Battery --> Location["定位
GPS、基站、WiFi定位"]
Battery --> Sensor["传感器
加速度计、陀螺仪、气压计"]
Battery --> Audio["音视频
录制、播放、相机"]
Battery --> Storage["存储
磁盘IO"]
Battery --> IO["外设
蓝牙、NFC、UWB"]

不同硬件模块的功耗量级差异很大。参考苹果WWDC的数据，定位和蜂窝数据通常是"耗电大户"，屏幕是"持续耗电大户"，而CPU/GPU在计算密集时瞬时功耗最高。

模块	典型功耗等级	特点
屏幕	持续高	只要亮屏就持续耗电
蜂窝数据	高	搜索基站、维持连接都耗电
GPS定位	高	冷启动搜星耗电特别明显
CPU/GPU	中~高	计算量决定功耗
WiFi	中	比蜂窝省电
蓝牙（BLE）	低	低功耗蓝牙专为续航优化
传感器	低~中	高频采样会显著增加功耗

耗电问题的本质

耗电问题的本质可以用一个简单的公式表示：