在iOS上做运动健康类应用，步数统计与卡路里消耗是绕不开的功能。Core Motion框架里的计步接口从iOS 7的CMStepCounter逐步过渡到iOS 8引入的CMPedometer，两者的数据模型和调用方式存在明显差异。很多应用还在沿用CMStepCounter的旧代码，但该接口已经被苹果标记为废弃，继续使用会遇到后台更新不稳定、可获取的数据类型有限等问题。CMPedometer不仅支持步数，还能返回距离、平均配速和楼层变化，配合运动协处理器可以实现更低功耗的持续记录。本文围绕两个类的权限配置、核心API调用、卡路里消耗估算以及实际数据精度展开，帮助开发者在迁移旧代码或设计新模块时做出合理选择。
一、CMStepCounter与CMPedometer的定位差异
CMStepCounter提供类方法isStepCountingAvailable判断硬件是否支持，通过queryStepCountStartingFrom:to:toQueue:withHandler:读取指定时间段内的步数。该接口没有实时回调，只能主动查询，适合定时拉取步数。它不返回距离和卡路里，因此应用需要自行推算。CMPedometer则提供startUpdates(from:withHandler:)实现持续更新，并且CMPedometerData对象包含numberOfSteps、distance、floorsAscended、averageActivePace等属性。这些属性依赖M系列运动协处理器，数据在系统层经过过滤和合并，比开发者自己用加速度计计算更稳定。但CMPedometer的历史查询限最近7天，更早的数据无法获取，这是它的一个限制。
权限配置上，两个类都需要在Info.plist中声明NSMotionUsageDescription，否则访问运动数据会直接崩溃或返回错误。CMPedometer没有引入额外的权限请求弹窗，系统只在第一次访问时根据描述展示用途说明。CMStepCounter在旧版iOS上权限控制相对宽松，但iOS 11以后统一要求描述。开发者还需要注意，如果应用被用户拒绝运动权限，CMPedometer.isStepCountingAvailable()仍可能返回true，因为该接口只表示硬件能力，不代表授权状态，真正发起查询时会报错。因此代码里要处理error回调。
二、用CMPedometer实现实时计步与卡路里计算
实时计步的调用流程比较简单。创建CMPedometer实例后，先调用isStepCountingAvailable判断硬件能力，再调用startUpdates(from:withHandler:)订阅更新。回调默认在后台队列，需要回到主线程刷新UI。如果需要从过去某个时间点开始补记，可以使用startUpdates(from: Date(timeIntervalSinceNow: -3600), withHandler:)，系统会先返回一个历史片段，再继续推送实时数据。停止更新时调用stopUpdates即可。
import CoreMotion
let pedometer = CMPedometer()
func startPedometerUpdates() {
guard CMPedometer.isStepCountingAvailable() else {
print("当前设备不支持计步")
return
}
pedometer.startUpdates(from: Date()) { data, error in
guard error == nil, let data = data else {
print("计步数据获取失败: \(error?.localizedDescription ?? "未知错误")")
return
}
DispatchQueue.main.async {
let steps = data.numberOfSteps.intValue
let distance = data.distance?.doubleValue ?? 0
print("步数: \(steps), 距离: \(distance) 米")
}
}
}
func queryTodaySteps() {
let now = Date()
let startOfDay = Calendar.current.startOfDay(for: now)
pedometer.queryPedometerData(from: startOfDay, to: now) { data, error in
guard error == nil, let data = data else { return }
print("今日步数: \(data.numberOfSteps)")
}
}
卡路里消耗计算方面，CMPedometerData本身不提供卡路里字段，需要根据步数、距离和用户体重等信息估算。常见的简化公式为：消耗能量（千卡）约等于体重（kg）× 距离（km）× 1.036。如果只有步数，可以先用步幅估算距离，一般成年人的步幅约为身高×0.45，或者直接取0.7米。公制单位下的计算可以这样实现：
func estimateCalories(steps: Int, distanceMeters: Double, weightKg: Double) -> Double {
let distanceKm = distanceMeters / 1000.0
let calories = weightKg * distanceKm * 1.036
return calories
}
这个公式仅适合步行场景。跑步时身体做功更大，单位距离消耗更高，需要使用MET值法重新计算，例如跑步MET约为8.3，步行约为3.5。如果应用面向健身人群，可以结合CMPedometer返回的averageActivePace判断当前配速，动态调整MET系数，提高估算准确度。不过苹果没有提供官方卡路里字段，第三方算法需要标注为估算值。
三、CMStepCounter与CMPedometer数据精度及实测对比
为了评估两个接口的数据差异，可以在同一设备上分别用CMStepCounter和CMPedometer统计同一时间段内的步数。CMStepCounter由于已废弃，在较新的iOS系统上可能返回空数据或者延迟严重。CMPedometer基于运动协处理器，在设备静止时能自动暂停计数，减少误计。实测中，正常步行1000步，CMPedometer的计数误差通常在±5步以内，而CMStepCounter在某些系统版本上可能漏计5%以上。跑步场景下差距更明显，因为CMStepCounter没有活动状态识别，手臂摆动异常时容易多计。
| 能力 | CMStepCounter | CMPedometer |
|---|---|---|
| 实时更新 | 不支持，需定时查询 | 支持startUpdates |
| 历史数据 | 支持指定时间段 | 支持，但最近7天 |
| 返回字段 | 仅步数 | 步数、距离、楼层、配速 |
| 卡路里 | 需自行估算 | 需自行估算 |
| 硬件依赖 | M7及以上 | M7及以上 |
卡路里计算精度同样受数据源影响。如果只用步数估算距离，误差会叠加到卡路里上。跑步等高强度活动应改用MET值法：消耗千卡 = MET × 体重（kg） × 时间（小时）。例如跑步MET约为8.3，步行约为3.5。如果应用面向健身人群，可以结合CMPedometer的averageActivePace判断当前配速，动态调整MET系数，提高估算准确度。不过苹果没有提供官方卡路里字段，第三方算法需要标注为估算值。
四、迁移与后台限制的注意事项
如果你还在使用CMStepCounter，迁移到CMPedometer并不复杂，但要注意几个差异。CMStepCounter的查询方法接收NSOperationQueue，回调里返回步数和错误；CMPedometer的回调参数是CMPedometerData和Error，数据类型更丰富。旧的类方法调用可以改成实例方法。此外，CMStepCounter没有停止实时更新的方法，因为它本来就不支持实时，而CMPedometer必须手动调用stopUpdates，否则回调会持续触发，增加电量消耗。
后台更新方面，CMPedometer的startUpdates在应用进入后台后仍会继续推送一段时间，但系统可能挂起应用。需要长时间后台记录步数的应用，应该使用queryPedometerData定时拉取，或者在应用回到前台时一次性查询缺失时间段。历史查询只覆盖最近7天，如果需要保存长期数据，要把每天的步数持久化到本地数据库，并在每天结束时做汇总。不能依赖CMPedometer保存所有历史，否则一周前的数据会读不到。
错误处理也要重视。在设备不支持计步或权限被拒时，CMPedometer会返回CMError，常见的错误码包括CMErrorMotionActivityNotAuthorized和CMErrorStepCountingNotAvailable。开发中应针对这些错误给出降级方案，例如使用CMMotionActivityManager判断用户活动状态，或者用加速度计自行实现计步，但后者功耗高、精度低，只适合作为兜底方案。卡路里计算的结果也应向用户说明为估算值，避免医疗健康场景误用。
Core MotionCMStepCounterCMPedometer修改时间：2026-09-19 17:08:22