iOS App 开发阶段性能优化，观察 CPU、内存和日志变化-KeyMob User Guide

在开发阶段谈性能优化，往往会被误解成提前做 Instruments 分析。真正参与过项目的人都知道，大多数性能问题并不是在某一次专项测试中被发现的，而是在功能逐渐堆叠、调试频繁、环境切换不断的过程中慢慢积累出来的。

这篇文章想讨论的不是“性能优化方法论”，而是 在开发阶段，如何用一组工具把性能问题持续暴露出来，以及这些工具在日常开发中具体该怎么配合使用。

性能问题，通常不是一次性出现的

以一个常见场景为例：
一个页面最初只有简单列表，CPU 和内存都很平稳；后来加了埋点、网络请求、图片缓存，性能开始波动；再之后接入 SDK，偶发卡顿才真正显现。

如果等到测试阶段再集中分析，很难还原是哪一步引入的问题。所以在开发阶段，我更倾向于 边写功能，边观察资源变化。

在 Mac 上，Xcode 和 Instruments 依然是分析细节的利器，比如：

但在实际开发中，它们更适合“问题已经明确”的情况，而不是长期常开。

原因很简单：

这也是我开始引入辅助工具的原因。

在功能联调阶段，我通常会做一件事那就是把性能监控当成日志一样常开，而不是测试任务。

这里我会使用克魔（KeyMob）作为常驻监控工具：

此时，开发者可以一边调试功能，一边观察资源曲线是否出现异常抬升。

有一次在开发阶段，页面切换并没有明显卡顿，但内存曲线在每次进入页面后都会缓慢上升。

操作过程大致是：

结果是：页面退出后，内存没有明显下降。

这时再切回 Xcode，用 Allocations 定位对象，效率就会高很多。
也就是说，克魔负责发现趋势，Xcode 负责确认原因。
内存监控

开发阶段我会非常频繁地查看日志，但并不只是为了 crash。

通过克魔的【实时日志】功能，可以在不依赖 Xcode 的情况下看到 NSLog 输出，尤其适合以下场景：

我通常会在日志中加一些轻量标记，比如页面生命周期、任务开始结束点，再结合性能曲线，就能快速判断是哪段逻辑拉高了资源占用。

在一个相对成熟的开发流程中，我常用的组合是：

这些工具并不是互相替代，而是覆盖不同阶段。

很多团队会把性能优化放在功能完成之后，但实际体验是：

而在开发阶段，通过工具持续观察，很容易在引入问题的那一刻就发现异常，甚至在提交代码前就修掉。