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