Bouncycastle AES 256 JITのためにマルチスレッドの復号速度が低下する

Question

私は写真を暗号化するアプリケーションを作成していますが、アクティベーションのようにギャラリーのサムネイルを復号化して表示する必要があります。もちろん、あなたはクリックして、さまざまな活動でフルサイズの画像を見ることができます。 私はAES/CBC/PKCS7Padding暗号を256ビット鍵で使用しています。私はPBEWithSHA256And256BitAES-CBC-BCを使用して暗号鍵を導き出し、それをメモリに格納する。その後、暗号化/復号化を行う必要があるすべてのスレッドは、その鍵を使ってCipherオブジェクトを初期化するメモリからそのキーを使用しています。

ここに私の問題があります。私は多くの画像を同時に解読すると（ギャラリーを表示する必要があるとしよう）、フルサイズの画像を解読しようとすると、非常に遅いです。一方、もし私がちょうど1つのイメージを解読すれば（どんなサイズであろうと）、次にギャラリーに行き、フルサイズのイメージを解読するのは非常に高速です。

私は本当に混乱しています。

私は間違っていますか？たぶんBouncy Castle Cryptoライブラリはスレッドセーフではないでしょうか？

更新日：私はこの問題がJITに関連していることを知りました。 JITを無効にすると、処理速度の差が完全になくなります。誰もがコードを最適化して、マルチスレッドで写真を解読するときにJITを強制的にコンパイルするようにコードを最適化する方法を理解するのを助けることができますか？

Answer 1

上記の説明から分かるように、パフォーマンス低下の原因は、ワーカースレッドの数が多いことです。スレッド数を制限する1つの方法として、java.util.concurrentにあるクラスを使用して、固定（または上限）スレッドプールを使用する方法があります。

適切なExecutors静的ファクトリメソッドを使用して固定スレッドプール実行サービスを作成できます。次に、個々のサムネイルを解読し、返されたExecutorServiceインスタンスのsubmit()メソッドを使用してGridViewセルにデータを取り込む非同期タスクを作成できます。

もう1つの可能性は、新しいLoaders API（developer.android.com）かもしれませんが、わかりません。私は今自分の使い方について読んでいます。だから、ドキュメントをチェックしたいかもしれません。

さらに別の方法がthis answer（stackoverflow.com）にあります。