在开发阶段谈性能优化，往往会被误解成提前做 Instruments 分析。真正参与过项目的人都知道，大多数性能问题并不是在某一次专项测试中被发现的，而是在功能逐渐堆叠、调试频繁、环境切换不断的过程中慢慢积累出来的。
这篇文章想讨论的不是"性能优化方法论"，而是 在开发阶段，如何用一组工具把性能问题持续暴露出来，以及这些工具在日常开发中具体该怎么配合使用。
性能问题，通常不是一次性出现的
以一个常见场景为例：
一个页面最初只有简单列表，CPU 和内存都很平稳；后来加了埋点、网络请求、图片缓存，性能开始波动；再之后接入 SDK，偶发卡顿才真正显现。
如果等到测试阶段再集中分析，很难还原是哪一步引入的问题。所以在开发阶段，我更倾向于 边写功能，边观察资源变化。
Xcode 仍然重要，但不适合所有场景
在 Mac 上，Xcode 和 Instruments 依然是分析细节的利器，比如：
- Time Profiler 看函数调用
- Allocations 查对象分配
- Leaks 验证内存泄漏
但在实际开发中，它们更适合"问题已经明确"的情况，而不是长期常开。
原因很简单：
- Instruments 启动成本高
- 多次 Attach/Detach 打断开发节奏
- 很难长时间后台运行观察趋势
这也是我开始引入辅助工具的原因。
开发阶段更需要"低打扰"的性能监控
在功能联调阶段，我通常会做一件事那就是把性能监控当成日志一样常开，而不是测试任务。
这里我会使用克魔（KeyMob）作为常驻监控工具：
- 连接真机后进入【性能图表】
- 勾选 CPU、内存、FPS
- 选择系统总进程 + 当前 App
- 点击开始后，不再频繁中断
此时，开发者可以一边调试功能，一边观察资源曲线是否出现异常抬升。
一个具体例子：页面切换导致的内存滞留
有一次在开发阶段，页面切换并没有明显卡顿，但内存曲线在每次进入页面后都会缓慢上升。
操作过程大致是：
- 用克魔监控内存曲线
- 反复进入和退出目标页面
- 观察内存是否回落
结果是：页面退出后，内存没有明显下降。
这时再切回 Xcode，用 Allocations 定位对象，效率就会高很多。
也就是说，克魔负责发现趋势，Xcode 负责确认原因 。
日志，不只是为排错服务
开发阶段我会非常频繁地查看日志，但并不只是为了 crash。
通过克魔的【实时日志】功能，可以在不依赖 Xcode 的情况下看到 NSLog 输出，尤其适合以下场景：
- App 非 Debug 构建
- 设备被测试同事使用
- 需要同时观察多个行为
我通常会在日志中加一些轻量标记，比如页面生命周期、任务开始结束点，再结合性能曲线，就能快速判断是哪段逻辑拉高了资源占用。
多工具组合，而不是替代关系
在一个相对成熟的开发流程中，我常用的组合是：
- 克魔：持续观察 CPU、内存、FPS、日志
- Xcode / Instruments：深入分析已确认的问题
- 抓包工具：验证网络请求是否影响性能
- TestFlight：对接真实用户环境验证结果
这些工具并不是互相替代，而是覆盖不同阶段。
为什么开发阶段就值得做这些事
很多团队会把性能优化放在功能完成之后，但实际体验是：
- 修改成本高
- 责任边界模糊
- 问题难以复现
而在开发阶段，通过工具持续观察，很容易在引入问题的那一刻就发现异常，甚至在提交代码前就修掉。