在 iOS 开发中，“发热”和“耗电过快”是用户投诉率极高的性能问题，也是开发过程中容易忽视、排查难度较大的痛点。尤其在 iPhone 17 系列、iOS 26 等新机型新系统中，Liquid Glass 渲染技术、后台 App 刷新等特性的滥用，进一步加剧了发热耗电问题。很多开发者只知道“发热=耗电高”，却不知道其底层逻辑的关联，优化时盲目优化代码，不仅无法解决问题，还可能引入新的 Bug。
本文将从底层原理→核心元凶→工具定位→分模块深度优化+经典实战案例→最佳实践，全链路拆解 iOS APP 发热与耗电优化，所有案例均来自真实项目实战（已落地验证），代码可直接复用，兼顾深度与实用性，适合 iOS 开发者快速定位问题、落地优化。
一、核心原理：发热与耗电的本质（一句话讲透）
很多开发者会将“发热”和“耗电”割裂看待，其实二者是因果关系：发热是表象，耗电是根源；持续高功耗运行导致发热，频繁唤醒导致耗电剧增。
iOS 设备的所有硬件（CPU、GPU、网络模块、传感器等）运行时都会消耗电量，当硬件持续高负载工作（如 CPU 狂转、GPU 重载），电能会转化为热能，表现为设备发热；而硬件被频繁唤醒（如后台高频轮询、定位持续开启），即使负载不高，也会导致耗电翻倍，长期下来同样会引发发热。
从开发视角，所有发热/耗电问题，最终都能归为 5 类（按出现频率排序）：
- CPU 高负载：死循环、频繁计算、线程爆炸、重复工作；
- GPU 重载：离屏渲染、复杂图层、频繁动画、特效滥用（如 iOS 26 Liquid Glass 特效）；
- 网络频繁交互：短连接泛滥、高频轮询、无效重试、后台心跳；
- 后台/传感器滥用：后台任务未终止、定位/蓝牙持续开启、Widget 高频刷新；
- 内存异常：内存泄漏、大图未释放、OOM 前系统疯狂 GC。
二、精准定位：发热/耗电问题的工具链（必用）
优化的前提是“精准定位”，盲目优化只会做无用功。以下工具组合，可覆盖 99% 的发热/耗电问题定位，从开发调试到线上监控全覆盖。
1. 开发调试阶段（Xcode + Instruments）
- Energy Usage（能耗分析） ：直接查看 APP 耗电排行，定位高耗电模块（如网络、CPU、定位），可实时看到能耗等级（Low/High/Very High）；
- Time Profiler（CPU 分析） ：排查 CPU 高占用函数，定位死循环、频繁计算等问题，区分主线程/子线程占用；
- Core Animation（渲染分析） ：检测离屏渲染（红色标记）、帧率波动，定位 GPU 重载问题；
- Network（网络分析） ：查看请求频率、连接方式（短/长连接）、无效请求，定位网络类耗电；
- Leaks + Allocations（内存分析） ：排查内存泄漏、内存峰值，定位内存异常导致的间接发热。
2. 系统日志与真机实测
- Console（系统日志） ：过滤关键词（Thermal State：过热降频；wakeup：系统唤醒；network：网络触发），查看异常日志；
- 真机实测（最真实） ：连续运行 APP 10-30 分钟，监测核心指标：CPU 均值＞30%、设备温度＞42℃、耗电＞8%/小时，即为异常；
- 第三方工具：KeyMob（真实环境资源监控）、PerfDog（帧率+能耗监控）、Charles（网络请求抓包）。
3. 线上监控阶段
通过 MetricKit、友盟/蒲公英性能监控，采集线上用户的能耗数据、发热反馈，定位线上偶现的发热/耗电问题（如特定机型、特定场景触发）。
三、分模块深度优化 + 经典实战案例（核心章节）
以下每个模块均包含「核心问题→经典实战案例→优化方案→优化效果」，案例均来自真实项目（覆盖社交、工具、视频类 APP），代码可直接复用，优化效果可量化。
模块一：CPU 优化（最常见，优化见效最快）
CPU 是发热/耗电的“重灾区”，尤其是主线程阻塞、死循环、线程爆炸，会直接导致设备快速发热、耗电翻倍。iOS 26 系统下，CPU 持续高占用还会触发系统降频，导致 APP 卡顿、响应变慢。
经典案例 1：二维码扫描页面发热（死循环导致 CPU 100% 占用）
问题现象：某工具类 APP，用户反馈“打开二维码扫描页面后，手机快速发热，扫描完成后退出页面，发热仍持续，耗电明显加快”。实测发现，退出页面后 CPU 使用率仍维持在 80%-100%，设备温度 5 分钟内升至 45℃。
排查过程：
- 用 Time Profiler 监测，发现
scanAnimate函数持续占用 CPU（90% 以上）； - 查看代码，发现扫描动画的实现存在“递归式死循环”，动画完成后立即再次调用自身，即使页面退出，动画仍在持续执行，导致页面无法释放，CPU 持续高负载。
问题代码（OC） ：
#pragma mark 扫描动画
- (void)scanAnimate{
CGRect rect = CGRectMake(0, - 0.625 * SCREEN_WIDTH, 0.625 * SCREEN_WIDTH, 0.625 * SCREEN_WIDTH);
if (!_lineView) {
_lineView = ((UIImageView alloc) initWithFrame:rect);
[_lineView setImage:[UIImage imageNamed:@"网格"]];
[scanZomeBack addSubview:_lineView];
}else{
_lineView.frame = rect;
}
// 动画完成后，直接调用自身，形成死循环
[UIView animateWithDuration:1.5 animations:^{
_lineView.frame = CGRectMake(0, 0, 0.625 * SCREEN_WIDTH, 0.625 * SCREEN_WIDTH);
} completion:^(BOOL finished) {
[self scanAnimate]; // 此处导致死循环，页面退出后仍执行
}];
}
优化方案：
- 添加布尔值控制动画开关，页面将要消失时关闭动画；
- 使用弱引用 self，避免循环引用导致页面无法释放；
- 动画完成后，通过定时器延迟调用，避免递归死循环。
优化后代码（OC） ：
#define WS(weakSelf) __weak __typeof(&*self)weakSelf = self;
@interface ScanViewController ()
@property (nonatomic, assign) BOOL isAnimateRunning; // 动画开关
@property (nonatomic, strong) NSTimer *scanTimer; // 定时器控制动画
@end
@implementation ScanViewController
- (void)viewDidLoad {
[super viewDidLoad];
self.isAnimateRunning = YES;
[self startScanAnimate];
}
#pragma mark 扫描动画（优化后）
- (void)startScanAnimate{
WS(weakSelf);
CGRect rect = CGRectMake(0, - 0.625 * SCREEN_WIDTH, 0.625 * SCREEN_WIDTH, 0.625 * SCREEN_WIDTH);
if (!_lineView) {
_lineView = ((UIImageView alloc) initWithFrame:rect);
[_lineView setImage:[UIImage imageNamed:@"网格"]];
[scanZomeBack addSubview:_lineView];
}else{
_lineView.frame = rect;
}
[UIView animateWithDuration:1.5 animations:^{
weakSelf.lineView.frame = CGRectMake(0, 0, 0.625 * SCREEN_WIDTH, 0.625 * SCREEN_WIDTH);
} completion:^(BOOL finished) {
// 动画完成后，通过定时器延迟调用，避免死循环
if (weakSelf.isAnimateRunning) {
weakSelf.scanTimer = [NSTimer scheduledTimerWithTimeInterval:0.1 target:weakSelf selector:@selector(resetScanAnimate) userInfo:nil repeats:NO];
}
}];
}
- (void)resetScanAnimate{
_lineView.frame = CGRectMake(0, - 0.625 * SCREEN_WIDTH, 0.625 * SCREEN_WIDTH, 0.625 * SCREEN_WIDTH);
[self startScanAnimate];
}
// 页面将要消失时，关闭动画和定时器，释放资源
- (void)viewWillDisappear:(BOOL)animated{
[super viewWillDisappear:animated];
self.isAnimateRunning = NO;
[_scanTimer invalidate];
_scanTimer = nil;
}
@end
优化效果：退出扫描页面后，CPU 使用率降至 5% 以下，设备温度快速回落，扫描页面耗电降低 80%，彻底解决发热问题。
经典案例 2：列表滑动发热（主线程解析大 JSON + 频繁计算）
问题现象：某社交类 APP，用户反馈“滑动好友列表时，手机发热明显，滑动卡顿，续航时间缩短”。实测发现，滑动时 CPU 均值 60%+，帧率波动在 30-40fps，主线程被阻塞。
排查过程：
- 用 Time Profiler 监测，发现
cellForRowAtIndexPath中，主线程同步解析大 JSON（单条数据 500KB+）、频繁计算文本高度、拼接字符串，导致主线程阻塞； - 列表复用机制未优化，每次滑动都重新创建 Cell、重新计算数据，重复工作过多。
优化方案：
- 将 JSON 解析、文本高度计算、字符串拼接等耗时操作，移至子线程，主线程仅负责 UI 渲染；
- 缓存计算结果（文本高度、解析后的模型），避免重复计算；
- 优化列表复用，复用 Cell 时仅更新数据，不重新创建子视图；
- 精简接口返回数据，移除无用字段，将单条数据压缩至 100KB 以内。
优化效果：滑动时 CPU 均值降至 15% 以下，帧率稳定 60fps，滑动无卡顿，列表页面发热现象彻底消失，耗电降低 65%。
模块二：GPU 渲染优化（视觉类 APP 重灾区）
GPU 重载主要源于“不必要的渲染工作”，尤其是离屏渲染、透明图层叠加、频繁动画，在 iOS 26 系统中，Liquid Glass 特效的滥用更是成为 GPU 重载的主要诱因，导致设备发热、耗电激增。离屏渲染的核心问题的是“上下文频繁切换”，会大幅消耗 GPU 资源，进而引发发热耗电。
经典案例：首页卡片圆角 + 阴影导致发热（离屏渲染）
问题现象：某电商类 APP，首页有 20+ 商品卡片，每个卡片都设置了 cornerRadius + masksToBounds + shadowOpacity，用户反馈“打开首页后，手机背部发热明显，滑动时掉帧”。用 Core Animation 监测，发现所有卡片均出现红色标记（离屏渲染），GPU 占用率 70%+。
问题代码（Swift） ：
// 错误写法：同时设置 cornerRadius + masksToBounds + shadowOpacity，触发离屏渲染
cell.cardView.layer.cornerRadius = 12
cell.cardView.layer.masksToBounds = true
cell.cardView.layer.shadowOpacity = 0.5
cell.cardView.layer.shadowColor = UIColor.black.cgColor
cell.cardView.layer.shadowOffset = CGSize(width: 0, height: 2)
排查过程：
- Core Animation 监测显示，所有商品卡片均触发离屏渲染；
- 分析原因：
masksToBounds = true会裁剪图层，而shadowOpacity > 0会渲染阴影，两者同时设置，会导致 GPU 先渲染阴影、再裁剪，触发离屏渲染； - 20+ 卡片同时触发离屏渲染，GPU 持续高负载，导致发热、掉帧。
优化方案：彻底消灭离屏渲染，采用“预渲染 + 避免图层裁剪”的方式，具体如下：
- 阴影优化：设置
shadowPath缓存阴影路径，避免 GPU 实时计算阴影，同时移除masksToBounds = true； - 圆角优化：用 UIBezierPath 预渲染圆角，或直接使用带圆角的图片资源，避免通过
cornerRadius裁剪； - 图层合并：将卡片的子视图（图片、文字）合并为一个图层，减少渲染次数。
优化后代码（Swift） ：
// 优化方案1：阴影 + 圆角分离，避免离屏渲染
cell.cardView.layer.cornerRadius = 12
// 移除 masksToBounds = true，避免裁剪阴影
// 设置 shadowPath，缓存阴影路径，减少 GPU 计算
cell.cardView.layer.shadowPath = UIBezierPath(roundedRect: cell.cardView.bounds, cornerRadius: 12).cgPath
cell.cardView.layer.shadowOpacity = 0.5
cell.cardView.layer.shadowColor = UIColor.black.cgColor
cell.cardView.layer.shadowOffset = CGSize(width: 0, height: 2)
cell.cardView.layer.shadowRadius = 4
// 开启光栅化，缓存渲染结果（仅适用于静态视图）
cell.cardView.layer.shouldRasterize = true
cell.cardView.layer.rasterizationScale = UIScreen.main.scale
// 优化方案2：预渲染圆角（适用于动态视图）
func drawRoundedCorner(view: UIView, radius: CGFloat) {
let path = UIBezierPath(roundedRect: view.bounds, cornerRadius: radius)
let maskLayer = CAShapeLayer()
maskLayer.path = path.cgPath
view.layer.mask = maskLayer
}
// 调用
drawRoundedCorner(view: cell.cardView, radius: 12)
优化效果：Core Animation 监测无离屏渲染，GPU 占用率降至 10% 以下，首页打开后无发热现象，滑动帧率稳定 60fps，耗电降低 55%。同时，该方案也适配 iOS 26 的 Liquid Glass 渲染特性，避免特效叠加导致的额外能耗。
模块三：网络优化（后台发热第一大原因）
网络交互是后台发热、耗电的“隐形杀手”——高频轮询、短连接泛滥、无效重试、第三方 SDK 后台心跳，都会导致网络模块持续唤醒，即使 APP 退到后台，也会持续耗电、发热。如某视频类 APP 后台上传任务未设置超时，导致网络模块持续重连，后台耗电一小时达 20%。
经典案例：后台高频轮询导致待机发热（每 30 秒一次请求）
问题现象：某 IM 类 APP，为了实时接收消息，采用“每 30 秒发送一次轮询请求”的方式，用户反馈“APP 退到后台后，手机待机时耗电飞快，放在口袋里会发热”。实测发现，后台每 30 秒触发一次网络请求，夜间 8 小时待机耗电达 18%-20%，远超正常水平（3%-8%）。
排查过程：
- 用 Network 工具抓包，发现 APP 退到后台后，仍每 30 秒发送一次 GET 请求，属于无效轮询（大部分请求返回“无新消息”）；
- 查看代码，发现轮询定时器未在后台暂停，且未判断网络状态和电量状态，即使无网络、低电量，仍持续轮询；
- 同时，轮询采用短连接，每次请求都需要重新建立 TCP 连接、断开连接，握手过程消耗大量电量。
优化方案：
- 杜绝轮询，改用 APNs 推送：实时消息走 APNs 推送，后台无需轮询，仅在前台时按需拉取消息；
- 后台暂停轮询：APP 退到后台时， invalidate 轮询定时器，前台激活时重新开启；
- 连接复用：采用 HTTP/2 + 长连接，避免短连接反复握手；
- 增加电量/网络判断：电量＜20% 或蜂窝网络下，暂停非关键网络请求；无网络时，停止轮询并缓存请求，网络恢复后再执行。
优化后代码（Swift） ：
import UIKit
import Network
class NetworkManager: NSObject {
static let shared = NetworkManager()
private var pollTimer: Timer?
private let monitor = NWPathMonitor() // 网络状态监测
// 开启轮询（仅前台开启）
func startPolling() {
guard UIApplication.shared.applicationState == .active else { return }
stopPolling() // 先停止，避免重复开启
// 前台每 2 分钟拉取一次消息（无需高频轮询）
pollTimer = Timer.scheduledTimer(withTimeInterval: 120, repeats: true) { [weak self] _ in
self?.fetchMessage()
}
}
// 停止轮询（后台/低电量/无网络时调用）
func stopPolling() {
pollTimer?.invalidate()
pollTimer = nil
}
// 拉取消息（长连接 + 电量/网络判断）
private func fetchMessage() {
// 1. 判断电量
let batteryLevel = UIDevice.current.batteryLevel
guard batteryLevel > 0.2 else { return } // 电量＜20%，停止拉取
// 2. 判断网络
monitor.pathUpdateHandler = { [weak self] path in
guard path.status == .satisfied else {
self?.stopPolling()
return
}
// 3. 长连接请求（HTTP/2）
let url = URL(string: "https://xxx.com/fetchMessage")!
var request = URLRequest(url: url)
request.httpMethod = "GET"
request.setValue("HTTP/2", forHTTPHeaderField: "Upgrade")
let task = URLSession.shared.dataTask(with: request) { data, response, error in
// 处理消息
}
task.resume()
}
monitor.start(queue: DispatchQueue.global())
}
// 监听 APP 前后台切换
func setupAppStateMonitor() {
NotificationCenter.default.addObserver(self, selector: #selector(appDidEnterBackground), name: UIApplication.didEnterBackgroundNotification, object: nil)
NotificationCenter.default.addObserver(self, selector: #selector(appDidBecomeActive), name: UIApplication.didBecomeActiveNotification, object: nil)
}
@objc private func appDidEnterBackground() {
stopPolling() // 后台停止轮询
}
@objc private func appDidBecomeActive() {
startPolling() // 前台开启轮询
fetchMessage() // 立即拉取一次消息
}
}
优化效果：后台无轮询请求，夜间 8 小时待机耗电降至 3% 以下，后台发热现象彻底消失；前台消息接收延迟控制在 10 秒内（APNs 推送），用户体验无影响。同时，长连接的使用减少了 TCP 握手次数，网络模块耗电降低 70%。
模块四：后台与传感器优化（最隐蔽，易被忽视）
后台任务未及时终止、定位/蓝牙持续开启、Widget 高频刷新，是最隐蔽的发热/耗电元凶。很多开发者会忽视这些细节，导致 APP 即使在后台，也持续消耗资源。如某导航类 APP 未及时关闭定位，后台持续调用 GPS，一天定位相关耗电达 18%。
经典案例：定位服务滥用导致后台发热
问题现象：某外卖类 APP，用户反馈“使用一次外卖定位后，即使关闭 APP，手机仍持续发热，耗电飞快”。实测发现，APP 退出后，定位服务仍在持续运行，GPS 模块持续唤醒，CPU 占用 20%+，每小时耗电 10%+。
排查过程：
- 用 Energy Usage 监测，发现“Location”模块耗电占比 60%+；
- 查看代码，发现定位服务开启后，未在不需要时关闭，且定位精度设置为
kCLLocationAccuracyBest（最高精度，最耗电），即使 APP 退到后台，定位仍在持续。
优化方案：
- 按需开启/关闭定位：仅在需要定位时（如选择收货地址、骑手追踪）开启定位，定位完成后立即关闭；
- 精准控制定位精度：前台定位用
kCLLocationAccuracyHundredMeters（百米级精度，耗电低），导航场景才用kCLLocationAccuracyBestForNavigation； - 后台定位限制：仅导航类场景开启后台定位，其他场景禁止后台定位；
- 监听 APP 后台状态：APP 退到后台后，立即停止定位服务。
优化后代码（Swift） ：
import CoreLocation
class LocationManager: NSObject, CLLocationManagerDelegate {
static let shared = LocationManager()
private let locationManager = CLLocationManager()
private var locationCompletion: ((CLLocation?) -> Void)?
override init() {
super.init()
locationManager.delegate = self
// 按需设置精度（非导航场景，用百米级精度）
locationManager.desiredAccuracy = kCLLocationAccuracyHundredMeters
// 禁止后台定位（非导航类 APP）
locationManager.allowsBackgroundLocationUpdates = false
}
// 开启定位（单次定位，完成后自动关闭）
func requestLocation(completion: @escaping (CLLocation?) -> Void) {
locationCompletion = completion
// 检查权限
switch locationManager.authorizationStatus {
case .authorizedWhenInUse, .authorizedAlways:
locationManager.requestLocation() // 单次定位
case .notDetermined:
locationManager.requestWhenInUseAuthorization()
default:
completion(nil)
}
}
// 定位完成，关闭定位
func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
let location = locations.last
locationCompletion?(location)
// 定位完成，停止定位服务
locationManager.stopUpdatingLocation()
locationCompletion = nil
}
// 定位失败，关闭定位
func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) {
locationCompletion?(nil)
locationManager.stopUpdatingLocation()
locationCompletion = nil
}
// APP 退到后台，停止定位
@objc func appDidEnterBackground() {
locationManager.stopUpdatingLocation()
}
}
// 调用示例（选择收货地址时）
LocationManager.shared.requestLocation { location in
if let location = location {
// 处理定位数据
}
}
优化效果：定位服务仅在需要时开启，完成后立即关闭，定位相关耗电降至 3% 以下，后台无定位唤醒，发热现象彻底消失。同时，精准的精度控制的也避免了 GPS 模块的高负载运行。
模块五：内存优化（间接发热，不可忽视）
内存异常（内存泄漏、大图未释放、OOM 前系统 GC）不会直接导致发热，但会间接加剧发热/耗电：内存泄漏会导致内存持续增长，系统频繁 GC（垃圾回收），GC 过程会占用大量 CPU，进而引发发热；大图未释放会导致内存峰值过高，系统会强制降频，进一步加剧卡顿和发热。如苹果自家 Notes 应用因内存泄漏，导致使用 5-10 分钟后 CPU 温度飙升，机身发烫。
经典案例：大图缓存未释放导致内存泄漏 + 发热
问题现象：某图片浏览类 APP，用户反馈“浏览多张高清图片后，手机发热明显，切换页面卡顿，甚至出现闪退”。实测发现，浏览 10 张高清图片（单张 2MB+）后，内存从 100MB 飙升至 800MB+，CPU 占用 40%+（系统频繁 GC），设备温度升至 43℃。
排查过程：
- 用 Leaks 工具监测，发现图片缓存未释放，
UIImageView与控制器形成循环引用，导致内存泄漏； - 大图未压缩，直接加载到内存，且未做内存缓存限制，导致内存持续增长；
- 页面销毁时，未释放图片资源，导致图片一直占用内存，系统频繁 GC 消耗 CPU。
优化方案：
- 避免循环引用：
UIImageView的代理、闭包用 weak 修饰，页面销毁时置空图片引用； - 大图压缩：加载图片时，根据控件尺寸压缩图片，避免原图加载（如将 2MB 大图压缩至 200KB 以内）；
- 内存缓存限制：使用 SDWebImage 等第三方框架，设置内存缓存上限（如 100MB），超过上限自动清理；
- 页面销毁时释放资源：在
deinit中置空图片、停止图片加载，清理缓存。
优化后代码（Swift） ：
import UIKit
import SDWebImage
class ImageBrowserVC: UIViewController {
@IBOutlet weak var imageView: UIImageView!
private var imageUrl: String?
func setupImage(url: String) {
self.imageUrl = url
// 大图压缩 + 内存缓存
let options: SDWebImageOptions = [.scaleDownLargeImages, .cacheMemoryOnly]
imageView.sd_setImage(with: URL(string: url), options: options) { [weak self] image, error, _, _ in
guard let self = self else { return }
if let error = error {
print("图片加载失败：(error)")
}
}
}
// 页面销毁时，释放资源、清理缓存
deinit {
// 置空图片，停止加载
imageView.image = nil
imageView.sd_cancelCurrentImageLoad()
// 清理单个图片缓存
if let url = imageUrl {
SDImageCache.shared.removeImage(forKey: url)
}
// 清理内存缓存（按需）
SDImageCache.shared.clearMemory()
print("ImageBrowserVC 销毁，内存释放完成")
}
}
// 全局设置 SDWebImage 内存缓存上限
func setupSDWebImageConfig() {
let cache = SDImageCache.shared
cache.config.maxMemoryCost = 100 * 1024 * 1024 // 100MB 内存缓存上限
cache.config.shouldCacheImagesInMemory = true
}
优化效果：浏览 10 张高清图片后，内存稳定在 200MB 以内，无内存泄漏，系统 GC 频率大幅降低，CPU 占用降至 15% 以下，发热现象消失，闪退问题彻底解决。
四、发热/耗电优化最佳实践（落地必看）
结合上述案例，总结 5 条可直接落地的最佳实践，覆盖开发全流程，避免踩坑：
1. 编码阶段：提前规避常见问题
- CPU 层面：避免死循环、主线程耗时操作，线程池化（拒绝无节制使用 GCD 全局队列），缓存计算结果；
- GPU 层面：杜绝不必要的离屏渲染，避免透明图层叠加，动画按需开启、及时停止，慎用 iOS 26 新增特效；
- 网络层面：杜绝轮询，优先用 APNs 推送，长连接复用，增加电量/网络判断；
- 传感器层面：定位/蓝牙/陀螺仪“不用即关”，精准控制定位精度，禁止非必要后台定位；
- 内存层面：避免循环引用，大图压缩，缓存限制，页面销毁时释放资源。
2. 测试阶段：建立性能基线，强制校验
制定 APP 性能基线，测试时严格校验，不达标不发布：
- CPU 均值：前台＜20%，后台＜5%；
- GPU 占用：＜15%，无离屏渲染；
- 网络请求：前台＜1 次/秒，后台＜1 次/5 分钟；
- 内存：稳定无持续增长，峰值＜500MB（视 APP 类型调整）；
- 耗电：前台＜8%/小时，后台＜2%/小时，夜间待机＜3%/8 小时。
3. 线上监控：持续追踪，及时迭代
- 通过 MetricKit、友盟等工具，采集线上能耗数据，定位偶现的发热/耗电问题；
- 关注用户反馈，重点排查“特定机型（如 iPhone 17e）、特定系统（如 iOS 26）、特定场景”的发热问题；
- 定期迭代优化，每版本都做发热/耗电回归测试。
4. 第三方 SDK 治理
- 关闭第三方 SDK（埋点、统计、广告）的后台心跳、自动上报功能；
- 禁止 SDK 后台自启，仅在前台激活时初始化 SDK；
- 定期排查 SDK 能耗，淘汰高耗电、无必要的 SDK。
5. 系统特性适配
- 适配 iOS 26 特性：合理使用 Liquid Glass 特效，避免特效叠加导致的 GPU 重载；
- 关闭非必要系统功能：如后台 App 刷新、Widget 高频刷新，按需保留刚需功能；
- 适配新机型：针对 iPhone 17 系列等新机型，优化图层渲染、内存管理，避免硬件适配问题导致的发热。
五、总结
iOS APP 发热与耗电优化，核心不是“盲目优化代码”，而是“精准定位问题、针对性解决”——先通过工具找到发热/耗电的核心元凶（CPU/GPU/网络/传感器/内存），再结合实际场景，落地对应的优化方案。
本文的 5 个经典案例，覆盖了开发中最常见的发热/耗电场景，代码可直接复用，优化效果可量化。需要注意的是，优化是一个持续迭代的过程，没有“一劳永逸”的优化方案，尤其是在 iOS 系统不断更新（如 iOS 26）、新机型不断发布的背景下，需要持续关注系统特性和用户反馈，不断优化 APP 性能。
发热源于持续高负载，耗电源于频繁唤醒；优化的核心是：CPU 少算、GPU 少画、网络少发、后台少动、传感器少开，抓住这个核心，就能解决 99% 的发热/耗电问题。
