BLE后台扫描PendingIntent与ScanCallback两种扫描方式如何选择？

1. startScan(List<ScanFilter> filters, ScanSettings settings, PendingIntent callbackIntent) #

这个重载的核心是将扫描任务交给系统托管，和你的应用进程生命周期解绑。

优点 #

• 完美适配后台长时扫描场景：即使你的应用进程被系统回收，扫描任务也不会终止，扫描到符合过滤规则的设备时，系统会通过你传入的PendingIntent拉起对应的组件（BroadcastReceiver/Service/Activity）传递结果，不需要做应用保活
• 系统级功耗优化：统一调度蓝牙扫描任务，比应用自行在后台保活扫描的功耗低很多

缺点 #

• 结果回调延迟更高：扫描结果通过跨进程通信传递，比同进程直接回调的延迟高100ms以上，不适合对响应速度要求极高的场景
• 数据处理链路长：需要在PendingIntent对应的目标组件中自行解析扫描结果，异常排查难度更高
• 权限约束更多：Android 12及以上版本除了需要蓝牙扫描权限外，还需要确保PendingIntent关联的组件没有被系统后台限制拦截

2. startScan(List<ScanFilter> filters, ScanSettings settings, ScanCallback callback) #

这个重载的扫描任务和你的应用进程绑定，回调执行在应用进程内。

优点 #

• 回调实时性极高：扫描结果直接在应用进程内触发回调，延迟极低，适合需要快速响应扫描结果的前台交互场景
• 代码逻辑简单：扫描结果直接在回调方法中处理，不需要跨组件传递解析数据，开发和排查问题成本更低

缺点 #

• 后台扫描限制极大：Android 8.0及以上版本，应用退到后台后最多只能保持几分钟扫描，进程被销毁后扫描任务会直接被系统终止
• 后台长时扫描实现成本高：如果要在后台持续扫描，需要做应用进程保活，功耗高，还很容易被系统电源优化策略杀死

选型依据 #

• 若你的需求是应用退到后台、甚至进程关闭后仍然需要持续扫描BLE设备（比如Beacon采集、门禁自动感应等场景），直接选择PendingIntent版本
• 若你只需要应用在前台运行时扫描BLE设备，或者对扫描结果的响应速度要求很高（比如前台搜设备配对、连接的场景），直接选择ScanCallback版本

内容的提问来源于stack exchange，提问作者Sebastien