私のアプリの特定のアクティビティを開始すると、ユーザーは続行するためにいくつかのデータを入力する必要があるダイアログで「歓迎」されます。次に、アクティビティ自体で、ユーザーは2つのボタンを使用して、無限の数のフィールド（複数のビューで構成される）を動的に作成および削除できます。
ご存知のように、画面の向きが変わると、アクティビティが再開されるため、すべての情報が失われます。明らかに、これは問題になる可能性があります。
画面の向きを処理するために、Androidのドキュメントでは開発者にonRetainNonConfigurationInstance（）を使用するようにアドバイスしています。唯一の問題は、これを使用してコンテキスト内のオブジェクトを保存すると、関連付けられているすべてのビューがリークすることです。私の場合、これはさらに問題があります。なぜなら、そのアクティビティのデータは本質的にそのビューに関連付けられており、ビューはそのコンテキストに関連付けられているからです。
Androidのドキュメントでは、開発者が構成の変更を自分で処理することを推奨していません。彼らは、「一般的に、後で彼らの生活を複雑にするだけの短期的な解決策」と述べています（そして私は引用します）
たとえば、hasBeenShownブール値を作成してtrueに設定するなど、最初のダイアログを簡単にバイパスできます。メタデータを保存することで、「動的に作成されたビュー」の問題を回避することもできます。この場合、生成されたフィールドの数、タイプ、相互の相対位置、テキストまたは選択などです。バグがありますが、深刻なことは何もありません）。
ただし、フィールド（ビュー）はlayoutInflateを使用して動的に生成されるため（したがって、ビューの数は無限になります）、画面の向きを変更した後に同じフィールドを再生成すると、エミュレーターでもアプリケーションが非常に遅くなります。実際のデバイス（Samsung Galaxy S）に20フィールド（約120ビュー）がある場合、完了するまでに約1分かかりました。
不思議なことに、ビューを直接渡したとき（つまり、すべてのものがリークしたとき）、SamsumgGalaxySが完了するまでに10秒もかかりませんでした。
この情報から、あなたはそれが最善のアプローチだと思いますか？
（1）-フィールドをリセットしますか？（実際にはオプションではありません。誤って画面を傾けると、誰もが腹を立てるでしょう= P）
（2）-Androidが画面の向きの変更を処理している間にロード画面を追加しますか？
（3）-ブロック画面の向きの変更
（4）-画面の向きの変更を自分で処理し、DoomAndroidのドキュメントで話題になっているものが決して来ないことを願っています。
PS：少しオフトピックですが、私のアクティビティが終了すると、すべてのメモリが解放されますか？