为什么不直接在Android中实例化服务？

我想知道为什么不建议通过构造函数直接实例化服务类。我找不到任何与之相关的东西。下面是一个非常基本的例子：

服务类别：

public class SomeRandomClass extends Service {

    private final Context mContext;

    public SomeRandomClass(Context context) {
        this.mContext = context;
    }
}

以及内部主要活动/服务：

SomeRandomClass class = new SomeRandomClass(this);
class.someMethod();

文章指出，直接实例化服务不是一个好主意，应该使用

startService（）

，但是为什么呢？如果我像这样实例化我的服务，我有一个直接指向服务的变量，我可以调用方法，而不必绑定到它，以便能够调用我的服务上的方法

通过使用

startService（）

我能看到的唯一优点是Android跟踪我的服务，但缺点是我必须绑定到服务才能与之通信。 另一方面，通过直接调用构造函数，我可以轻松地进行通信，但是如果我的活动/服务被终止/终止，“子”服务也被终止（我使用的不是活动而是其他服务）

---

还有什么其他原因不鼓励它吗？

只有当您想使用服务提供的设施时，将某个RandomClass作为服务才有意义。为了获得这些设施，您需要正确启动服务

但您似乎不想使用这些设施（自动后台生命周期管理，可能在单独的过程中）。您似乎想要的只是一个普通的旧类，没有扩展服务。

该官员将

服务描述为

（…）一种应用程序组件，表示应用程序希望在不与用户交互的情况下执行较长时间的运行操作，或为其他应用程序提供功能以供使用

因此，
服务
仍将运行，即使您的当前活动因资源管理优先级而被系统终止

如果您决定将某个活动或应用程序上下文中的某个服务实例化为一个子类，那么您可以将其实例化为一个单实例，但预期它们被破坏的频率要比Android
服务
要高得多