iOS Notification Service Extension启动缓慢被杀死问题求助

我之前在处理TestFlight分发的应用时，也碰到过几乎一模一样的问题——部分设备上Notification Service Extension启动耗时接近1s触发超时，被SpringBoard杀死。结合自己的排查经验和社区里的方案，给你几个可以尝试的方向：

1. 彻底清理扩展启动时的同步耗时操作 #

从日志看启动耗时刚好卡在1s阈值，大概率是扩展初始化阶段有同步阻塞操作

• 检查didReceiveNotificationRequest:withContentHandler:方法里的代码，有没有同步网络请求、大文件读取、复杂JSON解析、加密运算这类操作？哪怕是看似简单的UserDefaults读取，在系统负载高的时候也可能拖慢启动。
• 把所有非必要的初始化逻辑移到dispatch_async后台队列，或者延迟到通知内容处理完成后再执行。核心原则是：让扩展在1s内快速完成核心的通知内容修改，其他操作全部后置。

2. 优化扩展的编译与链接配置 #

TestFlight的Release包和本地Debug包的启动逻辑差异很大，调整这些配置能有效降低启动耗时：

• 确保开启Dead Code Stripping和Link Time Optimization (LTO)：这两个选项会在编译时移除无用代码、优化符号链接，大幅减少二进制加载时间。
• 统一主App和扩展的Deployment Target：如果扩展的部署目标比主App低，系统会加载额外的兼容库，拖慢启动速度。建议设置成和主App一致的版本。
• 检查Release模式下的Preprocessor Macros：有没有调试相关的宏（比如DEBUG=1）还在生效？这些宏可能会引入调试代码，增加启动负担。

3. 分析TestFlight包的启动链路差异 #

用Instruments工具针对扩展做启动耗时分析：

• 选择App Launch模板，直接启动扩展（可以通过推送触发），重点看DYLD阶段的耗时——比如动态库加载、符号解析的时间。TestFlight包经过App Store的优化，可能和本地包的依赖加载顺序不同。
• 用otool -L [ExtensionBinaryPath]命令查看扩展的依赖库，确认有没有冗余的框架，或者和主App重复的静态库（哪怕是静态链接，重复的库也会增加符号解析时间）。

4. 排查系统与设备的针对性问题 #

因为是部分设备出现问题，需要统计问题设备的特征：

• 是不是集中在iOS 15及以下的系统？旧系统对Extension的超时阈值可能更严格，或者内存管理机制不同。
• 是不是老旧设备（比如iPhone 8及以前）？这类设备的CPU和内存资源有限，扩展启动时容易被系统优先级调度影响。针对这些设备，可以简化扩展的功能（比如跳过非必要的富媒体处理），或者提前在主App里预加载部分资源。

5. 用系统日志深挖启动阻塞点 #

通过sysdiagnose获取完整的系统日志，里面会有更多DYLD启动的细节：

• 触发问题后，在设备上运行sysdiagnose（设置-隐私与安全性-分析与改进-立即开始生成诊断报告），导出后搜索xxx.Notification-Service相关的日志，看有没有DYLD加载失败、权限受限的提示。
• 可以在扩展的main.m里添加极早期的日志（比如在int main()开头就打日志），对比日志时间戳，定位启动卡在哪个阶段。

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