我正在尝试创建一个允许用户记录路线(位置/GPS)的应用。为了确保即使屏幕关闭也能记录位置，我为位置记录创建了一个前台服务。我将位置存储在 Room Database 中，该数据库使用 Dagger2 注入(inject)到我的服务中。

但是，这个服务被 Android 杀死了，这当然不好。我可以订阅内存不足警告，但这并不能解决我的服务在运行 Android 8.0 的现代高端手机上大约 30 分钟后被终止的根本问题

我创建了一个只有“Hello world” Activity 和服务的最小项目:https://github.com/RandomStuffAndCode/AndroidForegroundService

服务是在我的Application类中启动的，路由日志是通过一个Binder启动的:

// Application
@Override
public void onCreate() {
    super.onCreate();
    mComponent = DaggerAppComponent.builder()
            .appModule(new AppModule(this))
            .build();

    Intent startBackgroundIntent = new Intent();
    startBackgroundIntent.setClass(this, LocationService.class);
    startService(startBackgroundIntent);
}

// Binding activity
bindService(new Intent(this, LocationService.class), mConnection, Context.BIND_AUTO_CREATE | Context.BIND_IMPORTANT);
// mConnection starts the route logging through `Binder` once connected. The binder calls startForeground()

我可能不需要 BIND_AUTO_CREATE 标志，我一直在测试不同的标志以试图不让我的服务被杀死 - 到目前为止还没有运气。

使用分析器，我似乎没有任何内存泄漏，内存使用量稳定在 ~35mb:

使用 adb shell dumpsys activity processes > tmp.txt 我可以确认 foregroundServices=true 并且我的服务在 LRU 列表中排名第 8:

Proc#3: prcp F/S/FGS trm: 0 31592:com.example.foregroundserviceexample/u0a93 (fg-service)

似乎不可能创建一个您可以信任不会被杀死的前台服务。所以，我们能做些什么？嗯……

1. 将服务放在一个单独的进程中，以试图让 Android 杀死 UI/Activity，同时不理会该服务。可能会有所帮助，但似乎不能保证
2. 坚持一切在服务中，例如一个房间数据库。每个变量，每个自定义类，每次发生任何更改，然后使用 START_STICKY 启动服务。这似乎有点浪费，并且不会导致非常漂亮的代码，但它可能会工作......有点。根据 Android 在杀死服务后重新创建服务所需的时间，大部分位置可能会丢失。

这真的是目前在 Android 上后台做事的状态吗？没有更好的办法吗？

编辑:将应用程序列入白名单以进行电池优化(禁用它)不会阻止我的服务被终止

编辑:使用 Context.startForegroundService() 启动服务并没有改善这种情况

编辑:所以这确实只发生在 一些 设备上，但它始终在它们上发生。我想您必须做出选择，要么不支持大量用户，要么编写非常丑陋的代码。太棒了。

最佳答案

由startForeground 启动的服务属于第二重要的组visible process :

2. A visible process is doing work that the user is currently aware of, so killing it would have a noticeable negative impact on the user experience. A process is considered visible in the following conditions:

3. It is running an Activity that is visible to the user on-screen but not in the foreground (its onPause() method has been called). This may occur, for example, if the foreground Activity is displayed as a dialog that allows the previous Activity to be seen behind it.

4. It has a Service that is running as a foreground service, through Service.startForeground() (which is asking the system to treat the service as something the user is aware of, or essentially visible to them).

5. It is hosting a service that the system is using for a particular feature that the user is aware, such as a live wallpaper, input method service, etc.

The number of these processes running in the system is less bounded than foreground processes, but still relatively controlled. These processes are considered extremely important and will not be killed unless doing so is required to keep all foreground processes running.

话虽如此，您永远无法确定您的服务在任何时候都不会被终止。例如。内存压力、电池电量低等。见 who-lives-and-who-dies .

关于如何处理，基本上你自己回答了这个问题。要走的路是START_STICKY :

For started services, there are two additional major modes of operation they can decide to run in, depending on the value they return from onStartCommand(): START_STICKY is used for services that are explicitly started and stopped as needed, while START_NOT_STICKY or START_REDELIVER_INTENT are used for services that should only remain running while processing any commands sent to them. See the linked documentation for more detail on the semantics.

作为一般准则，您应该尽可能少地在后台(或前台)服务中执行操作，即只进行位置跟踪并将其他所有内容保留在前台 Activity 中。只有跟踪需要很少的配置并且可以快速加载。此外，您的服务越小，它被杀死的可能性就越小。只要它没有被杀死，系统就会将您的 Activity 恢复到进入后台之前的状态。另一方面，前台 Activity 的“冷启动”应该不是问题。
我不认为这是丑陋的，因为这可以保证手机始终为用户提供最佳体验。这是它必须做的最重要的事情。不幸的是，某些设备会在 30 分钟后关闭服务(可能没有用户交互)。

所以，正如你所说，你必须

Persist everything in the service in e.g. a Room database. Every variable, every custom class, every time any of them changes and then start the service with START_STICKY.

见 creating a never ending service

隐含问题:

Depending on how long it takes for Android to re-create the service after killing it, a large portion of locations may be lost.

这通常只需要很短的时间。特别是因为您可以使用 Fused Location Provider Api用于位置更新，这是一个独立的系统服务，不太可能被杀死。所以主要看你需要在onStartCommand中重新创建服务的时间。

Also take note that from Android 8.0 onwards you need to use a forground service because of the background location limits.

编辑: 正如最近在新闻中报道的那样: 一些制造商可能会让您难以保持服务运行。本站https://dontkillmyapp.com/跟踪制造商和您设备的可能缓解措施。 Oneplus目前 (29.01.19) 是最严重的违规者之一。

When releasing their 1+5 and 1+6 phones, OnePlus introduced one of the most severe background limits on the market to date, dwarfing even those performed by Xiaomi or Huawei. Not only did users need to enable extra settings to make their apps work properly, but those settings even get reset with firmware update so that apps break again and users are required to re-enable those settings on a regular basis.

Solution for users

Turn off System Settings > Apps > Gear Icon > Special Access > Battery Optimization.

可惜有

No known solution on the developer end

关于android - 在高端手机上杀死最小的android前台服务，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49637967/