Apple Watch表盘组件内存超限崩溃问题排查求助

问题概述 #

Apple Watch表盘组件（Complication）在真机上出现内存快速增长问题，3-5秒内达到15MB限制后崩溃，报错：

Thread 1: EXC_RESOURCE (RESOURCE_TYPE_MEMORY: high watermark memory limit exceeded) (limit=15 MB)

崩溃堆栈核心指向PNG编解码流程（lzfseDecode/PNGWritePlugin::writePNG/CGImageDestinationFinalize等系统API），且仅在watchOS 10.2真机（Apple Watch SE 2/Apple Watch 9）复现，模拟器无问题。

已验证：移除所有自定义图片、字体后问题仍存在；添加日志发现未显示的Complication也多次触发onAppear，推测存在屏幕外无意义渲染。

核心解决方案 #

1. 限制Complication的不必要渲染 #

WidgetKit/Complication框架可能预渲染所有注册的Complication类型，即使未被用户添加到表盘。针对这个问题：

• 在View层级中，仅在当前Complication处于活跃状态时才执行渲染逻辑：

  struct MyComplicationView: View {
      @Environment(\.complicationActive) var isActive
      
      var body: some View {
          if isActive {
              // 仅当组件活跃时渲染实际内容
              Text("Active Content")
          } else {
              // 非活跃状态返回极简占位
              Color.clear
          }
      }
  }
  

• 改用task(id:)绑定活跃状态，仅在激活时加载数据/执行重型操作：

  .task(id: isActive) {
      guard isActive else { return }
      // 执行数据加载、渲染准备等操作
  }
  

2. 优化系统级PNG编解码内存占用 #

从堆栈看，内存增长源于系统对图像的解码/编码操作，即使移除自定义图片，系统仍可能处理Complication的默认渲染缓存：

• 禁用Complication的图像缓存：在getTimelineEntries中避免返回带图像的TimelineEntry，或使用低内存模式的ImageRenderer：

  let renderer = ImageRenderer(content: myContentView)
  renderer.scale = UIScreen.main.scale
  renderer.format.preferredRange = .standard // 限制色彩范围降低内存
  

• 手动管理图像内存：如果必须使用图像，用preparingForDisplay()提前解码并优化内存：

  if let imageData = try? Data(contentsOf: imageURL) {
      let image = UIImage(data: imageData, scale: 1.0)?.preparingForDisplay()
  }
  

3. 规避watchOS 10.2系统bug #

该问题仅在watchOS 10.2出现，大概率是系统Complication渲染框架的bug：

• 升级watchOS到最新正式版/测试版，苹果可能已修复该内存泄漏问题；
• 简化Complication的View层级，避免嵌套复杂视图（如ZStack/List），改用扁平化布局；
• 禁用不必要的动态刷新：如果组件不需要实时更新，将getTimelineRefreshPolicy返回.never，减少系统重复渲染次数。

4. 替代Instruments的内存排查方案 #

由于Instruments在Watch上不稳定，可通过以下方式手动排查：

• 在onDisappear中添加内存日志，打印当前进程内存占用：

  import Foundation
  import UIKit
  
  func printMemoryUsage() {
      var info = mach_task_basic_info()
      var count = mach_msg_type_number_t(MemoryLayout<mach_task_basic_info>.size)/4
      let kerr = withUnsafeMutablePointer(to: &info) {
          $0.withMemoryRebound(to: integer_t.self, capacity: 1) {
              task_info(mach_task_self_, task_flavor_t(MACH_TASK_BASIC_INFO), $0, &count)
          }
      }
      if kerr == KERN_SUCCESS {
          print("Memory used: \(info.resident_size / 1024 / 1024) MB")
      } else {
          print("Error getting memory info: \(kerr)")
      }
  }
  

• 逐个注释Complication的注册类型，排查哪个类型触发了过度渲染；
• 使用Xcode的"Debug Memory Graph"功能，在崩溃前捕获内存快照，查看是否有大量重复的View实例或系统图像缓存对象。

总结 #

当前问题核心是watchOS 10.2系统对Complication的过度渲染，导致大量屏幕外组件执行渲染逻辑，触发系统图像编解码的内存爆炸。优先通过限制非活跃组件渲染、简化视图层级缓解，同时等待苹果系统修复。

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