企业官网建设流程全解析

1. 蓝牙后台保活到底难在哪

做过 Android 蓝牙外设对接的人，大概率都经历过这种场景：App 切到后台，或者手机屏幕一黑，蓝牙扫描就停了，设备连不上、数据断了、用户投诉接踵而至。尤其是 Android 8.0 之后，系统对后台行为和后台服务的限制越来越严，以前那套“随便起个 Service 就能一直扫”的做法彻底失效。这个项目标题里的“蓝牙后台保活”“Ble锁屏唤醒”“持续扫描”，说的就是怎么在 Android 8.0 及以上版本里，让蓝牙低功耗扫描在锁屏、后台、长时间待机的情况下依然能稳定工作。

先把结论摆出来：Android 8.0+ 想做到蓝牙后台持续扫描，靠单一手段是不行的，必须组合拳。核心思路是前台服务 + 低功耗扫描策略 + PendingIntent 唤醒 + 广播/JobScheduler 兜底。这套方案解决的是“App 不在前台时，蓝牙扫描被系统掐断”的问题，适合做智能穿戴、蓝牙防丢器、健康监测设备、车载蓝牙、工业蓝牙采集这类需要长时间保持蓝牙连接或扫描的应用开发者。不管你是刚接触 BLE 的新手，还是被后台限制折磨过的老手，下面这些内容都能直接拿去用。

我先把整个技术方案的骨架讲清楚，再逐层拆解每个环节的实现细节和踩坑点。文章会涉及大量代码和配置，但我会尽量用大白话解释每一步为什么这么做，让你不仅会抄，还能理解背后的逻辑。

2. 整体方案设计与核心思路拆解

2.1 为什么 Android 8.0 是分水岭

Android 8.0（API 26）引入了后台执行限制，这是整个问题的根源。具体来说，当 App 进入后台后，系统会限制以下几件事：后台服务会被停止（除非是前台服务）、隐式广播大部分被禁止、后台位置更新频率被限制、蓝牙扫描也被纳入管控。Android 10 之后又加了后台启动 Activity 的限制，Android 12 进一步收紧了前台服务的启动时机。所以如果你还在用 Android 7.0 时代的写法，在 8.0+ 上基本活不过几分钟。

这里有个关键点很多人搞混：蓝牙扫描本身在后台是可以做的，但前提是你得让系统认为你的 App 有“正当理由”在后台运行。这个“正当理由”的载体就是前台服务。前台服务会在通知栏显示一个常驻通知，告诉用户“这个 App 正在后台干活”，系统就不会轻易杀掉它。

2.2 方案选型的三个层次

我把整个保活方案分成三个层次，从强到弱依次是：

实际项目中，这三层要配合使用。前台服务负责“主战场”，PendingIntent 负责“锁屏唤醒”，JobScheduler 负责“兜底重连”。单独用任何一个都不够稳。

2.3 为什么不用双进程守护那套

网上有很多“双进程守护”“Native 进程保活”的方案，我实测下来在 Android 8.0+ 上基本没用，而且容易被系统判定为恶意行为，导致 App 被限制甚至下架。蓝牙场景和即时通讯不一样，我们不需要“永远不死”，只需要“在需要扫描的时候能扫到”。所以正确的思路不是对抗系统，而是顺着系统的规则走，用前台服务把合法性做足，用 PendingIntent 把唤醒链路打通。

提示：不要尝试用反射、隐藏 API 或者 Native 守护进程来绕过后台限制，这些手段在新版本上要么失效，要么会触发应用商店的合规审查。

3. 核心细节解析与实操要点

3.1 前台服务的正确声明方式

前台服务是整套方案的基石。从 Android 8.0 开始，启动前台服务必须调用startForegroundService()，然后在 5 秒内调用startForeground()显示通知，否则会抛 ANR 或崩溃。Android 10 之后还需要在 AndroidManifest 里声明foregroundServiceType，蓝牙场景一般用connectedDevice或location。

<service android:name=".BleScanService" android:enabled="true" android:exported="false" android:foregroundServiceType="connectedDevice|location" />

权限方面，Android 12 之前需要ACCESS_FINE_LOCATION才能扫描 BLE 设备，Android 12 之后新增了BLUETOOTH_SCAN、BLUETOOTH_CONNECT、BLUETOOTH_ADVERTISE三个运行时权限。这里有个坑：BLUETOOTH_SCAN如果声明了neverForLocation属性，系统会认为你不是用来推断位置的，可以不用申请定位权限，但部分厂商 ROM 仍然会要求定位权限才能扫到设备。我的建议是定位权限和蓝牙权限都申请，兼容性最好。

<uses-permission android:name="android.permission.BLUETOOTH_SCAN" android:usesPermissionFlags="neverForLocation" /> <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> <uses-permission android:name="android.permission.FOREGROUND_SERVICE_CONNECTED_DEVICE" />

3.2 扫描参数怎么设才省电又稳定

BLE 扫描有三个关键参数：SCAN_MODE、SCAN_MODE_LOW_POWER的窗口和间隔、以及是否开启setReportDelay。很多人为了“扫得快”直接用SCAN_MODE_LOW_LATENCY，结果电量哗哗掉，系统也会因为功耗过高而限制你。

我的经验是分场景设置：

• 前台交互时：用SCAN_MODE_LOW_LATENCY，扫描窗口和间隔都设短，快速发现设备。
• 后台持续扫描时：用SCAN_MODE_LOW_POWER，窗口设 512ms，间隔设 5120ms，这样占空比约 10%，功耗可控。
• 锁屏待机时：进一步降低频率，或者改用PendingIntent方式让系统在发现设备时才唤醒 App。

ScanSettings settings = new ScanSettings.Builder() .setScanMode(ScanSettings.SCAN_MODE_LOW_POWER) .setReportDelay(0) .setMatchMode(ScanSettings.MATCH_MODE_AGGRESSIVE) .build();

setMatchMode和setNumOfMatches这两个参数很多人忽略，它们配合ScanFilter使用，可以只上报匹配的设备，减少无效回调。如果你的设备有固定的 Service UUID，一定要用ScanFilter过滤，这样系统在底层就能筛掉大部分广播包，省电效果非常明显。

3.3 PendingIntent 扫描：锁屏唤醒的关键

这是整个方案里最核心的一环。普通的startScan()在锁屏后，如果 App 被系统冻结，扫描回调就不会执行。而startScan()有一个重载版本，可以传入一个PendingIntent，当系统发现匹配的设备时，会发送这个 PendingIntent，从而唤醒你的 App。

Intent intent = new Intent(context, BleScanReceiver.class); intent.setAction("com.example.BLE_SCAN_RESULT"); PendingIntent pendingIntent = PendingIntent.getBroadcast( context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_MUTABLE ); bluetoothLeScanner.startScan(filters, settings, pendingIntent);

这里有几个关键细节：

第一，PendingIntent的 flag 在 Android 12 之后必须显式指定FLAG_MUTABLE或FLAG_IMMUTABLE。蓝牙扫描场景下，系统需要往 Intent 里填充扫描结果，所以必须用FLAG_MUTABLE，否则收不到数据。

第二，接收 PendingIntent 的BroadcastReceiver必须在 Manifest 里静态注册，不能动态注册，因为 App 可能已经被冻结，动态注册的 Receiver 收不到。

<receiver android:name=".BleScanReceiver" android:exported="true"> <intent-filter> <action android:name="com.example.BLE_SCAN_RESULT" /> </intent-filter> </receiver>

第三，BleScanReceiver的onReceive里要做的事情要尽量轻量，因为广播接收器的执行时间有限（约 10 秒）。一般做法是：收到广播后，启动前台服务或者发一个本地通知，让用户点击后回到 App 处理数据。如果数据量小，也可以直接在onReceive里解析并存储。

注意：部分厂商 ROM（尤其是国内定制系统）对 PendingIntent 唤醒有额外限制，需要在设置里手动允许“自启动”和“后台弹出界面”。这个没法完全靠代码解决，只能在引导页里提示用户。

3.4 扫描结果的解析与去重

PendingIntent方式收到的扫描结果，是通过 Intent 的 extra 传过来的，key 是BluetoothLeScanner.EXTRA_LIST_SCAN_RESULT，值是一个ArrayList<ScanResult>。解析时要注意类型转换和空判断。

@Override public void onReceive(Context context, Intent intent) { if (intent == null) return; String action = intent.getAction(); if (!"com.example.BLE_SCAN_RESULT".equals(action)) return; ArrayList<ScanResult> results = intent.getParcelableArrayListExtra( BluetoothLeScanner.EXTRA_LIST_SCAN_RESULT); if (results == null || results.isEmpty()) return; for (ScanResult result : results) { String mac = result.getDevice().getAddress(); int rssi = result.getRssi(); // 去重、存储、判断是否需要唤醒界面 } }

去重是个容易被忽略的点。同一个设备在短时间内可能被上报多次，如果每次都触发业务逻辑，会造成重复处理和电量浪费。我的做法是用一个ConcurrentHashMap记录每个 MAC 地址的最后上报时间，超过一定间隔（比如 5 秒）才认为是新事件。

4. 实操过程与核心环节实现

4.1 完整的前台服务实现

下面是一个可以直接参考的前台服务实现，包含了通知渠道创建、扫描启动、扫描停止等核心逻辑。

public class BleScanService extends Service { private static final String CHANNEL_ID = "ble_scan_channel"; private static final int NOTIFICATION_ID = 1001; private BluetoothLeScanner scanner; private ScanCallback scanCallback; @Override public void onCreate() { super.onCreate(); createNotificationChannel(); BluetoothManager manager = (BluetoothManager) getSystemService(BLUETOOTH_SERVICE); BluetoothAdapter adapter = manager.getAdapter(); if (adapter != null) { scanner = adapter.getBluetoothLeScanner(); } } @Override public int onStartCommand(Intent intent, int flags, int startId) { startForeground(NOTIFICATION_ID, buildNotification()); startBleScan(); return START_STICKY; } private void createNotificationChannel() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { NotificationChannel channel = new NotificationChannel( CHANNEL_ID, "蓝牙扫描服务", NotificationManager.IMPORTANCE_LOW); channel.setDescription("保持蓝牙设备连接"); NotificationManager nm = getSystemService(NotificationManager.class); if (nm != null) nm.createNotificationChannel(channel); } } private Notification buildNotification() { Notification.Builder builder; if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { builder = new Notification.Builder(this, CHANNEL_ID); } else { builder = new Notification.Builder(this); } return builder .setContentTitle("设备连接中") .setContentText("正在保持蓝牙连接") .setSmallIcon(R.drawable.ic_ble) .setOngoing(true) .build(); } private void startBleScan() { if (scanner == null) return; ScanSettings settings = new ScanSettings.Builder() .setScanMode(ScanSettings.SCAN_MODE_LOW_POWER) .build(); List<ScanFilter> filters = new ArrayList<>(); // 根据实际设备添加过滤条件 scanCallback = new ScanCallback() { @Override public void onScanResult(int callbackType, ScanResult result) { // 处理扫描结果 } @Override public void onScanFailed(int errorCode) { // 处理扫描失败 } }; scanner.startScan(filters, settings, scanCallback); } @Override public void onDestroy() { if (scanner != null && scanCallback != null) { scanner.stopScan(scanCallback); } super.onDestroy(); } @Override public IBinder onBind(Intent intent) { return null; } }

START_STICKY这个返回值很关键，它告诉系统“服务被杀死后尽量重建”。但要注意，Android 8.0+ 对后台服务的重建有严格限制，START_STICKY只在服务因为内存不足被杀时有效，如果是被系统主动限制，重建也会失败。所以不能完全依赖它。

4.2 锁屏唤醒的完整链路

锁屏唤醒的链路是这样的：前台服务启动 PendingIntent 扫描 → 系统在底层持续监听 → 发现匹配设备 → 发送 PendingIntent → 静态广播接收器收到 → 启动前台服务或发通知 → 用户点击回到 App。

这里有个细节：PendingIntent扫描和普通ScanCallback扫描不能同时进行。如果你已经用ScanCallback启动了扫描，再调用startScan(filters, settings, pendingIntent)会抛异常。所以切换时要先stopScan。

// 切换到 PendingIntent 扫描 if (scanner != null) { scanner.stopScan(scanCallback); scanner.startScan(filters, settings, pendingIntent); }

另外，PendingIntent扫描在部分设备上需要屏幕关闭后才生效，这是系统行为，不用纠结。实测下来，三星、小米、OPPO 的部分机型在锁屏后 1-2 分钟内会进入深度休眠，此时 PendingIntent 扫描仍然有效，但普通扫描回调会停止。

4.3 JobScheduler 兜底重连

即使做了前台服务和 PendingIntent，仍然有可能被系统杀掉。这时候需要一个兜底机制，定期检查服务是否存活，如果挂了就重新拉起。JobScheduler 是最合适的选择，因为它由系统统一调度，不受后台限制影响。

ComponentName component = new ComponentName(this, BleScanJobService.class); JobInfo jobInfo = new JobInfo.Builder(JOB_ID, component) .setPersisted(true) .setPeriodic(15 * 60 * 1000) // 最小 15 分钟 .setRequiredNetworkType(JobInfo.NETWORK_TYPE_NONE) .build(); JobScheduler scheduler = (JobScheduler) getSystemService(JOB_SCHEDULER_SERVICE); if (scheduler != null) { scheduler.schedule(jobInfo); }

setPersisted(true)表示设备重启后任务仍然有效，但需要RECEIVE_BOOT_COMPLETED权限。setPeriodic的最小间隔是 15 分钟，这是系统硬性限制，改不了。所以 JobScheduler 只能做兜底，不能做实时扫描。

在BleScanJobService的onStartJob里，检查前台服务是否在运行，如果不在就重新启动。判断服务是否运行可以用ActivityManager.getRunningServices()，但这个 API 在新版本上已经不可靠了。更稳妥的做法是用一个静态变量或者 SharedPreferences 记录服务状态。

4.4 厂商 ROM 的适配要点

国内厂商 ROM 对后台的限制比原生 Android 更狠，这是绕不开的现实。我整理了几个主流厂商的适配要点：

代码层面能做的有限，主要是申请REQUEST_IGNORE_BATTERY_OPTIMIZATIONS权限，引导用户关闭电池优化。但注意，这个权限在 Google Play 上架时有严格审核，不能滥用，否则会被拒。

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { Intent intent = new Intent(); intent.setAction(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS); intent.setData(Uri.parse("package:" + getPackageName())); startActivity(intent); }

提示：引导页不要做得太激进，否则用户反感。我的做法是在检测到扫描异常时，弹一个温和的提示，告诉用户“为了保持设备连接，建议开启自启动权限”，并提供一个跳转按钮。

5. 常见问题与排查技巧实录

5.1 扫描不到设备怎么办

这是最高频的问题。排查顺序如下：

1. 检查权限：Android 12+ 必须动态申请BLUETOOTH_SCAN和BLUETOOTH_CONNECT，定位权限也要给。
2. 检查蓝牙开关：BluetoothAdapter.isEnabled()返回 false 时，扫描会静默失败。
3. 检查扫描是否真的启动了：startScan返回 void，不会告诉你成功与否，要在onScanFailed里看错误码。
4. 检查过滤条件：ScanFilter设得太严会过滤掉所有设备，先不加过滤扫一遍看看能不能扫到。
5. 检查厂商限制：部分 ROM 在锁屏后会关闭蓝牙扫描，需要在设置里允许后台扫描。

onScanFailed的错误码含义：

5.2 锁屏后扫描停止怎么排查

锁屏后扫描停止，通常是以下几个原因：

• 没有用前台服务：普通后台服务在锁屏后会被冻结。
• 没有用 PendingIntent 扫描：普通 ScanCallback 在 App 冻结后不再回调。
• 通知被用户划掉：前台服务的通知被划掉后，服务可能被降级为后台服务。
• 电池优化没关闭：系统进入 Doze 模式后，会暂停所有后台任务。

排查方法：在onScanResult里打日志，看锁屏后多久停止回调。如果 1 分钟内就停了，基本是前台服务没生效；如果 5-10 分钟才停，可能是 Doze 模式导致的。

5.3 PendingIntent 收不到广播怎么办

这个问题我踩过好几次，总结下来有这几个原因：

第一，PendingIntent的 flag 不对。Android 12+ 必须用FLAG_MUTABLE，用FLAG_IMMUTABLE会导致系统无法填充扫描结果。

第二，广播接收器没有静态注册。动态注册的 Receiver 在 App 冻结后收不到广播。

第三，Intent 的 action 不匹配。PendingIntent创建时用的 action 和 Receiver 里判断的 action 必须完全一致。

第四，部分 ROM 限制了隐式广播。虽然 PendingIntent 发送的是显式广播（指定了包名和类名），但部分 ROM 仍然会拦截。解决办法是在 Intent 里显式设置setPackage(getPackageName())。

Intent intent = new Intent(context, BleScanReceiver.class); intent.setAction("com.example.BLE_SCAN_RESULT"); intent.setPackage(context.getPackageName());

5.4 电量消耗过大的优化技巧

蓝牙扫描是耗电大户，优化不好用户会直接卸载。我的优化经验：

• 用 ScanFilter 过滤：只上报关心的设备，减少回调次数。
• 降低扫描频率：后台用SCAN_MODE_LOW_POWER，窗口和间隔拉大。
• 用 PendingIntent 替代 ScanCallback：锁屏后让系统在底层筛选，只在匹配时才唤醒 App。
• 及时 stopScan：不需要扫描时立刻停止，不要一直挂着。
• 批量上报：setReportDelay设一个值（比如 2000ms），让系统批量上报，减少唤醒次数。

实测数据：优化前后台扫描一小时耗电约 8%-12%，优化后降到 2%-4%。这个差距在用户感知上非常明显。

5.5 常见问题速查表

6. 几个容易被忽略的细节

6.1 通知的重要性等级不能太高

前台服务的通知如果设成IMPORTANCE_HIGH，会发出声音和震动，用户会很烦。蓝牙扫描场景用IMPORTANCE_LOW就够了，静默显示在通知栏即可。但也不能设成IMPORTANCE_MIN，因为部分 ROM 会把IMPORTANCE_MIN的通知折叠，导致前台服务被降级。

6.2 扫描回调的线程问题

ScanCallback的回调默认在主线程执行，如果处理逻辑耗时，会阻塞主线程导致 ANR。正确做法是在回调里只做数据拷贝，把耗时操作丢到子线程或者用 Handler 处理。

private final Handler workerHandler = new Handler( HandlerThreadExecutor.getBackgroundLooper()); @Override public void onScanResult(int callbackType, ScanResult result) { ScanResult copy = new ScanResult(result); workerHandler.post(() -> processResult(copy)); }

6.3 Android 13 的通知权限

Android 13（API 33）开始，通知需要动态申请POST_NOTIFICATIONS权限。如果用户拒绝了通知权限，前台服务的通知不会显示，但服务本身仍然可以运行。不过部分 ROM 会因为通知不可见而限制服务，所以还是要引导用户授予通知权限。

6.4 蓝牙适配器的状态监听

蓝牙可能被用户手动关闭，或者因为系统原因重启。要注册BluetoothAdapter.ACTION_STATE_CHANGED广播，在蓝牙关闭时停止扫描，在蓝牙开启时重新启动扫描。这个细节不做的话，蓝牙一关一开，扫描就彻底失效了。

IntentFilter filter = new IntentFilter(BluetoothAdapter.ACTION_STATE_CHANGED); registerReceiver(new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { int state = intent.getIntExtra(BluetoothAdapter.EXTRA_STATE, -1); if (state == BluetoothAdapter.STATE_ON) { startBleScan(); } else if (state == BluetoothAdapter.STATE_OFF) { stopBleScan(); } } }, filter);

7. 实际项目中的经验体会

这套方案我在三个量产项目里用过，分别是智能手环、蓝牙防丢器和工业温度采集器。智能手环项目对实时性要求最高，用的是前台服务 + 普通扫描，锁屏后靠 PendingIntent 兜底；防丢器项目对功耗最敏感，全程用 PendingIntent 扫描，App 只在收到广播时才短暂唤醒；工业采集器项目环境最恶劣，加了 JobScheduler 每 15 分钟检查一次服务状态。

踩过最大的坑是小米的省电策略。测试机是小米 10，锁屏后 3 分钟服务必被杀，日志显示是系统主动限制。后来发现是没加自启动白名单，引导用户设置后问题解决。这件事让我意识到，代码写得再好，也架不住厂商 ROM 的限制，用户引导页是必须做的。

另一个坑是 PendingIntent 的 flag。Android 12 刚出来的时候，我用FLAG_IMMUTABLE死活收不到广播，排查了一整天才发现是 flag 的问题。这个细节在官方文档里写得很清楚，但很容易忽略。

最后分享一个小技巧：在开发阶段，可以用adb shell dumpsys bluetooth_manager查看当前蓝牙扫描状态，用adb shell dumpsys activity services查看前台服务是否存活。这两个命令在排查问题时非常有用，比打日志快得多。