我之前做一款有声书iOS应用的时候，正好碰到过几乎一模一样的问题！首次触发拖拽、调用itemsForBeginningSession:代理方法的瞬间，正在播放的音频会突然卡顿一下，之后再拖拽就完全正常了，当时折腾了好一阵才找到根源和解决办法。

这个问题的核心原因其实和你遇到的键盘首次弹出卡顿逻辑类似：iOS系统在首次触发拖拽会话时，会同步完成一系列拖拽相关组件的初始化工作——比如拖拽手势识别的资源分配、拖拽预览的渲染服务启动等——这些同步操作会短暂抢占主线程甚至音频线程的资源，导致正在播放的音频出现断续。

分享几个亲测有效的解决思路：

• 提前预初始化拖拽系统组件
  和你预加载键盘的思路一致，我们可以在应用启动后、音频开始播放前，后台触发一次“假”的拖拽会话，让系统提前完成初始化，避免用户操作时的卡顿。示例代码如下：

  func prewarmDragSystem() {
      // 创建一个空的拖拽item，仅用于触发系统初始化流程
      let dummyItem = UIDragItem(itemProvider: NSItemProvider())
      // 找到当前视图的拖拽交互对象
      if let dragInteraction = view.interactions.first(where: { $0 is UIDragInteraction }) as? UIDragInteraction {
          // 调用代理方法触发系统预加载，返回nil不影响实际功能
          _ = dragInteraction.delegate?.dragInteraction?(dragInteraction, itemsForBeginning: UIDragSession())
      }
  }
  

  可以在application(_:didFinishLaunchingWithOptions:)或者音频播放器初始化完成后调用这个方法，用户完全感知不到这个操作，但后续真实拖拽就不会再卡顿了。

• 优化itemsForBeginningSession:的执行效率
  如果你在这个代理方法里做了音频元数据处理、预览图生成等耗时操作，一定要把这些逻辑移到后台线程，保证代理方法能快速返回。比如：

  func dragInteraction(_ interaction: UIDragInteraction, itemsForBeginning session: UIDragSession) -> [UIDragItem] {
      // 耗时操作异步执行
      DispatchQueue.global(qos: .userInitiated).async {
          self.generateAudioDragPreview()
          self.processAudioMetadataForDrag()
      }
      // 先返回基础的拖拽item，不阻塞主线程
      let itemProvider = NSItemProvider(object: self.currentAudioID as NSString)
      return [UIDragItem(itemProvider: itemProvider)]
  }
  

• 提升音频会话的优先级
  虽然iOS本身会优先保障音频线程，但可以通过设置音频会话的服务质量进一步强化优先级，减少被系统操作抢占的概率：

  do {
      let audioSession = AVAudioSession.sharedInstance()
      try audioSession.setCategory(.playback, mode: .default)
      try audioSession.setActive(true)
      // 将音频播放线程的优先级设为最高
      Thread.current.qualityOfService = .userInteractive
  } catch {
      print("音频会话设置失败：\(error)")
  }
  

其实不少开发者都在讨论这个问题，核心都是围绕“避免首次用户操作时的系统初始化阻塞”，预初始化的方案是目前最通用且有效的，和你之前解决键盘卡顿的思路完全契合。

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