返回

Android熄屏AltBeacon扫描失效？原因分析与解决方案

Android

解决 AltBeacon 在 Android 熄屏后无法发现 Beacon 的问题

搞 BLE 网关应用，让它在后台一直默默扫描 Beacon 并把数据发给服务器？听起来挺酷，实际搞起来可能会碰到坑。一个常见的问题是：应用在前台、后台、锁屏时都工作得好好的，Beacon 都能扫到。但只要手机屏幕一关，虽然扫描的回调还在触发，却死活发现不了 Beacon 了。这到底是咋回事？

问题

简单来说，情况是这样的：

  • 设备 & 环境 : Pixel 6a, Android 15, AltBeacon 库版本 v2.20.3
  • 现象 :
    • 屏幕亮屏，应用前台：正常扫描，能发现 Beacon。
    • 屏幕亮屏，应用后台：正常扫描，能发现 Beacon。
    • 屏幕亮屏，应用被杀掉（如果服务配置正确启动）：正常扫描，能发现 Beacon。
    • 屏幕亮屏，设备锁屏：正常扫描，能发现 Beacon。
    • 屏幕熄灭 : 扫描任务似乎在运行（回调被触发），但 didRangeBeaconsInRegion 或类似回调里返回的 beacons 列表是空的！

看起来就像熄屏状态下，蓝牙扫描硬件或者系统层面对结果做了什么限制，导致应用层收不到 Beacon 数据。

问题根源分析

熄屏后扫不到 Beacon，这通常不是 AltBeacon 库本身的问题，而是 Android 系统为了省电或者管理后台行为而引入的各种机制导致的。主要原因可能包括：

  1. 后台执行限制 (Background Execution Limits) : 从 Android 8.0 (Oreo) 开始，系统对应用在后台能做的事情做了很多限制。如果没有采取特殊措施（比如 Foreground Service），应用进程在后台很容易被暂停或杀死，其执行能力（包括启动扫描）会受限。虽然你的回调被触发，但这可能只是 JobScheduler 或类似机制按计划唤醒了应用一小会儿，而实际的蓝牙扫描操作可能因为更深层次的限制而无法有效执行。
  2. Doze 模式 (Doze Mode) : 当设备长时间未使用、屏幕关闭且静止时，Android 会进入 Doze 模式（低功耗模式）。在 Doze 模式下，系统会限制应用访问网络、执行同步、以及 运行后台任务（包括 BLE 扫描） 。系统只会提供短暂的“维护窗口期”让应用执行延迟的任务。即便你的应用能被唤醒触发回调，可能也正好错过了维护窗口，或者在窗口期内执行扫描的能力被严格限制了。
  3. App Standby (应用待机模式) : 如果用户一段时间没有主动使用某个应用，系统会将其置于 App Standby 状态，限制其网络访问和后台任务执行。
  4. BLE 扫描节流 (BLE Scan Throttling) : 为了省电和防止滥用，Android 系统（尤其在较新版本中）对后台 BLE 扫描的频率和持续时间有限制。即使你的应用通过某种方式保持运行（如 Foreground Service），过于频繁或长时间的后台扫描也可能被系统悄悄“降级”或限制结果上报。熄屏状态下这种节流可能更严格。
  5. 硬件/驱动特定行为 : 不同手机厂商的蓝牙芯片或驱动程序在低功耗状态（如熄屏）下的行为可能有所不同。有些硬件在屏幕关闭后可能会进入更深的睡眠状态，影响扫描的灵敏度或响应速度。
  6. 权限问题 : 虽然在屏幕亮时能工作，但不排除某些权限（特别是与后台位置相关的权限）的授予状态在特定条件下发生了变化，或者没有正确请求适用于后台操作的权限。Android 10 及以上版本对后台位置访问有更严格的要求。
  7. AltBeacon 库配置 : 不正确的扫描周期设置（如后台扫描周期 backgroundScanPeriod 设置得过短）也可能导致问题，或者与系统节流策略冲突。

综合来看，最可能的原因是 后台执行限制 和 Doze/App Standby 模式，配合 系统级的 BLE 扫描节流 ，共同导致了熄屏后无法有效接收 Beacon 广播。

解决方案

要确保应用能在熄屏状态下持续、可靠地扫描 Beacon，需要采取一些措施来“告知”Android 系统你的应用正在执行重要的后台任务，并合理配置扫描参数。

方案一：使用 Foreground Service (前台服务)

这是最推荐也是最符合 Android 设计规范的做法，用于需要长时间在后台执行用户可见任务（比如音乐播放、导航、持续的设备连接或扫描）的场景。

原理和作用 :

  • 启动一个 Foreground Service 会在系统通知栏显示一个持续的通知，告知用户你的应用正在后台运行。
  • 这会显著提高你应用进程的优先级，系统轻易不会杀死它。
  • 能有效绕过 Doze 模式和 App Standby 对应用大部分操作的限制（虽然某些深度 Doze 状态下仍可能有轻微影响，但比普通后台服务好太多）。
  • 对于需要访问位置信息的后台 BLE 扫描（Android 10+），Foreground Service 是获取后台位置权限的前提条件之一。

操作步骤 :

  1. 添加权限 : 在 AndroidManifest.xml 中添加 Foreground Service 权限。根据你的 Android Target SDK 版本，可能还需要特定的前台服务类型。对于 BLE 扫描，通常涉及位置信息。

    <manifest ...>
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
    <!-- Android 10 (API 29)及以上，如果扫描需要位置信息 -->
    <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
    <!-- Android 12 (API 31)及以上，需要明确指定服务类型 -->
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE_LOCATION" />
    <!-- Android 13 (API 33)及以上，需要通知权限来显示前台服务通知 -->
    <uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

    <application ...>
        <service
            android:name=".YourBeaconScanningService"
            android:foregroundServiceType="location" <!-- Android 10+ 需要指定类型 -->
            android:exported="false" />
        ...
    </application>
</manifest>

  2. 创建 Service : 创建一个继承自 Service 的类。在这个 Service 的 onCreate 或 onStartCommand 方法中，初始化并启动 AltBeacon 扫描。

  3. 创建 Notification Channel (Android 8.0+) :

    // 在 Service 的 onCreate 或 Application 类中创建
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    val channelId = "beacon_scan_channel"
    val channelName = "Beacon Scanning Service"
    val importance = NotificationManager.IMPORTANCE_LOW // 或者更低，避免声音/震动
    val channel = NotificationChannel(channelId, channelName, importance).apply {
        description = "Notification for ongoing beacon scanning"
    }
    val notificationManager = getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager
    notificationManager.createNotificationChannel(channel)
}

  4. 构建并显示通知，启动 Foreground Service :

    import android.app.Notification
import android.app.PendingIntent
import android.app.Service
import android.content.Intent
import android.os.Build
import android.os.IBinder
import androidx.core.app.NotificationCompat
import org.altbeacon.beacon.*

class YourBeaconScanningService : Service(), BeaconConsumer {

    private lateinit var beaconManager: BeaconManager
    private val channelId = "beacon_scan_channel"
    private val notificationId = 123 // Choose a unique ID

    override fun onCreate() {
        super.onCreate()
        beaconManager = BeaconManager.getInstanceForApplication(this)
        // 配置你的 Beacon Parser, e.g., iBeacon
        beaconManager.beaconParsers.add(BeaconParser().setBeaconLayout("m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"))

        // 设置扫描周期 (可以保持默认，或根据需要调整，后面会讨论)
        // beaconManager.setBackgroundScanPeriod(5000L) // 5 seconds
        // beaconManager.setBackgroundBetweenScanPeriod(60000L) // 60 seconds

        // 重要: 禁用 JobScheduler，让服务自己管理扫描周期
        // 在使用前台服务时，通常推荐禁用 JobScheduler 以获得更可控的扫描行为
        beaconManager.setEnableScheduledScanJobs(false)

        beaconManager.bind(this)
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        val notification = createNotification()
        startForeground(notificationId, notification) // 启动前台服务！

        // 这里可以再次确保 beaconManager 绑定和开始扫描
        if (!beaconManager.isBound(this)) {
            beaconManager.bind(this)
        } else if (beaconManager.isBound(this)) {
            // 如果已经绑定，可能需要重新启动扫描逻辑，确保它在运行
            startScanning()
        }


        return START_STICKY // Service 被杀死后尝试重启
    }

    override fun onDestroy() {
        super.onDestroy()
        if (beaconManager.isBound(this)) {
            beaconManager.unbind(this)
        }
        stopForeground(true) // 停止前台服务
    }

    override fun onBind(intent: Intent?): IBinder? {
        return null // 非绑定服务
    }

    override fun onBeaconServiceConnect() {
        // 服务连接成功后开始扫描
         startScanning()
    }

     private fun startScanning() {
        val region = Region("all-beacons-region", null, null, null)
        try {
            // 设置监听器
            beaconManager.addRangeNotifier { beacons, region ->
                Log.d("BeaconScanService", "Found ${beacons.size} beacons in region $region")
                if (beacons.isNotEmpty()) {
                    // 处理发现的 beacons...
                    // 发送数据到服务器等
                }
            }
            // 开始扫描
            beaconManager.startRangingBeaconsInRegion(region)
            Log.i("BeaconScanService", "Started ranging beacons")
        } catch (e: Exception) {
            Log.e("BeaconScanService", "Cannot start ranging", e)
        }
    }


    private fun createNotification(): Notification {
        val notificationIntent = Intent(this, MainActivity::class.java) // 点击通知时打开的 Activity
        val pendingIntentFlags = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
             PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
         } else {
             PendingIntent.FLAG_UPDATE_CURRENT
         }
        val pendingIntent = PendingIntent.getActivity(this, 0, notificationIntent, pendingIntentFlags)


        return NotificationCompat.Builder(this, channelId)
            .setContentTitle("Beacon Scanner Active")
            .setContentText("Scanning for nearby beacons in the background.")
            .setSmallIcon(R.drawable.ic_launcher_foreground) // 替换成你自己的图标
            .setContentIntent(pendingIntent)
             .setOngoing(true) // 使通知不能被轻易划掉
            .setCategory(NotificationCompat.CATEGORY_SERVICE)
            .setPriority(NotificationCompat.PRIORITY_LOW) // 低优先级，避免打扰
            .build()
    }
}

  5. 启动 Service : 在你的 Activity 或 Application 类中适时启动这个 Service。

    val serviceIntent = Intent(this, YourBeaconScanningService::class.java)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    startForegroundService(serviceIntent) // Android 8+ 必须用这个
} else {
    startService(serviceIntent)
}

安全建议 :

  • 明确告知用户 : 在应用内清楚解释为什么需要这个后台服务和通知，以及它在做什么。
  • 提供停止选项 : 给用户一个明确的方式来停止后台扫描服务。
  • 使用合适的通知优先级 : IMPORTANCE_LOW 或 IMPORTANCE_MIN 通常足够，避免打扰用户。

进阶技巧 :

  • 使用 START_STICKY 可以让系统在服务被意外杀死后尝试重启它。
  • 考虑在 Service 内部实现重试逻辑，处理 beaconManager 绑定失败或扫描启动异常的情况。
  • 监听网络状态变化，只在网络可用时发送数据到服务器，减少失败尝试。

方案二：优化扫描参数

即使使用了 Foreground Service，不合理的扫描参数也可能导致问题，尤其是在电量受限的场景下。AltBeacon 库区分前台和后台扫描周期。

原理和作用 :

  • scanPeriod (扫描周期) : 一次连续扫描持续多长时间。
  • betweenScanPeriod (扫描间隔) : 两次扫描之间的休息时间。
  • AltBeacon 有 foregroundScanPeriod, foregroundBetweenScanPeriod 和 backgroundScanPeriod, backgroundBetweenScanPeriod。当你使用 Foreground Service 时，它运行在前台模式，所以 foreground... 参数生效。但默认情况下，若不配置Foreground Service，Activity转入后台后，它可能切换到background模式参数（虽然推荐在服务里一直用foreground模式逻辑，除非特别设计）。
  • 过于频繁的扫描（短 scanPeriod，短 betweenScanPeriod）会大量消耗电量，并且更容易触发系统的扫描节流机制。在熄屏时，系统可能对这种高频扫描格外严格。

操作步骤 :

  1. 在 BeaconManager 初始化时设置合理的周期 :
    对于持续后台扫描，尤其是通过 Foreground Service 实现时，设置一个相对不那么激进的扫描周期可能更稳定、更省电。

    beaconManager = BeaconManager.getInstanceForApplication(this)
// ... 其他配置 ...

// 示例：每 10 秒扫描 1.1 秒 (AltBeacon 默认前景参数)
 // beaconManager.setForegroundScanPeriod(1100L)
 // beaconManager.setForegroundBetweenScanPeriod(0L) // 0L 意味着连续扫描，直到scanPeriod结束

// 尝试更长的周期和间隔，适合后台/熄屏场景，更省电，可能更不易被系统节流
 beaconManager.setForegroundScanPeriod(5000L) // 扫描 5 秒
 beaconManager.setForegroundBetweenScanPeriod(25000L) // 休息 25 秒 (总周期 30 秒)

// 确保不使用 JobScheduler (如果已采用 Foreground Service 方案)
 beaconManager.setEnableScheduledScanJobs(false)

beaconManager.bind(this) // 绑定服务以应用配置

    你需要根据实际应用场景（Beacon 密度、要求实时性等）和测试结果来调整这两个值。关键是找到一个平衡点：既能及时发现 Beacon，又不会过度消耗资源或被系统限制。

进阶技巧 :

  • 动态调整：可以根据设备是否充电、网络连接状况等动态调整扫描参数。比如，充电时可以扫描得频繁些，用电池时则保守些。
  • 考虑 BeaconManager.setRegionExitPeriod(milliseconds): 这个参数定义了在多久没收到某个 Region 的 Beacon 后触发 didExitRegion 回调。默认是 10 秒。如果你的 Beacon 发射频率很低，可能需要适当调大这个值，防止误判退出区域。

方案三：请求忽略电池优化 (谨慎使用)

可以请求用户将你的应用加入电池优化白名单，这样系统就不会对它施加 Doze 和 App Standby 限制。

原理和作用 :

  • 拥有 REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 权限的应用可以引导用户去系统设置里将其排除在电池优化之外。
  • 白名单应用基本不受 Doze 和 App Standby 的影响。

操作步骤 :

  1. 添加权限 : 在 AndroidManifest.xml 中添加：

    <uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>

  2. 检查并请求用户授权 :

    import android.content.Context
import android.content.Intent
import android.net.Uri
import android.os.Build
import android.os.PowerManager
import android.provider.Settings

fun checkAndRequestBatteryOptimization(context: Context) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
        val packageName = context.packageName
        val pm = context.getSystemService(Context.POWER_SERVICE) as PowerManager
        if (!pm.isIgnoringBatteryOptimizations(packageName)) {
            // 应用不在白名单，引导用户去设置
            val intent = Intent().apply {
                action = Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
                data = Uri.parse("package:$packageName")
            }
             // 最好在用户明确要求或理解为何需要时再弹出
             if (intent.resolveActivity(context.packageManager) != null) {
                 context.startActivity(intent)
             } else {
                  // 处理无法跳转到设置页面的情况，可能提示用户手动设置
             }
        } else {
             // 应用已在白名单中
        }
    }
}

重要提示与安全建议 :

  • Google Play 政策 : Google Play 对请求此权限的应用有严格审查。大多数应用不应请求此权限，除非它们的核心功能确实因电池优化而完全无法实现（例如报警应用、企业设备管理应用）。普通的 Beacon 网关应用很可能 不符合 要求。提交到 Play Store 前务必查阅最新政策。
  • 用户体验 : 强制用户关闭电池优化可能引起反感，因为这会显著增加耗电。
  • 优先选择 Foreground Service : Foreground Service 是官方推荐的、对用户更透明、也更符合平台规范的方案。通常情况下，Foreground Service + 合理的扫描参数就足够了。只有在 Foreground Service 仍然无法满足需求，且你有充分理由说服用户和应用商店时，才考虑此方案。

方案四：检查并请求所有必要权限

确保你的应用在运行时获得了所有需要的权限，特别是 Android 6.0 (Marshmallow) 及以上版本引入的运行时权限。

原理和作用 :

  • BLE 扫描涉及蓝牙和位置信息（即使你不直接使用地理位置，发现附近设备也需要位置权限）。
  • Android 版本越高，权限管理越细致。例如，Android 12 引入了 BLUETOOTH_SCAN 和 BLUETOOTH_CONNECT 权限，取代了旧的 BLUETOOTH 和 BLUETOOTH_ADMIN，并区分了精确位置 (ACCESS_FINE_LOCATION) 和大致位置 (ACCESS_COARSE_LOCATION)。后台位置访问需要 ACCESS_BACKGROUND_LOCATION。Foreground Service 显示通知需要 POST_NOTIFICATIONS (Android 13+)。

操作步骤 :

  1. 在 AndroidManifest.xml 中声明所有权限 : 参考方案一中的权限列表，根据你的 Target SDK 和功能需求添加。

  2. 在运行时动态请求权限 : 使用 Activity Result API (推荐) 或传统的 requestPermissions 方法。

    import androidx.activity.result.contract.ActivityResultContracts
import androidx.appcompat.app.AppCompatActivity
import android.Manifest
import android.content.pm.PackageManager
import android.os.Build
import androidx.core.content.ContextCompat

class MainActivity : AppCompatActivity() {

    private val requestPermissionsLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->
            var allGranted = true
            permissions.entries.forEach {
                if (!it.value) {
                    allGranted = false
                    Log.w("Permissions", "Permission not granted: ${it.key}")
                }
            }
            if (allGranted) {
                // 所有权限都获取成功，可以启动服务或进行其他操作
                startMyBeaconService()
            } else {
                // 权限被拒绝，告知用户功能受限或再次请求
                Log.e("Permissions", "Not all required permissions were granted.")
                 // 这里可以显示提示，解释为何需要权限
            }
        }

    fun checkAndRequestPermissions() {
        val requiredPermissions = mutableListOf<String>()

         // BLE Scan permissions (Android 12+)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
             if (ContextCompat.checkSelfPermission(this, Manifest.permission.BLUETOOTH_SCAN) != PackageManager.PERMISSION_GRANTED) {
                requiredPermissions.add(Manifest.permission.BLUETOOTH_SCAN)
            }
             if (ContextCompat.checkSelfPermission(this, Manifest.permission.BLUETOOTH_CONNECT) != PackageManager.PERMISSION_GRANTED) {
                requiredPermissions.add(Manifest.permission.BLUETOOTH_CONNECT) // Although not strictly for scanning, often needed nearby
            }
        } else {
             // Older Android versions require Location for BLE scan
            if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED) {
                 requiredPermissions.add(Manifest.permission.ACCESS_FINE_LOCATION)
             }
             // Possibly BLUETOOTH and BLUETOOTH_ADMIN needed too, though handled by library often
        }

        // Location permissions needed regardless of Android version for scanning to work reliably
        if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED) {
             requiredPermissions.add(Manifest.permission.ACCESS_FINE_LOCATION)
        }
         // Optional: If you only need coarse location for some reason
        // if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_COARSE_LOCATION) != PackageManager.PERMISSION_GRANTED) {
        //     requiredPermissions.add(Manifest.permission.ACCESS_COARSE_LOCATION)
        // }


         // Background location (Android 10+) - request AFTER fine location is granted
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
            if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_BACKGROUND_LOCATION) != PackageManager.PERMISSION_GRANTED) {
                 // IMPORTANT: Request background location separately, after foreground location is granted.
                 // The system UI for this is different. Typically you explain why you need it, then direct user to settings or request here.
                 // For simplicity, adding here, but UX needs careful thought.
                requiredPermissions.add(Manifest.permission.ACCESS_BACKGROUND_LOCATION)
             }
        }


         // Notification permission (Android 13+) for Foreground Service notification
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            if (ContextCompat.checkSelfPermission(this, Manifest.permission.POST_NOTIFICATIONS) != PackageManager.PERMISSION_GRANTED) {
                requiredPermissions.add(Manifest.permission.POST_NOTIFICATIONS)
            }
        }

        if (requiredPermissions.isNotEmpty()) {
            requestPermissionsLauncher.launch(requiredPermissions.toTypedArray())
        } else {
             // 所有权限已就绪
            startMyBeaconService()
        }
    }

    private fun startMyBeaconService() {
        // 启动你的 Beacon Service (见方案一)
        Log.d("MainActivity", "All permissions granted, starting service...")
        val serviceIntent = Intent(this, YourBeaconScanningService::class.java)
         if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
             startForegroundService(serviceIntent)
         } else {
             startService(serviceIntent)
         }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
         super.onCreate(savedInstanceState)
         // ... setup UI ...

         // 在合适的时机（比如用户点击“开始扫描”按钮后）检查并请求权限
        // checkAndRequestPermissions()
    }
}

安全建议 :

  • 按需请求 : 只请求应用功能确实需要的权限。
  • 提供清晰解释 : 在请求权限前，向用户解释为什么需要这些权限，尤其像后台位置这种敏感权限。
  • 优雅处理拒绝 : 如果用户拒绝了权限，要能正常处理，或者再次解释并引导用户去设置中开启。

方案五：适配特定设备和系统版本

最后，不得不提的是 Android 生态的碎片化。

原理和作用 :

  • 某些手机厂商（如华为、小米、OPPO、VIVO 等）可能在 Android 系统之上添加了更激进的电源管理策略或后台限制。
  • 即使你使用了 Foreground Service，这些定制系统可能仍会干扰你的应用，或者需要用户在特定的“省电管理”、“应用自启动管理”等设置中手动将你的应用加入白名单。
  • 不同 Android 版本对后台行为的限制也在不断演进。Android 15 还在开发中，可能会引入新的变化。

操作步骤/建议 :

  1. 广泛测试 : 在目标用户群可能使用的各种设备和 Android 版本上进行充分测试，特别注意国产手机品牌和最新的 Android 系统。
  2. 查阅厂商文档/社区 : 了解特定厂商的后台限制和可能的解决方案（如果有的话）。有时需要引导用户进行手动设置。
  3. 代码适配 : 可能需要针对特定 Android 版本或设备型号做一些条件判断和适配。例如，Android 12 对 BLE 扫描做了改动，需要检查新权限。
  4. 保持库更新 : AltBeacon 库也在持续更新，以适配最新的 Android 系统行为和限制。确保使用较新且稳定的版本。你使用的 2.20.3 已经是比较新的版本，关注其后续更新。
  5. 监控与反馈 : 在应用中加入错误上报和性能监控，收集在不同设备上运行失败或表现不佳的数据，有助于定位和解决特定问题。

通过实施 Foreground Service、优化扫描参数、确保权限正确，并留意设备和系统差异，你应该能够解决 AltBeacon 在 Android 熄屏后无法发现 Beacon 的问题，让你的 BLE 网关应用稳定可靠地运行在后台。