对于非绑定设备（也就是扫描后连接的这种模式），Android 上 BLE 的默认行为是应用拥有与 BLE 设备的连接。相比之下，Android 操作系统拥有绑定设备的连接。

这意味着对于非绑定设备的情形，如果您的应用程序由于资源限制在后台被操作系统终止，或者如果您的用户将您的应用程序滑开（立即终止它，效果明显😃），BLE 连接将丢失，您应该会看到大多数 BLE 外围设备再次开始广告。

尝试使您的应用程序进程尽可能长时间保持活动状态的最直接方法是使用前台服务。如何实现自己的前台服务，在 官方文档里 有明确的步骤。
foreground-services

前台服务本质上是一个带着 通知抽屉中的持久横幅 运行的服务(也就是状态栏有个通知 ），让用户了解您的应用程序正在后台执行某些操作。（A foreground service is essentially a Service that runs with a persistent banner in the notification drawer, keeping the user in the loop that your app is doing something in the background. ）
由于内存限制而被系统终止的概率非常低，但并非不可能。

值得注意的是，当用户在前台服务运行时滑离（swipes away ）您的应用程序时，您的应用程序进程仍然存在，但您的 Activity 堆栈和任何其他面向用户的元素都会被吹走（get blown away)。因此，必须格外小心以确保您的 BLE 逻辑存在于这些实体之外，就像在一个名为 ConnectionManager 的单例中处理应用程序的所有 BLE 需求一样。

通常，您的Activities和Fragments 不应该对 BLE 连接的状态做出任何假设。相反，他们应该依赖 ConnectionManager（或任何管理应用程序 BLE 需求的实体）作为唯一的事实来源，并根据 UI 的需要在 onCreate() 和 onResume() 中相应地更新 UI。

使用前台服务也不是完全安全的，因为 Android P 及更高版本具有自适应电池功能，有时会限制运行前台服务的应用程序进程的正常运行时间，但根据我们的经验，这似乎是随机发生的。到目前为止，解决此限制的唯一方法是要求您的用户关闭应用程序的电池优化，这是隐藏在“设置”应用程序中的一个选项。

其他 Android 后台处理技术，如依赖 AlarmManager 和 WorkManager 也是可行的，但连接事件不会是即时的，并且可能会丢失一些 BLE 通知或指示，如果这些事件发生时应用程序碰巧没有运行。
也就是说，如果您的应用程序不需要在事件发生时了解它们，并且可以定期唤醒，再次连接到 BLE 设备（如果它在附近），并查询新的数据, 那么 这些后台技术就是好的，可以接受的。