１、ディレクトリ内の画像ファイルのみ処理。
２、ディレクトリ内の子ディレクトリと画像ファイルの処理。
android OS4.2 実機テスト。
１は、Runnableに画像ファイルのリストと作業用ディレクトリを渡し、別スレッドで画像変換保存を実行。
RecyclerViewで十分なスクロール速度が出せた。作業用ディレクトリ内を毎回、ファイルの全てを削除しているがストレスを感じるほどの遅延はない。
２は、１と同じ方法と、前回の処理内容にディレクトリに張り付けるサムネイル画像を作業用ディレクトリとは別の場所に、アプリでは消さないキャッシュ保存を付け加えた。（システムで消される可能性あり）ディレクトリ用のアイコン画像は消さずに再利用させる。実機テストでは、ディレクトリ用アイコン画像の保存が有ると無しではかなりの差があった。内部に数十のディレクトリの存在だと流石にね^^;
例えば、現在のディレクトリに画像の入ってる子ディレクトリがたくさんある。その中の１つの子ディレクトリに入り、元の場所に戻ってきたときに、入る前に見ていたディレクトリ達のアイコン画像は保存されているので、読み込むだけですぐに表示ができる。これが保存されていなければ、また１から作って表示となるので、その分のモタツキが気になる。
画像ファイルと違ってディレクトリ数は少なめだから保存し続けても問題は少ないだろう。
内容の画像が変わった時にアイコン画像は変わらないので別途のアイコン画像の更新機能は必要かな・・。
あと気になるところは、ディレクトリの取得した情報の使い回しとか。
バックグラウンドでディレクトリの情報収集ができたりするといいんだが・・・。
処理の流れ、
１、ディレクトリの子ディレクトリ、画像ファイル、情報取得と管理。（Fileが使いやすい。保存はString かな）
２、名前をソート。
３、画像だけなら、画像ファイルネームリスト使用。混在なら、別の配列にディレクトリを積み、次にファイルを積み配列１本にまとめる。同時に識別配列に識別子を本体と関連させて入れていく。配列２本作成。
４、RecyclerViewのアダプターにファイル名配列とキャッシュディレクトリを渡す。（ 関数addAll() にて ）
５、渡したときにスレッドに使うRunnableにもそれらの情報を渡して、スレッドを実行。
６、アダプターのonBindViewHolder()で画像、文字、タッチ処理を設定。キャッシュディレクトリ、ファイル名から、あるルールで保存されているキャッシュファイルの存在を確かめて、存在すれば読み込む。無ければ用意したリソースの画像を使うなど。
アダプターではキャッシュが有るか無いかの判断だけで良いと思う。スレッドで画像処理し、キャッシュに保存して、そのポジションをアダプターに通知する。アダプターは受け取った更新通知からもう一度そのポジションだけをonBindViewHolder()で再描画している？はず。分担できるくくりで分けた方が簡単みたい。
スレッド処理。
５－１、受け取った情報の確認。
５－２、作業用ディレクトリのファイルを全て削除。
５－３、リストから入力側ファイルと出力側ファイルを構築確認。
５－４、出力ファイルが出力場所に存在するか確認。存在すれば次のリストアイテムへ。
５－５、入力側ファイルからbitmapを作成、画像サイズを調整。
５－６、bitmapを保存ファイルに出力。
５－７、アダプターへ更新通知。（新規保存したものについて通知）
「５－３」～「５－７」をリスト数分繰り返す。
最初はごてごてしてぐちゃぐちゃになっていたけど、試行錯誤してスッキリした形になった。
分かりやすく他のものにも応用できそう。無駄を省いて効率を上げられたらもっと速くなるかな。