Core Bluetooth: Architektur und BLE-Entwicklung auf iOS

Was ist Core Bluetooth: Architektur und Komponenten

Core Bluetooth unterteilt den BLE-Stack in zwei logische Rollen, die von der Bluetooth-SIG-Spezifikation definiert werden. Die Rolle des zentralen Geräts (Central) wird durch die Klasse CBCentralManager repräsentiert — sie initiiert das Scannen, stellt Verbindungen her und verwaltet die Liste der verbundenen CBPeripherals. Die Rolle des peripheren Geräts (Peripheral) wird durch CBPeripheralManager repräsentiert — sie veröffentlicht Dienste und Merkmale, beantwortet zentrale Anfragen und sendet Benachrichtigungen. Eine einzelne iOS-Sitzung kann gleichzeitig in beiden Rollen auf verschiedenen BLE-Funkgeräten arbeiten, aber eine typische Anwendung verwendet eine Rolle.

Die Core Bluetooth-Architektur umfasst fünf wichtige Abstraktionen. CBCentralManager verwaltet den Zustand des Bluetooth-Adapters des Geräts: poweredOn (betriebsbereit), poweredOff (Bluetooth deaktiviert), unauthorized (keine Berechtigung), unsupported (BLE nicht verfügbar). CBPeripheral repräsentiert ein entferntes BLE-Gerät mit seiner UUID, Namen, RSSI und GATT-Hierarchie. CBService — eine logische Gruppe von Merkmalen. CBCharacteristic — ein Datenpunkt zum Lesen/Schreiben/Benachrichtigen. CBPeripheralManager erstellt einen lokalen GATT-Server zur Emulation eines Peripheriegeräts.

CBCentralManager-Zustände steuern alle BLE-Operationen. Beim App-Start wird centralManagerDidUpdateState mit dem aktuellen Bluetooth-Zustand aufgerufen. Wenn der Zustand nicht .poweredOn ist, werden BLE-Aufrufe vom System ignoriert. Der Entwickler muss den Zustand vor jedem Scan und jeder Verbindung überprüfen. Der Übergang von .poweredOff zu .poweredOn erfolgt, wenn Bluetooth in den iOS-Einstellungen aktiviert wird — der Delegierte erhält einen erneuten Aufruf, und die App kann das Scannen fortsetzen.

CBCentralManager: Scannen und Verbinden von BLE-Geräten

CBCentralManager ist der Einstiegspunkt für alle BLE-Operationen auf der Seite des zentralen Geräts. Die Initialisierung nimmt einen Delegierten (CBCentralManagerDelegate) und eine DispatchQueue entgegen — Apple empfiehlt die Hauptwarteschlange für Einfachheit oder eine serielle Warteschlange für Leistung. Nach der Initialisierung überprüft das Framework automatisch den Bluetooth-Zustand und ruft centralManagerDidUpdateState: auf — der erste zu behandelnde obligatorische Delegierte.

Das Scannen beginnt mit der Methode scanForPeripheralsWithServices:options:. Der erste Parameter ist ein Array von CBUUID-Diensten zum Filtern: Wenn die UUIDs der gewünschten Dienste bekannt sind, reduziert deren Übergabe den Stromverbrauch und die Suchzeit. Bei nil werden alle BLE-Geräte in Reichweite erkannt. Zu den Optionen gehören .allowDuplicatesKey (wiederholte Erkennung desselben Geräts) und .solicitedServiceUUIDsKey (für auf dem Zentralrechner veröffentlichte Dienste).

import CoreBluetooth

class BLECentral: NSObject {

    private var centralManager: CBCentralManager!
    private var discoveredPeripherals: [CBPeripheral] = []

    override init() {
        super.init()
        centralManager = CBCentralManager(delegate: self, queue: .main)
    }

    // BLE-Scanning starten
    func startScan() {
        guard centralManager.state == .poweredOn else {
            print("Bluetooth nicht verfügbar")
            return
        }
        // Alle Geräte scannen (nil = kein Filter)
        centralManager.scanForPeripherals(withServices: nil,
                                            options: [CBCentralManagerScanOptionAllowDuplicatesKey: true])
    }

    // Scannen beenden
    func stopScan() {
        centralManager.stopScan()
    }

    // Mit ausgewähltem Gerät verbinden
    func connect(to peripheral: CBPeripheral) {
        centralManager.connect(peripheral, options: nil)
    }
}

// MARK: - CBCentralManagerDelegate
extension BLECentral: CBCentralManagerDelegate {

    func centralManagerDidUpdateState(_ central: CBCentralManager) {
        if central.state == .poweredOn {
            startScan()
        }
    }

    func centralManager(_ central: CBCentralManager,
                        didDiscover peripheral: CBPeripheral,
                        advertisementData: [String : Any],
                        rssi: NSNumber) {
        if !discoveredPeripherals.contains(where: { $0.identifier == peripheral.identifier }) {
            discoveredPeripherals.append(peripheral)
            print("Found devices: \(peripheral.name ?? "Unknown"), RSSI: \(rssi)")
        }
    }

    func centralManager(_ central: CBCentralManager,
                        didConnect peripheral: CBPeripheral) {
        print("Connected: \(peripheral.identifier)")
        peripheral.delegate = self
        peripheral.discoverServices(nil)
    }

    func centralManager(_ central: CBCentralManager,
                        didDisconnectPeripheral peripheral: CBPeripheral,
                        error: Error?) {
        print("Disconnected: \(peripheral.identifier)")
    }
}

Die Klasse BLECentral demonstriert den vollständigen Zyklus des Scannens und Verbindens von BLE-Geräten. centralManagerDidUpdateState startet das Scannen, wenn Bluetooth aktiviert ist. didDiscoverPeripheral sammelt gefundene Geräte im Array discoveredPeripherals mit Deduplizierung nach identifier. Nach der Verbindung (didConnect) beginnt sofort die Diensterkennung — dies ist ein obligatorischer Schritt vor allen GATT-Operationen.

CBPeripheralManager: Erstellen eines BLE-Servers auf iOS

CBPeripheralManager ist die Klasse zur Emulation eines BLE-Peripheriegeräts auf iOS. Eine App in der Peripherierolle kann ihre Dienste und Merkmale veröffentlichen, eingehende Lese-/Schreibanfragen von einem zentralen Gerät annehmen und Benachrichtigungen senden. CBPeripheralManager wird für BLE-Zubehör verwendet, das vom iPhone emuliert wird: Fernbedienungen, Tastaturen, Tracker, IoT-Gateways.

Der Lebenszyklus von CBPeripheralManager beginnt mit der Initialisierung und dem Delegierten CBPeripheralManagerDelegate. Nach Erhalt der poweredOn-Bestätigung über peripheralManagerDidUpdateState: werden Dienste veröffentlicht (addService:) und das Advertising gestartet (startAdvertising:). Die Advertising-Daten CBAdvertisementData umfassen den lokalen Namen (CBAdvertisementDataLocalNameKey), Dienst-UUIDs (CBAdvertisementDataServiceUUIDsKey) und die Sendeleistung (CBAdvertisementDataTxPowerLevelKey). Die maximale Advertising-Paketgröße beträgt 31 Byte für BLE 4.0 und 251 Byte für extended advertising BLE 5.0+.

// BLE-Peripherie auf iOS über CBPeripheralManager
class BLEPeripheral: NSObject {

    private var peripheralManager: CBPeripheralManager!

    let serviceUUID = CBUUID(string: "1234")
    let characteristicUUID = CBUUID(string: "5678")

    override init() {
        super.init()
        peripheralManager = CBPeripheralManager(delegate: self, queue: .main)
    }

    // Dienst mit Merkmal veröffentlichen
    func setupService() {
        let characteristic = CBMutableCharacteristic(
            type: characteristicUUID,
            properties: [.read, .write, .notify],
            value: nil,
            permissions: [.readable, .writeable]
        )
        let service = CBMutableService(type: serviceUUID, primary: true)
        service.characteristics = [characteristic]
        peripheralManager.add(service)
    }

    // Advertising starten
    func startAdvertising() {
        let advertisementData: [String: Any] = [
            CBAdvertisementDataLocalNameKey: "My BLE Device",
            CBAdvertisementDataServiceUUIDsKey: [serviceUUID]
        ]
        peripheralManager.startAdvertising(advertisementData)
    }
}

// MARK: - CBPeripheralManagerDelegate
extension BLEPeripheral: CBPeripheralManagerDelegate {

    func peripheralManagerDidUpdateState(_ peripheral: CBPeripheralManager) {
        if peripheral.state == .poweredOn {
            setupService()
        }
    }

    func peripheralManager(_ peripheral: CBPeripheralManager,
                        didAdd service: CBService,
                        error: Error?) {
        if error == nil {
            startAdvertising()
        }
    }

    // Leseanfrage bearbeiten
    func peripheralManager(_ peripheral: CBPeripheralManager,
                        didReceiveRead request: CBATTRequest) {
        let data = "CurrentValue".data(using: .utf8)!
        request.value = data
        peripheralManager.respond(to: request, withResult: .success)
    }

    // Schreibanfrage bearbeiten
    func peripheralManager(_ peripheral: CBPeripheralManager,
                        didReceiveWrite requests: [CBATTRequest]) {
        for request in requests {
            if let value = request.value {
                print("Write: \(value)")
            }
        }
        peripheralManager.respond(to: requests.first!, withResult: .success)
    }
}

Die Klasse BLEPeripheral erstellt einen BLE-Server mit einem einzelnen Merkmal, das Lesen, Schreiben und Benachrichtigungen unterstützt. Nach der Initialisierung veröffentlicht peripheralManagerDidUpdateState den Dienst über addService: und startet dann das Advertising über startAdvertising:. Die Handler didReceiveRead und didReceiveWrite antworten auf eingehende GATT-Anfragen vom zentralen Gerät. Zum Senden von Benachrichtigungen wird die Methode updateValue:forCharacteristic:onSubscribedCentrals: verwendet.

GATT-Operationen: Lesen, Schreiben und Benachrichtigungen

GATT-Operationen (Generic Attribute Profile) sind die Grundlage des Datenaustauschs in Core Bluetooth. Nach der Erkennung von Diensten und Merkmalen kann das zentrale Gerät drei Arten von Operationen ausführen: Lesen eines Merkmalswerts, Schreiben eines Werts und Abonnieren von Benachrichtigungen/Indikationen. Jede Operation ist asynchron und gibt das Ergebnis über den entsprechenden CBPeripheralDelegate-Callback zurück.

Lesen: erfolgt durch Aufruf von readValueForCharacteristic:. Der Wert kommt in peripheral:didUpdateValueForCharacteristic:error: an. Wichtig: Das Lesen gibt den aktuellen Wert vom Gerät zurück, keinen zwischengespeicherten. Wenn das Gerät das Lesen nicht unterstützt (Eigenschaft .read), gibt der Aufruf einen Fehler zurück. Bei großen Werten (größer als MTU) fragmentiert und setzt BLE die Daten automatisch auf GATT-Ebene wieder zusammen.

Schreiben: erfolgt durch Aufruf von writeValue:forCharacteristic:type:. BLE unterstützt zwei Schreibmodelle: withResponse (zuverlässig, mit Bestätigung) und withoutResponse (schnell, ohne Bestätigung). Die Eigenschaft CBCharacteristic.properties definiert die verfügbaren Schreibtypen. Die maximale Größe eines einzelnen Schreibpakets ist durch MTU begrenzt: 23 Byte für BLE 4.0 (20 Byte Nutzlast + 3 Byte Header), bis zu 247 Byte für BLE 5.0 mit erweitertem MTU (MTU 251).

Benachrichtigungen: werden durch Aufruf von setNotifyValue:true forCharacteristic: aktiviert. Nach dem Abonnement sendet das Peripheriegerät automatisch Aktualisierungen über peripheral:didUpdateValueForCharacteristic: immer dann, wenn sich der Merkmalswert ändert. Zum Deaktivieren von Benachrichtigungen wird setNotifyValue:false forCharacteristic: aufgerufen. Core Bluetooth verwaltet automatisch den CCCD-Deskriptor auf dem Peripheriegerät.

Core Bluetooth Hintergrundmodus und State Restoration

Der Hintergrundmodus in Core Bluetooth ermöglicht BLE-Apps, im Hintergrund weiter zu scannen, Verbindungen aufrechtzuerhalten und Benachrichtigungen zu empfangen. Zur Aktivierung muss die Fähigkeit „Uses Bluetooth LE accessories“ in Xcode aktiviert werden (Info.plist → Required background modes → App communicates using Core Bluetooth) und der Schlüssel „bluetooth-central“ zu UIBackgroundModes hinzugefügt werden. Für die Peripherierolle — „bluetooth-peripheral“.

State Restoration ist ein Mechanismus von Core Bluetooth zur Wiederherstellung des Zustands von BLE-Verbindungen nach einem Neustart der App durch iOS. Wenn der Hintergrundmodus aktiv ist und bei der Initialisierung von CBCentralManager oder CBPeripheralManager ein restoreIdentifier angegeben wird, speichert iOS den Zustand des BLE-Stacks beim Beenden der App und stellt ihn beim nächsten Start wieder her. Der Delegierte centralManager:willRestoreState: erhält ein Wörterbuch mit gespeicherten CBPeripherals und ausstehenden Verbindungen.

// Core Bluetooth-Konfiguration mit State Restoration
class BLECentralWithRestoration: NSObject {

    let restoreIdentifier = "com.app.blecentral"
    private var centralManager: CBCentralManager!

    override init() {
        super.init()
        let options: [String: Any] = [
            CBCentralManagerOptionRestoreIdentifierKey: restoreIdentifier,
            CBCentralManagerOptionShowPowerAlertKey: true
        ]
        centralManager = CBCentralManager(delegate: self,
                                          queue: nil,
                                          options: options)
    }
}

extension BLECentralWithRestoration: CBCentralManagerDelegate {

    // Zustand nach Neustart wiederherstellen
    func centralManager(_ central: CBCentralManager,
                        willRestoreState dict: [String : Any]) {
        if let peripherals = dict[CBCentralManagerRestoredStatePeripheralsKey]
            as? [CBPeripheral] {
            for peripheral in peripherals {
                peripheral.delegate = self
                // GATT-Erkennung wiederherstellen
                peripheral.discoverServices(nil)
            }
        }
    }

    func centralManagerDidUpdateState(_ central: CBCentralManager) {
        if central.state == .poweredOn {
            print("Bluetooth nach Wiederherstellung bereit")
        }
    }
}

In der Konfiguration BLECentralWithRestoration aktiviert der Schlüssel CBCentralManagerOptionRestoreIdentifierKey die Zustandsspeicherung. Wenn die App von iOS beendet wurde (z. B. wegen Speichermangels), erhält centralManager:willRestoreState: beim nächsten Start eine Liste zuvor verbundener CBPeripherals. Die App stellt die Delegierten wieder her und führt eine erneute Diensterkennung durch — der Benutzer bemerkt die Verbindungsunterbrechung nicht. Ohne State Restoration gehen alle BLE-Sitzungen verloren, wenn die App beendet wird.

BLE-App-Beispiel in Swift: Zentrale und Peripherie

Ein vollständiges Beispiel einer BLE-App in Swift vereint sowohl zentrale als auch periphere Geräte in einem Projekt. Die App kann in zwei Modi arbeiten: BLE-Geräte erkennen und verbinden (Zentrale) oder ein BLE-Zubehör emulieren (Peripherie). Nachfolgend wird eine Architektur mit einem gemeinsamen BLE-Manager gezeigt, der die Rolle beim Start auswählt.

// Universeller BLE-Manager für Zentrale und Peripherie
class BLEManager {

    enum Role {
        case central
        case peripheral
    }

    private let role: Role
    private var centralManager: CBCentralManager?
    private var peripheralManager: CBPeripheralManager?
    let advertisedServiceUUID = CBUUID(string: "A001")

    init(role: Role) {
        self.role = role
        switch role {
        case .central:
            centralManager = CBCentralManager(delegate: nil, queue: .main)
        case .peripheral:
            peripheralManager = CBPeripheralManager(delegate: nil, queue: .main)
        }
    }

    // Zentrales Gerät: Scannen
    func scanForDevices() {
        centralManager?.scanForPeripherals(withServices: nil, options: nil)
    }

    // Peripheres Gerät: Advertising
    func advertiseService() {
        let data: [String: Any] = [
            CBAdvertisementDataServiceUUIDsKey: [advertisedServiceUUID]
        ]
        peripheralManager?.startAdvertising(data)
    }
}

// Verwendung beim Start
let isCentral = UserDefaults.standard.bool(forKey: "isCentral")
let manager = BLEManager(role: isCentral ? .central : .peripheral)

if isCentral {
    manager.scanForDevices()
} else {
    manager.advertiseService()
}

Der BLEManager wählt die Rolle bei der Initialisierung und erstellt den entsprechenden Manager (CBCentralManager oder CBPeripheralManager). Das Rollen-Flag kann in UserDefaults gespeichert oder über einen Konfigurationsserver übergeben werden. Dieser Ansatz ermöglicht es der BLE-App, sich an den Anwendungsfall anzupassen: an der Verkaufsstelle arbeitet ein iPhone als Zentrale zum Scannen von Zahlungsterminals; auf einem IoT-Gateway — als Peripherie zum Sammeln von Sensordaten.