核心Haptics和核心蓝牙干扰吗？

Question

设置

我的iOS应用程序正在与BLE设备通信。作为对此交流中某些事件的回应，我想向用户提供触觉反馈。

为了支持像iPhone 7这样的旧手机，我决定为此使用UIFeedbackGenerator，特别是UIImpactFeedbackGenerator。

现在，当在BLE上接收到上述事件时，我调用feedbackGenerator.impactOccurred()。

行为

在呼叫时，没有发生触觉反馈。但是系统仍然记得这些对UIFeedbackGenerator的调用。

因为，当用户随后与UI元素交互时，所有对feedbackGenerator.impactOccurred()的调用都会立即触发，并提供触觉反馈作为对该UI交互的响应。这对用户来说是相当令人困惑的，他们当时并没有预料到触觉反馈。此外，如果有足够多的电话随着时间的推移累积起来，触觉反馈可能会相当强烈。

当这些被遗忘的触觉反馈调用累积到足够多的时候，系统似乎被重载了；控制台中生成了以下日志几十次：

‘t:295：-CAReportingClient init_block_invoke:无法与助手应用程序通信

无论如何，根据UIFeedbackGenerator的苹果文档，这是可以预料到的行为。

注意到，调用这些方法并不直接使用触觉。相反，它会将事件通知系统。然后，系统根据设备、应用程序的状态、电池剩余电量和其他因素确定是否播放触觉。

我的问题

您是否有使用核心蓝牙改变CoreHaptics或UIFeedbackGenerator行为的经验？这是我调试的起点，因为当我在本地模拟通信的所有部分时，触觉反馈工作得很好。

我已经尝试过的

• 从主/后台线程
• 调用UIFeedbackGenerator，使用UINotificationFeedbackGenerator代替UIFeedbackGenerator上的UINotificationFeedbackGenerator prepare()。

F 232

Answer 1

结果，我在CoreBluetooth实现中没有给予足够的关注。我计划经常向特征发送数据的工作人员正在DispatchQueue.global(qos: .userInitiated)中运行。

因为我和我的工作人员阻塞了这个队列，CoreHaptics决定最好不要马上播放反馈信息。

这个故事的寓意是:注意你使用的队列。