多くのアクティビティを持つアプリがあります。アクティビティの 1 つは、購入オプションを表示するためのものです。
課金ライブラリのサンプルアプリ（https://github.com/googlesamples/android-play-billing)、BillingClientLifecycle、BillingManager が使用され、これらは両方とも単一のアクティビティに関連付けられているため、アクティビティが作成/破棄されると接続が開かれ/閉じられます。
ただし、多くのアクティビティがあるアプリでは、異なるアクティビティごとにこれを個別に実行するのは理想的ではないようです。また、アプリの起動時にサブスクリプションが有効かどうかも確認したいと思います。
アプリの Application サブクラスに BillingClient を作成しようと考えています。ただし、これを行うと、BillingClient 接続が開かれるだけで、閉じられなくなります (onDestroy メソッドがないため)。これまでにこれを実行したことがある人はいますか? また、これはベスト プラクティスに反していますか? また、ネットワークやパフォーマンスに問題が発生するでしょうか?
ベストアンサー1
BillingClientImpl.java私はのソースを読みましたが、を呼び出さないことを意味するとしても、アプリケーション シングルトンとしてbilling-1.2.2-sources.jar使用しても安全だと信じています。BillingClientBillingClient.endConnection()
BillingClientImpl.javaActivityコンストラクタではは不要で、 を使用します。 を使用し、アプリのコンテキストを保存するために をContext呼び出すだけです。メソッドにはパラメータがありますが、アクティビティは保存されません。 唯一の目的は、課金の目的で を呼び出すことです。context.getApplicationContext()launchBillingFlowActivityactivity.startActivity(intent)
BillingClient.startConnectioncontext.registerReceiverは、独自の を登録するためBillingBroadcastReceiverに を呼び出しBroadcastReceiver、次にサービス接続をバインドするために を呼び出します。(繰り返しますが、これらの呼び出しは両方とも、特定の ではなく、context.bindServiceアプリ コンテキストに対して実行されます。)mApplicationContextActivity
アプリの存続期間中に課金クライアントが必要である限り、でおよび を呼び出しregisterReceiver、またはを呼び出さないことは安全かつ許容されます。bindServiceApplication.onCreate()unregisterReceiverunbindService
registerReceiverおよび/またはbindService呼び出しがコンテキストを使用する場合、これは安全ではありません。Activityが破棄されるServiceConnectionと がリークしますActivityが、アプリが破棄されると、そのプロセスは終了し、すべてのサービス接続が自動的にクリーンアップされるためです。