iOS 在從外圍設備傳入 BLE 連接時停止喚醒應用程序

Question

我們有一個 BLE 外設，每小時連接到手機並傳遞一些數據。 以下是該過程的工作原理：

使用密鑰UIApplicationLaunchOptionsBluetoothCentralsKey啟動時

1. application(didFinishLaunchingWithOptions launchOptions)應用程序使用傳遞給它的 ID 重新初始化 CBCentralManager。
2. 然后它通過常規的恢復周期並從 BLE 外設讀取數據。
3. 對雲中的服務執行 REST 請求。

假設該應用程序在手機重啟后至少啟動了一次，一切正常運行幾天（如果應用程序沒有運行或被強制耗盡內存，iOS 會再次正確啟動它，假設用戶沒有手動強制關閉）。

然而，每隔幾天當有來自 BLE 設備的傳入請求時，iOS 就會停止喚醒應用程序。 如果用戶重新啟動應用程序，一切正常運行幾天，然后再次停止。 鑒於我們產品的性質，讓我們的應用程序/外圍設備以盡可能可靠的方式協同工作至關重要。

關於它可能發生的原因的理論：
（經過仔細檢查，他們都被解雇了）

• 用戶重新啟動手機而忘記重新啟動應用程序。
  我們添加了正常運行時間的日志記錄，它表明手機在應用程序啟動之間沒有重新啟動。

• 內存警告導致應用程序被啟動。
  再次添加日志記錄，他們顯示沒有applicationDidReceiveMemoryWarning

• 連接不良導致應用在上傳結果時運行時間超過 10 秒，iOS 終止它並感到不安
  我們人為地將服務器響應延遲了 15 秒來測試這一點，並且在測試期間一切都繼續正常工作。

關於正在發生的事情以及為什么 iOS 停止通知應用程序有關傳入 BLE 連接的任何想法？

問題之一是我們無法弄清楚如何可靠地重現問題所以任何建議也將不勝感激！

謝謝！

---

更新 1：這是我們如何初始化CBCentralManager ：

self.centralManager = CBCentralManager(delegate: self, queue: nil, options: [
    CBCentralManagerOptionRestoreIdentifierKey : MyCentralManagerID,
    CBCentralManagerOptionShowPowerAlertKey : 0])

我看到了一些建議，隊列參數不應為零。 鑒於我無法可靠地重現問題，在我可以自信地觀察到其影響之前，我會猶豫是否要進行更改。

Answer 1

我想首先說我已經使用 CoreBluetooth 很長時間了，從我注意到 CoreBluetooth State Preservation and Restoration 根本不可靠地工作。 你可以讓它“正常”工作，但除非蘋果有一天修復它，否則你永遠不會讓它可靠地重新連接。

有很多錯誤會導致此功能無法正常工作，但我會給您一個我認為會導致您出現問題的錯誤：

如果事件源自您正在與之通信的外圍配件，例如連接/斷開連接事件和特征通知，則狀態恢復只會由於藍牙相關活動而重新啟動您的應用程序。 對於其他事件，最重要的是一般藍牙狀態更改事件，您的應用程序不會重新啟動並通知此事件。 之所以如此糟糕，是因為所有藍牙狀態更改事件都將取消所有掛起或當前連接，這意味着掛起的連接將被刪除並且您的應用程序不會收到通知。 這實際上意味着您的應用程序仍然會認為連接仍在等待中，而實際上它們並非如此。 由於您的應用程序此時已終止，因此再次喚醒它的唯一方法是讓用戶再次手動啟動它（或者為此目的“破解”其他后台模式，這也不太可靠）。

如果用戶切換飛行模式、切換藍牙、重啟 iOS 設備或任何其他導致狀態更改的未定義原因，就會發生這種情況……

但這只是一個錯誤。 還存在許多其他問題，例如 XPC 連接在不同時間無緣無故中斷。 我還注意到掛起的連接可以進入“limbo”模式，其中外圍狀態設置為連接，但實際上它永遠不會連接，除非你循環連接狀態。

總之，我感到非常難過，說出來，但如果你正在開發必須依賴於周邊在后台被重新連接的應用程序，然后我不建議這樣做。 你會很沮喪。 我可能會寫一篇關於 Apple 不想修復的 Core Bluetooth 中的所有錯誤的文章。 更奇怪的是，您可以通過一個應用程序輕松破壞設備上的全局藍牙連接，因此在設備重新啟動之前，任何應用程序都無法使用藍牙。 這非常糟糕，因為它違背了 Apple 自己的沙盒原則。