私はこれに対する満足のいく答えを見つけることができなかったので、ここに行きます：何が対処されActivity/Service.getApplication()、Context.getApplicationContext()？
このアプリケーションでは、どちらも同じオブジェクトを返します。ではActivityTestCaseただし、アプリケーションをあざけることになりますgetApplication()モックで戻って来るが、getApplicationContextまだ別のコンテキストのインスタンス（アンドロイドによって注入1）を返します。それはバグですか？わざとですか？
そもそも違いがわかりません。テストスイートの外で、両方の呼び出しが異なるオブジェクトで返されるケースはありますか？いつ、なぜ？さらに、なぜgetApplicationはとで定義されていますがActivity、Serviceでは定義されていませんContextか？常にどこからでも利用できる有効なアプリケーションインスタンスがあるべきではありませんか？
回答:
非常に興味深い質問です。それは主に意味的な意味だと思いますが、歴史的な理由によるものかもしれません。
現在のAndroidアクティビティとサービスの実装では、同じオブジェクトgetApplication()をgetApplicationContext()返しますが、これが常に当てはまるという保証はありません（たとえば、特定のベンダーの実装で）。
あなたがマニフェストに登録Applicationクラスをしたいのであれば、あなたがすべき決して呼び出しませんgetApplicationContext()、それはアプリケーションインスタンスではないかもしれないので、（あなたは明らかにテストフレームワークを経験している）、およびアプリケーションにキャスト。
getApplicationContext()そもそもなぜ存在するのか？
getApplication()はgetApplicationContext()Contextクラスで宣言されていますが、ActivityクラスとServiceクラスでのみ使用できます。
これは実際には1つのことを意味します。ブロードキャストレシーバーでコンテキストではなく、onReceiveメソッドでコンテキストが指定されたコードを記述する場合、呼び出すことができるのは getApplicationContext()。つまり、BroadcastReceiverでアプリケーションにアクセスできる保証はありません。
Androidコードを見ると、アタッチされたときにアクティビティがベースコンテキストとアプリケーションを受け取り、それらは異なるパラメーターであることがわかります。getApplicationContext()それはへの呼び出しであるデリゲートbaseContext.getApplicationContext()。
もう1つ：ほとんどの場合、Applicationをサブクラス化する必要はないとドキュメントに記載されています。
通常、サブクラス化する必要はありません
Application。ほとんどの場合、静的シングルトンは、よりモジュール的な方法で同じ機能を提供できます。シングルトンにグローバルコンテキストが必要な場合（たとえば、ブロードキャストレシーバーを登録するため）、それを取得する関数に、最初にシングルトンを構築ContextするContext.getApplicationContext()ときに内部的に使用するを指定できます 。
これが正確で正確な答えではないことは知っていますが、それでもあなたの質問に答えることはできますか？
android.app.Applicationは非常に役立ちます。たとえば、データベースの初期化に際限のない問題がありました。Application.onCreateそこに移動すると、魅力のように機能しました。今私はすべてのシステム全体の初期化をApplication行い、それなしで別のアプリを書くことはありません。
比較getApplication()とgetApplicationContext()。
getApplication戻ってApplication次のようないくつかのデバイスの状況にあなたのグローバルなアプリケーションの状態と応答を管理できるようになりますオブジェクトonLowMemory()とonConfigurationChanged()。
getApplicationContextグローバルアプリケーションコンテキストを返します。他のコンテキストとの違いは、たとえば、アクティビティが終了すると、Androidによってアクティビティコンテキストが破棄される（または利用できなくなる）可能性があることです。アプリケーションコンテキストは、（特定のに関連付けられていない）アプリケーションオブジェクトが存在している間は常に使用可能なままなActivityので、これを使用して、より長期間、一時的なUIオブジェクトとは関係なく使用できるコンテキストを必要とする通知などに使用できます。
これらが同じであってもなくても、コードが何をしているかに依存すると思います-通常の使用では、それらは異なると思います。
Application であるContext（それはそれから継承）、および実行時に、両方の方法は、同じインスタンスを返します。違いは何ですか？
Activityコンテキストとコンテキストの違いを求めているのではありませんApplication。Application（グローバルで一意のアプリケーションコンテキストである）と、何getApplicationContextが返されるかの違いを考えています。後者は実際にはAndroid 1.6以前は機能していませんでした。以前は常に戻ってきましたnull。
コンテキストの折り返しと関係があるようです。から派生したほとんどのクラスContextは実際にはContextWrapperであり、本質的にはおそらくラッパーによる変更を伴う別のコンテキストに委譲されます。
コンテキストは、モックとプロキシをサポートする一般的な抽象概念です。多くのコンテキストはのような寿命の限定されたオブジェクトにバインドActivityされているため、将来の通知への登録などの目的で、より寿命の長いコンテキストを取得する方法が必要です。それはによって達成されContext.getApplicationContext()ます。論理実装はグローバルApplicationオブジェクトを返すことですが、コンテキスト実装が適切なライフタイムを持つラッパーまたはプロキシを返すことを妨げるものはありません。
アクティビティとサービスは、より具体的にApplicationオブジェクトに関連付けられています。これの有用性は、派生クラスからカスタムクラスを作成してマニフェストに登録できることでありApplication、Activity.getApplication()Service.getApplication()その特定のタイプの特定のオブジェクトをに返すまたは返すことができることです。派生Applicationクラスにキャストして、何にでも使用できます。カスタム目的。
つまり、getApplication()はApplicationオブジェクトを返すことが保証されていますが、getApplicationContext()代わりにプロキシを返すことは自由です。
Applicationます。