現状、画像ビューワーはほぼ完成して安定して動くようになった。
KitKatでもメモリ不足の例外で止まらないように対処した。
ただ、別アクティビティやフラグメントも使わず、レイアウトの表示非表示で機能切り替えを行っているためにアプリ起動時間が長い。
起動時間が長い。はユーザーの不満の大きな要素である。
解消するには機能別にアクティビティか、フラグメントに分けて各初期化時間を分散する事。
メインアクティビティはスタート画像表示とメッセージのみで、画面やボタンをタップしたら本体へ移行するのが王道だろう。
プログレスサークルの導入も必要。
方法案：
１、mainActivity + subActivity(今までのレイアウト切り替えを使う)
２、mainActivity + 複数 subActivity(機能ごとに用意)
３、mainActivity + 複数フラグメント(機能ごとに切り替え)
考察：
１、
メリット：作り直す部分が少なく起動時間の不満解消に早い対応が可能。
デメリット：スタート画面以後のサブ初期化時間は長いまま。メモリ消費も変わらず融通もない。
２、
メリット：起動時間の短縮。アクティビティ毎にメモリ解放をシステムが管理。メモリ不足対応をシステム任せを期待。
デメリット：開発時間がかかる。アクティビティ毎のデータ共有の難しさ。最小データ通信。アクティビティ毎の廃棄処理。
３、
メリット：起動時間の短縮。フラグメント毎にメモリ解放をシステムが管理。メモリ不足対応をシステム任せを期待。
デメリット：開発時間がかかる。フラグメント毎のデータ共有の難しさ。最小データ通信。フラグメント毎の廃棄処理。
選択：
巨大なアプリでは無いし１番で様子を見たいところ。しかし、プログレスサークルが思ったように動作させられない。
２番３番は似たようなもの。onCreate()を分散するので各初期化時間は短くなる。
デバイスの違いに柔軟にデザインを対応させられるフラグメント使用が良いのかもしれない。
準備：
機能別フラグメント作成に当たり、データ処理の系統を確定する。
フラグメント間のデータ通信の種類や最小サイズを考える。
フラグメント破棄されることを考慮し、フラグメント再構築時の各種データ保存を考える。
プロファイルデータのアクセスを考える。種類による保存、読み出しの場所とタイミングを分ける。