iOS应用发生Out of Memory崩溃，寻求崩溃成因分析

核心崩溃原因 #

从崩溃日志的Last Exception Backtrace可以明确，这是**内存耗尽（OOM）**导致的崩溃：

• 系统在尝试为CFString分配内存时失败，触发__CFStringHandleOutOfMemory，进而抛出_CFRaiseMemoryException，最终导致进程被终止。

触发路径拆解 #

崩溃发生在UI布局流程中，完整调用链如下：

1. LEEAlert弹窗触发视图布局（lee_alert_view_layoutSubviews）
2. 进入UILabel的布局计算流程，需要计算其intrinsicContentSize（固有内容尺寸）
3. 为了计算尺寸，UILabel需要合成对应的富文本（_synthesizedAttributedText）
4. 合成富文本时创建NSConcreteMutableAttributedString，调用CFString的内存扩容方法__CFStringChangeSizeMultiple
5. 此时系统剩余内存不足以满足扩容需求，直接触发OOM异常

场景推测 #

崩溃发生在显示LEEAlert弹窗的场景下，大概率是以下情况之一：

• 弹窗内的UILabel绑定了超长未截断的文本，或者包含大量复杂的富文本属性（比如多段不同样式的文本），导致文本合成时需要占用大量内存
• App在弹窗显示前已经存在较高的内存占用（比如内存泄漏、大对象未释放），叠加文本布局的内存需求后，直接耗尽系统可用内存

排查与优化建议 #

• 检查文本内容：确认弹窗内UILabel的文本是否过长，是否需要提前做截断处理；排查富文本是否存在不必要的复杂样式
• 监控内存状态：在弹窗显示前，检查App的内存占用情况，排查是否存在内存泄漏、大对象（如大图、缓存数据）未及时释放的问题
• 优化文本布局：对于超长文本，考虑异步预计算文本尺寸，避免在主线程布局时集中消耗内存；或者限制UILabel的最大行数，减少布局计算的内存开销
• 检查弹窗实现：确认LEEAlert是否存在重复触发布局的逻辑（比如布局回调中重复修改约束），导致多次重复计算文本尺寸，加剧内存消耗

内容的提问来源于stack exchange，提问作者jian lu