常にandroid：configChanges =“ keyboardHidden | orientation”を使用しないのはなぜですか？

なぜandroid:configChanges="keyboardHidden|orientation"すべての（ほぼすべての;））アクティビティで使用しないのか疑問に思っていましたか ？

品：

• あなたの活動がローテーションされることを心配する必要はありません
• 速いです

あまり良くない：

• 画面サイズに依存している場合は、レイアウトを変更する必要があります（例：2列のレイアウトなど）

悪い：

• さまざまな向きでさまざまなレイアウトを作成するための柔軟な方法がない
• フラグメントを使用するとあまり良くない

しかし、異なるレイアウトを使用しないのであれば、なぜでしょうか？

簡単な背景

デフォルトでは、Androidで特定の主要な構成変更が発生すると（一般的な例は方向の変更です）、Androidは実行中のアクティビティを完全に再起動して、そのような変更に適応できるようにします。

android:configChanges="keyboardHidden|orientation"AndroidManifestで定義するときは、Androidに次のように伝えます。「キーボードが引き出されたとき、または電話が回転したときにデフォルトのリセットを行わないでください。これを自分で処理したいのです。そうです。 」

これは良いことですか？すぐに...

心配ない？

あなたが最初に始める長所の1つは、

あなたの活動がローテーションされることを心配する必要はありません

多くの場合、向きの変更（「回転」）によって生成されるエラーがある場合、を挿入するだけで簡単に修正できると誤って信じていますandroid:configChanges="keyboardHidden|orientation"。

ただし、android：configChanges = "keyboardHidden | orientation"は、絆創膏にすぎません。実際には、構成の変更をトリガーする方法はたくさんあります。たとえば、ユーザーが新しい言語を選択した場合（つまり、ロケールが変更された場合）、方向の変更と同じ方法でアクティビティが再開されます。必要に応じて、すべての異なるタイプの構成変更のリストを表示できます。

編集：さらに重要なことに、ハックボッドがコメントで指摘しているように、アプリがバックグラウンドにあり、Androidがメモリを解放してメモリを解放することを決定した場合にも、アクティビティが再開されます。ユーザーがアプリに戻ると、Androidは他の構成変更があった場合と同じようにアクティビティを再開しようとします。それを処理できない場合-ユーザーは満足できません...

つまり、android:configChanges="keyboardHidden|orientation"「心配」の解決策にはなりません。適切な方法は、Androidがスローする再起動に満足できるようにアクティビティをコーディングすることです。これは、道を進むときに役立つ良い習慣なので、慣れます。

それで、いつそれを使うべきですか？

あなたが述べたように、明確な利点があります。ローテーションのデフォルトの構成変更を自分で処理して上書きすると、処理が速くなります。ただし、この速度には利便性の代償が伴います。

簡単に言うと、縦長と横長の両方に同じレイアウトを使用している場合は、上書きを行うことで適切な状態になります。アクティビティを本格的にリロードする代わりに、ビューは単純にシフトして残りのスペースを埋めます。

ただし、デバイスが横向きのときに何らかの理由で別のレイアウトを使用する場合、Androidがアクティビティをリロードすると、正しいレイアウトが読み込まれるので問題ありません。[そのようなアクティビティでオーバーライドを使用し、実行時に魔法のような再レイアウトを実行したい場合...まあ、幸運-それは単純ではありません]

簡単なまとめ

ぜひ、android:configChanges="keyboardHidden|orientation"あなたに合っているなら、それを使ってください。しかしPLEASE姿勢の変化がフル活動再開をトリガすることができる唯一の方法ではありませんので、ときに何かが変化し、何が起こるかテストしてください。

私の観点から：レイアウトが横長モードと縦長モードの両方で同じである場合、アプリで2つのうち1つを無効にすることもできます。

私がこれを述べた理由は、ユーザーとして、私が向きを変更したときに、アプリが私にいくつかの利益を提供することを期待しているからです。スマートフォンの持ち方が問題にならないのであれば、選択肢は必要ありません。

たとえば、ListViewがあり、ListItemをクリックすると、そのアイテムの詳細ビューが表示されるようにするアプリを例にとります。横向きの場合は、画面を2つに分割して、左側にListView、右側に詳細ビューを表示します。Portraitでは、1つの画面にリストが表示され、ListItemが選択されたときに画面が詳細ビューに変更されます。その場合、向きの変更は、さまざまなレイアウトと同様に理にかなっています。

理由はわかりません。..たまに再起動しても大丈夫です... configChangesがほとんどの場合を処理してくれます...たぶんいくつかのタイプのアプリケーションではこれは問題になるかもしれませんが、それは本当にアプリケーションのタイプとどのように復元するかに依存しますアプリの再起動時の状態...アプリのいずれかが再起動すると、ユーザーがログバックされ、最後のアクティビティがコードによって開かれ、ユーザーjusは以前の場所に戻るためのいくつかの手順を失いますが、大したことではありません。他の一部の状態は常に持続し、一部の状態は、再起動時に常に復元されます。アクティビティが再開されたときは、そのアプリが使用されていないか何かである必要がありました...まったく問題ありません...たとえば、ゲームでは、これはおそらく問題になるか、他の種類のアプリではわかりません...

このようにすると、アプリケーションは通常の状況で正常に機能するようになります。そして、コードははるかに読みやすくなり、新しいバグを作成し、常にそれを維持する必要がある場所を保存および復元するために必要な大量のロジックがありません... Androidが電力を失い、アプリケーションウィンドウを強制終了すると、コンテキストが失われ、再び始まりますが、これは特別な状況でのみ発生し、新しいデバイスではこれがますます珍しくなります...

だから私を殺してください、しかし私はこれをアプリケーション全体でかなりうまく使います... android：configChanges = "locale | keyboard | keyboardHidden | orientation | screenLayout | uiMode | screenSize | smallestScreenSize"しかし、いくつかの特別な種類のアプリケーションでは、良い方法ですが、ほとんどのアプリはこれで十分です。

一時停止すると、プレーヤーを解放するよりも速くなると思います。それでも一時停止します。

曲を一時停止しない解決策を見つけました。

画面の向きの構成変更を処理し、onConfigurationChangedメソッドを使用してレイアウトファイルを読み込むことをマニフェストに記述します。logCatでこれを実行すると、onPause、onCreate、onResumeが呼び出されないため、曲が一時停止されないことがわかります。

1. マニフェストを更新して向きを処理します。

   android:configChanges="orientation|screenSize"

2. このコードを追加

   @Override
   public void onConfigurationChanged(Configuration newConfig) {
       // TODO Auto-generated method stub      
       super.onConfigurationChanged(newConfig);        
       setContentView(R.layout.activity_main);
   }