2

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

服务等级：

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 会跟踪我的服务，但缺点是我必须绑定到服务才能与之通信。另一方面，通过直接调用构造函数，我可以轻松进行通信，但是如果我的活动/服务被终止/终止，那么“子”服务也会被终止（我没有使用活动，而是使用其他服务）。

还有什么不鼓励的原因吗？

4

2 回答 2

6

如果您想使用服务提供的设施，那么将 SomeRandomClass 完全作为服务才有意义。为了获得这些设施，您需要正确启动服务。

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

于 2013-09-17T21:52:00.777 回答
0

官方文档描述Service为

(...) 一个应用程序组件，表示应用程序希望在不与用户交互的情况下执行更长时间运行的操作，或提供功能供其他应用程序使用。

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

如果您决定子类化，您可以从 Activity 或应用程序的应用程序上下文将服务实例化为单例Application，但预计它们会比 Android 更频繁地被销毁Service。

于 2013-09-17T21:56:27.133 回答