Android蓝牙后台处理：最优实现方案探讨

Hey there, let's tackle your BLE background persistence problem head-on. Given your app's minSdkVersion 23 and targetSdkVersion 29, here's a breakdown of each option you mentioned, plus the optimal solution tailored to your needs:

Let's start by evaluating each tool against your requirements (persistent BLE connection, periodic data fetch, background BLE advertising, and auto-reconnect after app kill):

• AlarmManager: Great for precise one-off timing, but it’s heavily restricted by Doze Mode on Android 6+. It only triggers a short-lived task, can’t maintain a persistent BLE connection or background advertising, and won’t keep your process alive long-term. Not a fit here.
• JobScheduler: Android’s built-in batch scheduler saves battery by grouping tasks, but it’s designed for deferred, non-urgent work. It can’t guarantee consistent 30-minute intervals (system may delay tasks to save power) and can’t sustain a continuous BLE connection or broadcast. Nope.
• WorkManager: Jetpack’s cross-version solution for background tasks, but it’s meant for tasks that don’t require persistent process ownership. It runs tasks in isolated threads, and once the task finishes, your process can still get killed. It can’t maintain BLE advertising or a steady connection. Not ideal.
• ForegroundService: This is your best bet! Here’s why:
  • Android 8+ (API 26) prioritizes foreground services by requiring a persistent notification, so the system won’t kill your process unless it’s absolutely starved for memory.
  • It lets you maintain a continuous BLE connection, run background advertising, and execute periodic tasks all in one persistent process.
  • You can configure it to restart automatically after being killed (with START_STICKY) and use saved device data to reconnect automatically.

Let’s walk through how to adapt your current setup to use a Foreground Service:

1. Convert BleService to a Foreground Service #

Update your BleService to launch itself as a foreground service on startup, and handle auto-reconnect using saved MAC addresses:

public class BleService extends Service {
    private static final String BLE_PREFS = "BLE_PREFS";
    private static final String KEY_SAVED_MAC = "CONNECTED_DEVICE_MAC";
    private ScheduledExecutorService scheduleTaskExecutor;
    private BluetoothLeAdvertiser mAdvertiser;
    // ... your existing BLE variables (mBleService, connectedDevice, etc.)

    @Override
    public void onCreate() {
        super.onCreate();
        // Start BLE advertising for your phone to be discoverable
        startBleAdvertising();
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        // Create a foreground notification (required for API 26+)
        createForegroundNotification();

        // Auto-reconnect to saved device if available
        SharedPreferences prefs = getSharedPreferences(BLE_PREFS, MODE_PRIVATE);
        String savedMac = prefs.getString(KEY_SAVED_MAC, null);
        if (savedMac != null) {
            connectToDevice(savedMac);
        }

        // Return START_STICKY to tell system to restart service if killed
        return START_STICKY;
    }

    private void createForegroundNotification() {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            NotificationChannel channel = new NotificationChannel(
                "BLE_SERVICE_CHANNEL",
                "BLE Connection Service",
                NotificationManager.IMPORTANCE_LOW
            );
            NotificationManager manager = getSystemService(NotificationManager.class);
            manager.createNotificationChannel(channel);
        }

        Notification notification = new NotificationCompat.Builder(this, "BLE_SERVICE_CHANNEL")
            .setContentTitle("BLE Device Connected")
            .setContentText("Fetching data every 30 minutes")
            .setSmallIcon(R.drawable.ic_bluetooth)
            .setPriority(NotificationCompat.PRIORITY_LOW)
            .build();

        // Launch as foreground service
        startForeground(1, notification);
    }

    // ... your existing connectToDevice() method
}

2. Move BLE Logic & Periodic Tasks to the Service #

Get rid of the BroadcastReceiver and scheduled tasks in StatusActivity—handle all BLE operations directly in the service:

// Inside BleService, after successful device connection
private void startPeriodicDataFetch() {
    scheduleTaskExecutor = Executors.newSingleThreadScheduledExecutor();
    scheduleTaskExecutor.scheduleAtFixedRate(() -> {
        if (mBleService != null && connectedDevice != null) {
            connectedDevice.requestTemperature(mBleService, connectedDevice);
        }
    }, 0, 30, TimeUnit.MINUTES);
}

// Clean up resources when service is destroyed
@Override
public void onDestroy() {
    super.onDestroy();
    if (scheduleTaskExecutor != null) {
        scheduleTaskExecutor.shutdown();
    }
    if (mAdvertiser != null) {
        mAdvertiser.stopAdvertising(new AdvertiseCallback() {});
    }
    if (mBleService != null) {
        mBleService.disconnect();
    }
    stopForeground(true);
}

3. Handle BLE Advertising (Phone as LE Device) #

Add code to start persistent BLE advertising in the service (so your phone stays discoverable):

private void startBleAdvertising() {
    BluetoothManager bluetoothManager = (BluetoothManager) getSystemService(Context.BLUETOOTH_SERVICE);
    BluetoothAdapter bluetoothAdapter = bluetoothManager.getAdapter();
    
    if (bluetoothAdapter != null && bluetoothAdapter.isMultipleAdvertisementSupported()) {
        mAdvertiser = bluetoothAdapter.getBluetoothLeAdvertiser();
        
        AdvertiseSettings settings = new AdvertiseSettings.Builder()
            .setAdvertiseMode(AdvertiseSettings.ADVERTISE_MODE_LOW_POWER)
            .setConnectable(true)
            .setTimeout(0) // Run indefinitely
            .setTxPowerLevel(AdvertiseSettings.ADVERTISE_TX_POWER_LOW)
            .build();

        AdvertiseData data = new AdvertiseData.Builder()
            .setIncludeDeviceName(true)
            // Add your custom service UUID if needed
            // .addServiceUuid(new ParcelUuid(YOUR_SERVICE_UUID))
            .build();

        mAdvertiser.startAdvertising(settings, data, new AdvertiseCallback() {
            @Override
            public void onStartSuccess(AdvertiseSettings settingsInEffect) {
                super.onStartSuccess(settingsInEffect);
                // Advertising started successfully
            }

            @Override
            public void onStartFailure(int errorCode) {
                super.onStartFailure(errorCode);
                // Handle advertising failure (e.g., Bluetooth off)
            }
        });
    }
}

4. Sync with StatusActivity #

When StatusActivity is in the foreground, bind to the service to update the UI:

// Inside StatusActivity
private BleService mBleService;
private ServiceConnection mConnection = new ServiceConnection() {
    @Override
    public void onServiceConnected(ComponentName className, IBinder service) {
        BleService.LocalBinder binder = (BleService.LocalBinder) service;
        mBleService = binder.getService();
        // Use mBleService to get current connection status/data and update UI
    }

    @Override
    public void onServiceDisconnected(ComponentName arg0) {
        mBleService = null;
    }
};

@Override
protected void onStart() {
    super.onStart();
    // Bind to BleService
    Intent intent = new Intent(this, BleService.class);
    bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
}

@Override
protected void onStop() {
    super.onStop();
    unbindService(mConnection);
}

Add a LocalBinder to BleService to expose its instance to the activity:

public class LocalBinder extends Binder {
    BleService getService() {
        return BleService.this;
    }
}

@Nullable
@Override
public IBinder onBind(Intent intent) {
    return new LocalBinder();
}

• Foreground Service Priority: Android treats foreground services as high-priority processes. They’re exempt from Doze Mode and App Standby restrictions, so your BLE operations and periodic tasks will keep running even when the app is in the background.
• START_STICKY: When you return this from onStartCommand, the system will restart your service if it’s killed due to low memory. Note that the restart intent will be null, so you must rely on saved data (like the device MAC) to resume operations.
• Manual App Kill: If the user manually kills your app, the system won’t restart the service automatically. To handle this, you can add a BroadcastReceiver that listens for BOOT_COMPLETED (to restart on device boot) and PACKAGE_RESTARTED (if supported), but be aware that some OEMs may block these broadcasts.

• Save Device MAC: Use SharedPreferences or Room to store the connected device’s MAC address. The service reads this on startup to auto-reconnect.
• Store Collected Data: Use Room Database to persist temperature readings—this ensures data isn’t lost if the process is killed.
• UI Updates: Use LiveData in the service to publish data updates. The activity can observe this LiveData to update the UI automatically when it’s in the foreground.

内容的提问来源于stack exchange，提问作者Jorge Morata Toribio