iBeacon Monitoring＆RangingとCoreBluetoothscanForPeripheralsWithServicesを介したビーコンの検出
BLEビーコン\周辺機器をスキャンしたいアプリにiOSによって適用される制限に関しては多くの混乱があります。いくつかのブログとStackOverflowの回答を読んだ後、すべての問題を正しく理解しているかどうかを確認したいと思います。誤解したり見逃したりしたことがあれば訂正してください。私はiOS7以降のみを参照し、接続ではなく検出に焦点を当てています（iBeacon Monitoring＆Ranging APIを使用してCLBeaconに接続できますか？）。
ビーコンのオプションは明確です-汎用BLEペリフェラルを使用するか、 iBeacon形式 でアドバタイズするBLEペリフェラルを使用します（また、非標準のペリフェラルは、adv-でiBeaconフォーマットでアドバタイズできます。パケットおよびスキャン応答パケットの異なる形式）。
一般的な制限
- iBeacon Rangingは、あなたの周りにあるビーコンを知らせます。ビーコンがアドバタイズするProximityUUIDを事前に指定する必要があります（「一般的な」スキャンは不可）。
didRangeBeaconsは、最近見つかったCLBeaconオブジェクトの配列を使用して毎秒呼び出されます。ビーコンからの距離とその精度は、Appleの開発者だけが実際に知っている機密アルゴリズムを使用してiOSによって計算されます（アルゴリズムは、ビーコンがアドバタイズするrssi値とrssi-at-1メートルのキャリブレーションバイトに基づいています）。 iBeacon Monitoringを使用して、リージョンに出入りするたびにデリゲートを呼び出すこともできます。ここでも、探しているProximityUUIDを指定する必要があります（メジャーとマイナーを指定することもできます）。 「リージョンの終了」は、広告を受信しない時間によって定義されるため、すぐに実行することはできません。デバイスごとに同時にレンジング/モニタリングできるリージョンの数は20に制限されています-これは、他のアプリが同時にモニタリング\レンジングを行う場合を意味します、アプリが監視\範囲を設定できない場合があります（右？）。 - CoreBluetooth-ビーコンの広告で他の広告構造を検出することもできます。ビーコンがiBeacon形式でもアドバタイズする場合、iBeaconフィールド（ProximityUUID、メジャー、マイナー...）は、他の場合に表示される標準の「メーカー固有」の広告構造で送信されるにもかかわらず、表示されません。 。
フォアグラウンドでの実行-制限の少ないユースケース：
- iBeaconのレンジングとモニタリング-これ以上の制限はありません。
- CoreBluetooth-
nilのserviceUUIDsにscanForPeripheralsWithServicesを渡すと、すべての周辺機器がスキャンされます。オプションでCBCentralManagerScanOptionAllowDuplicatesKeyをYESとして渡すと、同じ周辺機器\ビーコンに対してdidDiscoverPeripheralが複数回呼び出されます（タイマーを使用すると、広告が検出されなかったと思います）しばらくの間受信し、ユーザーが「リージョン」を終了したと想定します）。
バックグラウンドでの実行-より制限されたユースケース：
- iBeaconRangingは直接機能しません。 iBeaconMonitoringは
didEnterRegionを呼び出し、アプリの実行時間を6秒にします。これにより、レンジングを開始できます（たとえば、メジャーとマイナーを検出するため）。 iOSはバッテリーの電力を維持するためにスキャンのオンとオフを切り替えるため、検出がすぐに行われない場合があります。同じProximityUUIDで複数のビーコンの領域に入り、特定のメジャーおよび/またはマイナーなしでこのUUIDを監視する場合、最初のビーコンからの信号の受信を開始すると、didEnterRegionが呼び出されます。最初のビーコンの領域を終了せず、2番目のビーコンの領域にも入力したため、アプリは再度起動されないため（didEnterRegionは再度呼び出されません）、2番目のビーコンを検出するためのレンジングを開始できません。ビーコンのメジャーとマイナー。アプリは単にフォアグラウンドにポップアップすることはできませんが、ローカル通知やその他のバックグラウンド操作を作成できます。 - CoreBluetooth Core Bluetoothバックグラウンド処理
scanForPeripheralsWithServicesによると、を使用してバックグラウンドで実行できますが、少なくとも1つのserviceUUIDを指定する必要があります。didDiscoverPeripheralには10秒の実行時間が与えられます。CBCentralManagerScanOptionAllowDuplicatesKeyの使用は機能しません-didDiscoverPeripheralはすべての周辺機器に対して1回呼び出されます。したがって、リージョンからの「終了」と「再入」を検出することはできません。この問題を解決するために、MACアドレスを変更する非標準のBLEペリフェラルを使用できると思います。アプリは単にフォアグラウンドにポップアップすることはできませんが、ローカル通知やその他のバックグラウンド操作を作成できます。 iOSはバッテリーの電力を維持するためにスキャンのオンとオフを切り替えるため、検出がすぐに行われない場合があります。
アプリが強制終了された後に実行
- iBeaconモニタリング-動作します！ユーザーがアプリを強制終了したり、デバイスが再起動された場合でも。
- CoreBluetooth-アプリがiOSによって強制終了された場合（非アクティブまたはメモリの制約のため）、アプリはウェイクアップされます。ただし、ユーザーがアプリを明示的に強制終了した場合、アプリは起動されません（これにより、最初のケースのテストが困難になります）。デバイスの再起動後に何が起こるかわかりません...
誰かがこれらの制限についてもっと経験がありますか？いくつかのユースケースでは、scanForPeripheralsWithServicesをiBeaconモニタリングのより良い代替手段として使用できますか？
ありがとう！
あなたはほとんどあなたの説明に正しいです。たった2つの説明：
20リージョンの制限は、デバイスごとにnotであり、アプリ固有です。モバイルデバイスで他のアプリが何をしているかに関係なく、アプリはiOSによって最大20のリージョンを監視できます。とはいえ、ハードウェアの支援を受けてバックグラウンドで監視できるリージョンの数には、デバイス固有のハードウェア制限がある可能性があります。これらの制限は文書化されていません。これらの文書化されていない制限を超えると、バックグラウンドでビーコンが検出されるまでにかなり時間がかかる可能性があります。 （とはいえ、とにかく、いつ検出が行われるかについてのOSの保証はありません。）
Monitoring and RangingAPIを使用して
CLBeaconに接続することはできません。これらのAPIは、コネクションレス型のBLEアドバタイズパケットでのみ機能します。
はい、代わりにscanForPeripheralsWithServicesを使用することは可能です。これは、独自のシステムを実装するためにジンバルビーコンが行うことです。ただし、バックグラウンド検出時間と信頼性の点で実際の欠点があります。