粘性服务对 Android 中具有庞大单体代码库的应用程序的影响？

Question

众所周知，Java memory model由数据（或代码）、栈和堆段组成。我认为Android也是如此。我有一个单一的单体应用程序（让我们认为这个应用程序的代码库太大了）。当我启动应用程序时，应用程序中的活动和片段被加载到 Dalvik JVM 并被卸载。在这种情况下，这如何与服务一起使用？假设我有一个STICKY_SERVICE 之类的，

public class CountingNumberService extends Service {
    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        for(int i=0; i<100; i++) {
            //Do something
        }
        return Service.START_STICKY;
    }
    @Override
    public IBinder onBind(Intent intent) {
        /**
         * This has to do with some inter process communication
         */
        return null;
    }
}

由于服务是STICKY，它使进程表现得像一个持久进程并且它一直在运行。现在考虑我停止使用我的应用程序，并且作为用户，我认为应用程序已关闭（我正在关闭它或从最近清除它）但由于我的服务是 STICKY 它会一直在运行，我假设我会有以下影响，

1. 我会吃掉用户的电池。
2. 一些额外的代码（除了服务）将与应用程序一起运行（？）但不确定。如果是整个应用程序都位于数据段中，那么它将不允许其他应用程序顺利运行。

我对进程上的STICKY 服务（巨大的单体代码）及其影响感到有些困惑。有人可以澄清一下吗？

Answer 1

由于服务是 STICKY，它使进程表现得像一个持久进程并且它始终在运行。

不，它没有。

但由于我的服务是 STICKY，它会一直运行

不，不会的。

引用the documentation for START_STICKY:

如果此服务的进程在启动时被杀死（从onStartCommand(Intent, int, int) 返回后），则将其保持在启动状态，但不要保留此传递的意图。稍后系统将尝试重新创建服务。

仍然欢迎 Android 在它认为合适的情况下终止您的进程。 START_STICKY 所做的只是鼓励 Android 在条件允许的情况下重新启动您的服务（沿途分叉一个新进程）。