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

Services によって提供される機能を使用したい場合にのみ、 SomeRandomClass が Service であることは意味があります。これらの機能を取得するには、サービスを適切に開始する必要があります。

ただし、これらの機能を使用したくないようです (自動バックグラウンド ライフサイクル管理、おそらく別のプロセスで)。あなたが望むように見えるのは、 Service を拡張せずに、単純な古いクラスです。

于 2013-09-17T21:52:00.777 に答える
0

公式ドキュメントでは、次のように説明されてServiceいます

(...) ユーザーと対話せずに実行時間の長い操作を実行するか、他のアプリケーションが使用する機能を提供するというアプリケーションの要求を表すアプリケーション コンポーネント。

その結果、Service現在のアクティビティがリソース管理の優先順位のためにシステムによって強制終了された場合でも、 は引き続き実行されます。

をサブクラス化する場合は、アプリのアクティビティまたはアプリケーション コンテキストからサービスをシングルトンとしてインスタンス化できますがApplication、Android よりも頻繁に破棄されることが予想されServiceます。

于 2013-09-17T21:56:27.133 に答える