Androidの面接問題についてあなたのApplication類に対する理解について
実は何に対する理解を言って、あなたがこれに対して使うことができるかどうかを考察して、重点は何か穴があるかどうかです!
まず、Applicationは1つのDalvik仮想マシンに1つのインスタンスしか存在しないので、単例モードで静的にApplicationを取得するのではなく、Applicationコンストラクション関数をpriveteに設定しても実現できません.では、なぜアプリではなくDalvik仮想マシンだと強調したのでしょうか.
1つのAppに複数のDalvik仮想マシン、すなわち伝説のマルチプロセスモードがある可能性があるからです.このモードでは、Dalvikごとに1つのApplicationインスタンスが存在します.彼らの間には関係ありません.AプロセスApplicationに保存されているデータは、BプロセスのApplicationで取得できません.彼らはオブジェクトではなく、2つのプロセスに隔離されているので、ここでは、AppではなくDalvik仮想マシンであることを強調します.
次に、Applicationの本質はContextであり、ContextWrapperから継承されます.
ContextWrapperって何?Contextのパッケージです.
Applicationには2つのサブクラスがあります.1つはMultiDexApplicationです.「65535」の問題が発生した場合は、彼から継承し、マルチDexパッケージ構成に関する作業を完了することができます.
もう1つは、TDD(テストケースドライバ)開発モードでMokeを使用してテストを行う際に用いられるもので、ApplicationのMoke類MockApplicationに代わることができます.
アプリケーションが起動すると、まず
また、ContextではgetApplicationContext()でApplicationオブジェクトを取得したり、
PS:上記の3つの方法で取得したものはすべて同じApplicationオブジェクトであり、getApplicationContext()はContextの実装クラスContextImplで具体的に実装されているが、getApplication()はActivityとServiceで単独で実装されているため、彼らの役割ドメインは異なるが、取得したものはすべて同じApplicationオブジェクトであり、1つのDalvik仮想マシンに1つのApplicationオブジェクトしかないためである.
しかし、低メモリの場合、アプリケーションが破棄され、アプリケーションに保存されているデータ情報が失われ、プログラムが錯乱したり、Crashになったりする可能性があるというピットがあります.
アプリケーションでデータを保存したい場合は、空の判断をするか、他の方法でデータ情報を保存するかを選択してください.
また、Applicationには、onLowMemory()とonTrimMemory()のようないくつかの有用な方法が存在します.この2つの方法では、データベース接続を閉じたり、ピクチャメモリキャッシュを削除したりするなどの操作を実行してメモリ消費を低減し、システムによって回収されるリスクを低減することができます.
最後に、Dalvik仮想マシンのライフサイクルと同じ長さのApplicationのライフサイクルに注意するため、一例または静的変数の初期化操作を行う場合は、必ずApplicationをContextとして初期化する必要があります.そうしないとメモリ漏洩が発生します.Dialogを使用する場合はContextとしてActivityを使用するのが一般的ですが、コンテキストとしてApplicationを使用することもできます.WindowタイプをTYPE_に設定する必要があることを前提としています.SYSTEM_DIALOGは、関連権限を申請します.この時点でポップアップされたDialogはApplication全体に属しており、このDialogのActivity破棄をポップアップしてもDialogは回収されず、Application破棄時のみこのDialogは自動的に消滅する.
まず、Applicationは1つのDalvik仮想マシンに1つのインスタンスしか存在しないので、単例モードで静的にApplicationを取得するのではなく、Applicationコンストラクション関数をpriveteに設定しても実現できません.では、なぜアプリではなくDalvik仮想マシンだと強調したのでしょうか.
1つのAppに複数のDalvik仮想マシン、すなわち伝説のマルチプロセスモードがある可能性があるからです.このモードでは、Dalvikごとに1つのApplicationインスタンスが存在します.彼らの間には関係ありません.AプロセスApplicationに保存されているデータは、BプロセスのApplicationで取得できません.彼らはオブジェクトではなく、2つのプロセスに隔離されているので、ここでは、AppではなくDalvik仮想マシンであることを強調します.
次に、Applicationの本質はContextであり、ContextWrapperから継承されます.
android.content.Context
↳ android.content.ContextWrapper
↳ android.app.Application ContextWrapperって何?Contextのパッケージです.
Applicationには2つのサブクラスがあります.1つはMultiDexApplicationです.「65535」の問題が発生した場合は、彼から継承し、マルチDexパッケージ構成に関する作業を完了することができます.
もう1つは、TDD(テストケースドライバ)開発モードでMokeを使用してテストを行う際に用いられるもので、ApplicationのMoke類MockApplicationに代わることができます.
アプリケーションが起動すると、まず
Application.attach()が呼び出されます.もちろん、この方法は非表示です.開発者が接触できる最初の呼び出された方法は実はApplication.onCreate()です.私たちは通常、この方法の中で様々な初期化を完了します.例えば、ピクチャロードライブラリ、Httpライブラリのデフォルト構成の初期化操作などです.しかし、この方法では、Appの起動速度に影響を与えるため、不要な操作に対しては非同期操作、怠惰ロード、遅延ロードなどのポリシーを使用してUIスレッドへの影響を低減することができるため、時間のかかる操作を行わないほうがいい.また、ContextではgetApplicationContext()でApplicationオブジェクトを取得したり、
Activity.getApplication()、Service.getApplication()でApplicationを取得したりできるので、すべてのActivityまたはServiceで使用できるように、Applicationでグローバルなデータを保存できます.PS:上記の3つの方法で取得したものはすべて同じApplicationオブジェクトであり、getApplicationContext()はContextの実装クラスContextImplで具体的に実装されているが、getApplication()はActivityとServiceで単独で実装されているため、彼らの役割ドメインは異なるが、取得したものはすべて同じApplicationオブジェクトであり、1つのDalvik仮想マシンに1つのApplicationオブジェクトしかないためである.
しかし、低メモリの場合、アプリケーションが破棄され、アプリケーションに保存されているデータ情報が失われ、プログラムが錯乱したり、Crashになったりする可能性があるというピットがあります.
アプリケーションでデータを保存したい場合は、空の判断をするか、他の方法でデータ情報を保存するかを選択してください.
また、Applicationには、onLowMemory()とonTrimMemory()のようないくつかの有用な方法が存在します.この2つの方法では、データベース接続を閉じたり、ピクチャメモリキャッシュを削除したりするなどの操作を実行してメモリ消費を低減し、システムによって回収されるリスクを低減することができます.
最後に、Dalvik仮想マシンのライフサイクルと同じ長さのApplicationのライフサイクルに注意するため、一例または静的変数の初期化操作を行う場合は、必ずApplicationをContextとして初期化する必要があります.そうしないとメモリ漏洩が発生します.Dialogを使用する場合はContextとしてActivityを使用するのが一般的ですが、コンテキストとしてApplicationを使用することもできます.WindowタイプをTYPE_に設定する必要があることを前提としています.SYSTEM_DIALOGは、関連権限を申請します.この時点でポップアップされたDialogはApplication全体に属しており、このDialogのActivity破棄をポップアップしてもDialogは回収されず、Application破棄時のみこのDialogは自動的に消滅する.