耗电-定位与传感器优化

定位是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+)是最省电的一次性定位入口,系统会在获取到满足精度的定位后自动停止硬件。 ...

May 2, 2026

Objective-C 关联对象 Associated Objects 作用与实现原理

objc4 runtime Associated Objects objc-references.mm 关联对象 Associated Objects 作用与实现原理 关联对象让调用方在不改类布局、不新增 ivar 的情况下,把一组 key - value 挂到任意 Objective-C 对象上。 objc4 的实现不是把字段塞进对象内存,而是用一张运行时全局表保存“对象地址、key、关联值和内存管理策略”的映射。 入口 APIobjc_setAssociatedObject objc_getAssociatedObject 核心存储AssociationsHashMap ObjectAssociationMap 值封装ObjcAssociation policy + value 清理时机objc_destructInstance objc_disposeClassPair 目录 作用与使用边界 公开 API 与 policy 核心结构与字段 set / get / remove 流程 对象销毁与特殊关联 禁止关联对象的场景 测试覆盖点 作用与使用边界 关联对象主要服务于分类、框架扩展、运行时补充状态等场景:调用方只有对象指针和一个稳定 key,就能为对象保存额外值。 这避免了修改类的 ivar 布局,也让分类可以模拟“存储属性”。 适合做什么 给现有类或分类补充少量状态。 把辅助对象、回调 block、缓存值挂到宿主对象。 用唯一地址作为 key,避免和其他调用方冲突。 不适合做什么 高频读写的核心数据结构。 需要类型系统和对象布局明确表达的状态。 清空他人关联值,尤其是随意调用 objc_removeAssociatedObjects。 运行时代价 每次访问都需要全局关联表查询。 set / get / remove 通过 AssociationsManagerLock 串行保护表。 对象析构时可能需要额外释放所有关联值。 **关键结论:**关联对象是“外置 side table”,不是对象内的 ivar。对象只保存一个“可能有 associated objects”的快速标记,真正的 key/value 在全局表里。 ...

June 1, 2026

耗电-检测

本文介绍iOS耗电问题的检测手段,从开发阶段的本地工具,到线上的监控体系,帮助团队形成一套完整的耗电可观测能力。 检测手段全景 flowchart TB subgraph Dev["研发阶段"] EG["Xcode Energy Gauge实时能效评分"] Inst["InstrumentsEnergy 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 正常使用 03 / 48 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中有多个和能效相关的工具: ...

May 8, 2026

Swift 宏

Swift 5.9(WWDC 2023)引入的宏(Macro)是近几年语言层最大的一次能力扩展。它让 Swift 第一次具备了编译期代码生成的官方机制——你可以在源码层面写一段"能生成代码的代码",编译器会在类型检查前把它展开成真正的 Swift 源码,再走正常的编译流程。SwiftUI 的 #Preview、Observation 框架的 @Observable、SwiftData 的 @Model、Swift Testing 的 @Test / #expect、FoundationModels 的 @Generable / @Tool,全都是宏。 一、为什么要有宏 1.1 Swift 之前能做什么,又差在哪 在宏之前,Swift 已经有一整套"元编程"手段,但每一种都有明显的边界: 机制 做什么 局限 @propertyWrapper 给属性注入行为(如 @Published、@State) 只能包属性,不能生成方法、不能生成类型、不能访问其他成员 @resultBuilder 把一段 DSL 收集成表达式(如 SwiftUI 的 ViewBuilder) 只作用于闭包里,无法改类型定义 KeyPath + Mirror 运行时反射读写属性 只能读,类型安全差,性能差(见 iOS反射) Codable 等编译器魔法 自动合成 init(from:) / encode(to:) 只有编译器内部能写,开发者写不出同等能力的东西 Sourcery / SwiftGen 文本级代码生成 游离于编译器之外,无类型信息、无法访问 AST Objective-C #define 纯文本替换 没有作用域、没有类型、没有卫生(hygiene),对调试器和 IDE 极不友好 宏就是要一次性补齐这块能力:在保留类型安全与 IDE 体验的前提下,把"只有 Swift 编译器团队能写的代码生成"开放给所有开发者。 ...

May 4, 2026

CocoaPods 源码导读:架构总览

本系列基于 CocoaPods 1.16.2(2026 年 4 月)源码进行分析。源码仓库由 15 个 Ruby Gem 组成,本文先从整体架构与职责拆分讲起,再以 pod install --repo-update 为主线绘制全景执行图,串起后续两篇专题的切入点。 系列目录: 架构总览(本文) 从命令到依赖求解 从下载到工程集成 一、CocoaPods 不是单一仓库 很多人以为 CocoaPods 就是一个 Ruby 项目,其实官方仓库 CocoaPods/CocoaPods 只是入口,真正的能力被拆成 15 个独立 gem,每个 gem 只做一件事。用 gem dependency cocoapods 会看到这样的依赖拓扑: graph TB subgraph "入口" A["bin/pod(CocoaPods gem)"] end subgraph "命令行框架" B["CLAideCommand/Arg/Option DSL"] end subgraph "领域模型" C["CorePodfile/Podspec/Source/Lockfile"] end subgraph "依赖求解" D["Molinillo回溯式 SAT 求解器"] end subgraph "下载" E["cocoapods-downloaderGit/HTTP/SVN/Hg/SCP"] end subgraph "Xcode 工程读写" F["Xcodeprojpbxproj/xcconfig/workspace"] G["NanaimoASCII plist 解析"] end subgraph "插件与子命令" H["cocoapods-plugins"] I["cocoapods-trunkcocoapods-searchcocoapods-trycocoapods-deintegrate"] end subgraph "辅助" J["cork彩色输出"] K["nap轻量 HTTP 客户端"] end A --> B A --> C A --> D A --> E A --> F F --> G A -.加载.-> H H -.调用.-> I A --> J I --> K 各 gem 的一句话职责: ...

May 2, 2026

Objective-C KVC 作用与实现原理

Key-Value Coding / Foundation behavior with objc4 runtime support Objective-C KVC:从字符串 key 到对象读写 KVC 的核心价值是:把“访问某个属性或实例变量”抽象成 valueForKey:、setValue:forKey: 这样的字符串协议。 读完这一页,你应该能说清楚它解决什么问题、Foundation 大致怎样查找成员, 以及 objc4 runtime 在消息发送、元数据查询、ivar 直写和内存管理上提供了哪些支撑。 适合第一次系统理解 KVC 标注 objc4 / Foundation 边界 含关键流程和注释代码 目录 KVC 到底有什么用 本仓库能看到什么 读写 key 的查找顺序 objc4 提供的底层能力 核心类、方法和关键属性 关键操作流程 常见坑与记忆模型 1. KVC 到底有什么用 平时你写 person.name 或 [person name],访问目标在编译期就固定了。 KVC 允许你在运行时才决定要访问哪个成员:[person valueForKey:@"name"]。 这使得对象、字典、表单、序列化、绑定和调试工具可以用同一套字符串 key 访问模型对象。 动态访问 运行时才知道字段名时,用字符串 key 读取或写入对象。 统一映射 JSON、表单、数据库行、UI 绑定都可以映射到对象属性。 批量和路径 valueForKeyPath: 能沿着 department.manager.name 连续取值。 ...

June 1, 2026

耗电-治理

前面几篇分别讲了耗电的原理、检测、以及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 低电量模式下的降级策略? 权限 涉及的用户权限?是否遵守最小权限原则? 架构层面的能效约束 一些通用能力可以在架构层统一管控,避免各业务重复踩坑: ...

May 7, 2026

Swift底层原理-结构体、类和协议

在Objective-C底层原理-NSObject文章中,我们深入了解了Objective-C对象的底层实现。本文将探讨Swift中类和结构体的底层原理。 Swift数据结构的分类 Swift中的类根据是否继承自NSObject,在底层实现上存在显著差异: 继承自NSObject的Swift类:兼容Objective-C运行时,支持完整的Objective-C特性 纯Swift类:使用Swift原生运行时,性能更优但Objective-C互操作性受限 Swift中结构体是值类型,具有以下核心特征: 栈上分配内存(非逃逸情况) 值语义和完整拷贝 写时拷贝优化(COW) 静态方法派发 Swift类的底层实现 继承自NSObject的Swift类 当Swift类继承自NSObject时,必须兼容Objective-C的运行时系统,其底层实现与Objective-C对象高度一致。 内存布局 class Class: NSObject { var name: String var isMale: Bool var age: Int init(name: String, isMale: Bool, age: Int) { self.name = name self.isMale = isMale self.age = age super.init() } } 实例内存布局: 偏移量 内容 大小 说明 0x0-0x7 isa_t isa 8字节 指向类对象,包含优化的位域信息 0x8-0x17 String name 16字节 Swift String结构(64位系统) 0x18 Bool isMale 1字节 布尔值 0x19-0x1F (padding) 7字节 Swift编译器根据下一个字段(Int,8字节对齐要求)自动插入填充,确保Int字段从8的倍数地址开始 0x20-0x27 Int age 8字节 64位整数 0x28-0x2F (padding) 8字节 最终内存对齐填充 关键特性: ...

May 6, 2026

Objective-C KVO 作用与实现原理

objc4 runtime reading note KVO:从“属性变化通知”到 runtime 动态子类 KVO(Key-Value Observing)让一个对象在另一个对象的某个 key path 变化时收到回调。 在这个 objc4 仓库里,Foundation 的 KVO 主体代码不在源码中;但 runtime 暴露了 KVO 需要的关键能力: 复制类、切换对象的 isa、判断 ivar 内存语义,并保证这些操作在初始化、弱引用和并发加载场景下安全。 入口:addObserver 核心:动态子类 通知:will/didChange 底层:objc_duplicateClass 阅读路线 KVO 解决什么问题 实现原理总览 objc4 中的关键支撑 核心类和关键方法 关键流程 带注释代码片段 使用边界和排错 1. KVO 的作用:把“状态变化”变成可订阅事件 普通属性赋值只改变对象内部状态,调用者不知道“谁关心这个变化”。KVO 把某个 key path 的变化包装成标准事件: 被观察对象负责发出变化,观察者在 observeValueForKeyPath:ofObject:change:context: 中接收。 解耦 观察者不需要改写被观察对象的业务代码,只注册感兴趣的 key path。 统一格式 变化以 change 字典传递,可包含旧值、新值、变化类型等。 自动拦截 对 KVC/KVO 兼容的 setter,Foundation 可自动在 setter 前后发通知。 手动通知 复杂派生属性或批量变化可用 willChangeValueForKey: 和 didChangeValueForKey: 明确包围。 ...

June 1, 2026

iOS 定时器的注意事项

iOS 开发中常用的定时器有 NSTimer、CADisplayLink 和 GCD Timer。它们各有特点,但在使用时都有一些需要注意的问题。 常见定时器类型 1. NSTimer 最常用的定时器,基于 RunLoop 实现: // 自动添加到当前 RunLoop 的 DefaultMode NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timerFired) userInfo:nil repeats:YES]; // 手动创建,需要手动添加到 RunLoop NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerFired) userInfo:nil repeats:YES]; [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode]; 2. CADisplayLink 与屏幕刷新率同步的定时器,适合做动画: CADisplayLink *displayLink = [CADisplayLink displayLinkWithTarget:self selector:@selector(update)]; [displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; 3. GCD Timer 不依赖 RunLoop,精度更高: dispatch_source_t timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue()); dispatch_source_set_timer(timer, DISPATCH_TIME_NOW, 1.0 * NSEC_PER_SEC, 0); dispatch_source_set_event_handler(timer, ^{ NSLog(@"GCD Timer fired"); }); dispatch_resume(timer); 注意事项一:循环引用问题 问题描述 NSTimer 和 CADisplayLink 在使用 target-action 模式时,会强引用 target。如果 target 又持有定时器,就会形成循环引用: ...

May 2, 2026