在 iOS 开发里， 实时日志几乎是每个工程师每天都会用到的东西。
但真正让人头疼的，往往不是“有没有打日志”，而是当问题出现时：

• 日志是不是还在
• 日志是不是完整
• 日志能不能对应到当下的操作
• 日志是不是被别的噪声淹没了

很多线上或测试阶段的问题，其实并不复杂，但只要 实时日志缺失或不连续，排查成本就会被无限放大。

实时日志的问题，通常不是没打印，而是看不到

有一次在做联调时，遇到一个看似简单的问题：
某个接口在部分设备上偶发失败，但重试又能成功。

开发第一反应是让测试把日志发过来，结果拿到的只有几行零散的 NSLog，前后上下文完全对不上。
当时才意识到一个问题：日志是有的，但没有全部读取到。

Xcode Console 的局限，很多人其实已经习惯了

大多数情况下，我们都是直接用 Xcode 的 Console 看实时日志：

• 连接设备
• Run
• 看 NSLog / os_log

在开发阶段，这确实够用。但一旦进入稍微复杂一点的场景，它的问题就会暴露出来：

• 日志量一大，很快被刷走
• 多进程（WebKit、Extension）日志混在一起
• 断开连接后日志就没了
• 无法很好地按 App、进程、关键字长期观察

当问题不是“立即复现”的时候，Xcode Console 往往就显得力不从心。

Console.app 能看到更多，但并不轻松

macOS 自带的 Console.app 能看到系统级日志，包括：

• App 日志
• WebKit 进程日志
• 系统警告
• sandbox / permission 相关信息

但它的使用体验并不友好：

• 日志量巨大
• 过滤条件复杂
• 不太适合持续盯着某一个 App
• 对非开发人员不友好

在一次需要长时间观察日志的测试中，我们试过用 Console.app，结果是：
信息很多，但真正有用的内容反而更难找。

实时日志，往往需要跟着运行走

后来在排查另一个问题时，我开始刻意调整思路：
不再把日志当成“事后分析材料”，而是当成 运行过程的一部分。

这时用到的是 克魔（KeyMob）。

最初并不是因为它“能看日志”，而是因为它在真机环境下，可以把日志、性能、运行状态放在一个连续的时间线上。

用 KeyMob 看实时日志，关键不在“多”，而在“连续”

在 KeyMob 里查看 iOS App 实时日志时，有几个细节让我印象比较深：

• 日志不会因为断开 Xcode 而消失
• 可以按 App、进程、关键字过滤
• 日志和当前操作几乎是同步的
• 在长时间运行时，日志依然是连续的

这在一些“慢性问题”上非常有用，比如：

• 某个操作偶发触发异常
• 后台切前台后逻辑不一致
• WebView 页面在某些时刻行为异常

这些问题，往往需要你 盯着日志跑完整个操作流程，而不是只看某个时间点。

WebView 场景下，实时日志尤其容易断层

如果 App 里有 WebView、uni-app 或混合页面，实时日志的复杂度会明显上升。

这时，单靠 Native 日志是不够的。

我一般会同时使用：

• Safari Inspector：看 JS console、前端报错
• KeyMob：看 App 侧实时日志、系统日志

在一次白屏问题排查中，就是通过对比这两边的日志时间点，才发现：

• Native 侧并没有明显异常
• WebView 进程在某个时刻被系统重启
• 重启前有连续的内存和日志警告

如果没有连续的实时日志，很难把这些线索串起来。

网络相关问题，实时日志也很关键

还有一类问题，看起来是“接口失败”，但本质并不只是网络。

在某次弱网测试中，我们发现：

• 接口请求确实发出去了
• 服务端返回也正常
• 但 App 偶发解析失败

通过 Charles 抓包，只能确认网络层没问题。
真正的线索，反而出现在实时日志里：

• 某次解析异常前，日志里已经出现警告
• 同一时间 CPU 有短暂峰值
• 后续逻辑走了异常分支

如果只是事后看零散日志，这些细节很容易被忽略。

实时日志不是“单独使用”的工具

在现在的工程实践中，我基本不会单独谈“怎么看实时日志”，而是把它放进一个组合里：

• Xcode Console：开发调试、快速验证
• KeyMob：真机实时日志、长期观察
• Console.app：系统级异常补充
• Safari Inspector：Web 相关日志
• Charles：网络行为对照

实时日志的价值，往往体现在 和别的信号一起看的时候。

其实看这些经历，会发现很多问题并不是“没有日志”，而是：

• 日志没被连续记录
• 日志和操作脱节
• 日志和系统行为没有放在一起看

当实时日志真正和运行过程同步的时候，很多原本模糊的问题，其实就会自己出来。