iOS 性能问题定位方法

“页面有点卡”可能来自主线程计算、布局、图片解码、锁等待或内存压力。直接凭经验修改代码容易把耗时转移到别处。有效的性能优化应从稳定复现开始，使用时间线和调用栈确认瓶颈，再用相同条件验证改动。

一、先把问题描述具体

性能问题应转换为可观察场景，例如：

• 首次进入详情页停顿半秒。
• 长列表快速滚动时周期性掉帧。
• 连续浏览图片后内存基线增长。
• 点击提交后主线程无响应。
• 应用切回前台时界面冻结。

明确设备、系统版本、数据量和操作路径，团队才能复现同一个问题。

二、建立基线

优化前记录多次结果，包括耗时分布、峰值内存和关键调用次数。单次测量容易受系统后台任务、缓存和温度影响。

调试构建包含额外检查，最终判断应使用接近正式配置的构建，同时保留足够符号用于定位调用栈。

三、检查主线程长任务

主线程负责事件、布局和绘制。任何连续占用都会推迟交互响应。时间分析中重点查看：

• JSON 解码和模型转换。
• 图片读取与解码。
• 数据库同步查询。
• 大数组排序和过滤。
• 自动布局反复求解。
• 锁等待和同步队列调用。

找到调用栈后再决定是减少工作、移动到后台还是分批处理。

四、区分 CPU 与等待

耗时长不一定消耗大量处理器。线程可能在等待锁、磁盘或同步任务。只看函数总耗时会误判。

如果主线程同步等待后台结果，应改为异步数据流；如果多个线程争抢同一锁，则需要缩短临界区或重新设计共享状态。

五、分析列表掉帧

列表问题可以按阶段检查：

• 单元格创建是否过多。
• 配置方法是否格式化和解析大对象。
• 图片是否在主线程解码。
• 自适应高度是否反复变化。
• 数据更新是否重载整表。
• 滚动回调是否执行重计算。

使用展示模型、差量更新和目标尺寸图片前，先确认对应阶段确实是热点。

六、观察内存增长

内存上升可能来自缓存、暂时峰值或泄漏。重复进入退出页面，观察对象数量和退出后的基线。

若目标控制器未释放，沿强引用路径检查闭包、观察者、计时器和任务。若对象能释放但峰值过高，则关注图片解码、批量数据和同时运行任务数量。

七、检查分配频率

即使对象很小，在滚动或动画每帧大量创建也会增加引用计数和回收成本。重点检查绘制、布局与格式化循环中的临时数组、字符串和图形对象。

缓存对象只在创建成本明显且输入稳定时有价值。无边界缓存会把 CPU 问题变成内存问题。

八、使用业务阶段标记

在请求、解析、持久化和渲染等边界记录非敏感阶段耗时，可以把系统时间线与业务行为对应起来。

protocol PerformanceClock {
    func now() -> TimeInterval
}

struct SystemPerformanceClock: PerformanceClock {
    func now() -> TimeInterval {
        ProcessInfo.processInfo.systemUptime
    }
}

struct PerformanceStage {
    let name: String
    let startedAt: TimeInterval
}

单调递增时间适合计算进程内耗时，不受用户修改系统时间影响。项目已有计时组件时优先复用，标记名称保持稳定，不能包含用户敏感数据。

九、关注能耗和温度

持续轮询、过度动画、高频定位和重复请求会增加能耗。设备升温后系统可能降低性能，问题表现为运行一段时间后越来越卡。

优化时不仅看单次速度，也观察任务频率、后台执行和通信次数。合并展示刷新时不能丢失必须完整处理的业务数据。

十、验证而不是相信改动

每次只改变一个主要变量，在相同设备和数据下重复测量。还要检查功能、内存和耗电是否回退。

一次优化完成后，把可重复场景加入性能回归流程。新功能引入重型依赖或布局时，能尽早发现基线变化。

总结

iOS 性能定位应从具体场景和基线开始，通过调用栈区分计算、等待、布局和内存问题。找到最主要瓶颈后做最小改动，再用相同条件复测。测量驱动的方法不仅更可靠，也能避免用复杂缓存掩盖真正问题。