Android写真キャッシュ原理、特性比較
これはMDCで共有した内容です。ソース解析の第一期発表の時に紹介したソース解析の後でゆっくりすることです。
全体の設計と原理からいくつかの写真キャッシュを比較して、彼らを使っていない友達も彼らのいくつかの特性上の実現を知ることができます。
一.四大画像キャッシュ基本情報
Universal ImageLoaderは、初期には多くのアプリケーションによって使用されています。
Picassoはスクウェアソースのプロジェクトであり、彼の主導者はJakeWharnであることから広く知られています。
GlideはGoogle社員のオープンソースプロジェクトで、Google Appに使われています。去年のGoogle I/Oで紹介されましたが、国内の資料は多くありません。
FreescoはFacebookが今年上半期にオープンした写真キャッシュです。
（1）二つのメモリキャッシュにNativeキャッシュを加えて三段キャッシュを構成しています。
（2）ストリーミング対応で、ウェブページのぼかした漸進的な表示画像と似ています。
（3）Gif、WebPなど、複数フレームの動画像のサポートがより良いです。
Freescoはまだ正式な1.0バージョンを発表していません。同時にFreescoのソースコードをよく知っている時間があまりないです。後はFreescoを含まないです。後で時間があれば、比較に参加します。
より多くの画像キャッシュが表示されます。Android画像キャッシュライブラリ
二、基本概念
正式に対比する前に、いくつかのピクチャキャッシュ共通の概念を理解する：
（1）Request Manager：モジュールの生成と管理をお願いします。
（2）Engine：エンジン部分は、タスクの作成（データの取得）を行い、スケジュール実行を行います。
（3）GetData Interface：データ取得インターフェースは、各データソースからデータの取得を担当しています。
メモリキャッシュからデータを取得し、DiskCacheはローカルキャッシュからデータを取得し、ダウンロード器はネットワークからデータを取得する。
（4）Displayer：リソース（ピクチャ）ディスプレイは、リソースを表示または操作するために使用されます。
例えばImageViewのように、これらのピクチャキャッシュはすべてImageViewだけではなく、他のViewおよび仮想Displayer概念をサポートしています。
（5）Processorリソース（写真）プロセッサ
資源の処理を担当します。例えば、回転、圧縮、切り取りなどです。
上記の概念の呼称は、異なるピクチャキャッシュにおいて異なることがあります。例えば、DisplayerはImageLoaderの中でImageAwareと呼ばれ、PicassoとGlideの中でTargetと呼ばれます。
三、共通の長所
1.使いやすい
一つのコードで画像の取得と表示が可能です。
2.配置可能度が高く、適応度が高い
画像キャッシュのダウンロード装置（再試行機構）、デコーダ、ディスプレイ、プロセッサ、メモリキャッシュ、ローカルキャッシュ、スレッドプール、キャッシュアルゴリズムなどは、大部分が簡単に構成できる。
適応度が高く、システム性能に応じてキャッシュ設定を初期化し、システム情報を変更した後に動的にポリシーを調整する。
例えばCPUコア数に応じて最大マージ数を決定し、利用可能メモリに応じてメモリのキャッシュサイズを決定し、ネットワークの状態が変化した場合に最大マージン数を調整するなどです。
3.多段キャッシュ
いずれも少なくとも2段階のキャッシュがあり、画像のロード速度を向上させます。
4.複数のデータソースに対応
複数のデータソース、ネットワーク、ローカル、リソース、Asetsなどをサポートします。
5.複数のDisplayerをサポートします。
ImageViewだけでなく、他のViewや仮想Displayer概念もサポートします。
他の小さな共通点は、動画サポート、トランスフォーム処理サポート、EXIF情報取得などです。
四、ImageLoaderの設計と長所
1.全体の設計と流れ
上はImageLoaderの全体設計図です。全体のライブラリはImageLoader Enggine、CacheおよびImageDown loader、ImageDecoder、BitmapDisplayer、BitmapProcessorの5つのモジュールに分けられています。ここでCacheはMemoryCacheとDiscerの2つの部分に分けられます。
簡単に言えば、ImageLoaderは画像をロードして表示するジョブを受け取って、ImageLoader Enggineに渡して、ImageLoader Enggineはタスクを配布して具体的なスレッド池に行って実行します。タスクはCacheとImageDownloaderを通じて画像を取得します。中間はBitmapProcessorとImagededer処理を経ます。最終的にBitmapに変換してBitmapDisplayerに渡してImageAwareに表示します。
2.ImageLoaderのメリット
（1）ダウンロードの進捗監査をサポートします。
(2)Viewスクロール中に画像の読み込みを一時停止することができます。
PauseOnScrrollListenerインターフェースにより、Viewスクロール中に画像のロードを一時停止することができます。
（3）デフォルトでは複数のメモリキャッシュアルゴリズムを実現します。 これらのピクチャキャッシュはいずれもキャッシュアルゴリズムを設定することができますが、ImageLoaderはデフォルトでは、Sizeが最大で最初に削除し、最小で最初に削除し、最近は少なくとも使用し、先に削除し、時間が一番長い場合は削除します。
(4)ローカルキャッシュファイル名規則の定義をサポートします。
五、Picassoデザインと長所
1.全体の設計と流れ
上はPicassoの全体設計図です。ライブラリ全体はDisplatch、Request Handler及びDownloader、PicassoDrawableなどのモジュールに分けられます。
DisplatchはActionの配信と処理を担当し、提出、一時停止、継続、キャンセル、ネットワーク状態の変化、再試行などを含む。
簡単に言えば、Picassoは画像をロードして表示するジョブを受け取り、Requestを作成してDispactchに渡し、Disparはタスクを具体的なRequest Handlerに配布し、タスクはMemoryCache及びHandlerを通じて画像を取得し、写真取得が成功したらPicassoDrawableを通じてTargetに表示します。
注意したいのは、上のDataのFile system部分で、Picassoはカスタムローカルキャッシュのインターフェースがなく、デフォルトはhttpのローカルキャッシュを使用し、API 9以上はhttpを使用し、以下はUrlconnectionを使用するので、カスタムローカルキャッシュが必要であれば、Downloaderを再定義する必要がある。
2.ピカソのメリット
（1）統計モニタ機能を持参する
画像キャッシュで使用されるモニタをサポートします。キャッシュの命中率、使用済みメモリのサイズ、節約された流量などが含まれます。
(2)優先度処理対応
各タスクスケジュールの前に優先度の高いタスクを選択します。例えば、AppページではBannerの優先度がIconより高い場合に適用されます。
（3）画像サイズ計算までの遅延に対応しています。ロードが完了しました。
（4）フライトモード対応、スレッド数はネットワークタイプによって変わります。
携帯電話を飛行モードやネットワークタイプに切り替えると、自動的にスレッド池の最大合併数が調整されます。例えば、wifiの最大合併は4、4 gは3、3 gは2です。
ここでPicassoは、CPUコアの数ではなく、ネットワークタイプによって最大の合併数を決定します。
（5）「なし」ローカルキャッシュ
ローカルキャッシュがないということは、ローカルキャッシュがないということではなく、Picasso自身が実現していないということで、スクウェアのもう一つのネットワークライブラリok httpに任せて実現したという利点は、Resonse HeaderのCache-ControlおよびExpiredに画像の期限切れを要求することによって実現できる。
六、Glideの設計と長所
1.全体の設計と流れ
上はGlideの全体設計図です。全体のライブラリはRequest Manager（要求マネージャ）、Enggine（データ取得エンジン）、Fetch（データ取得器）、MemoryCache（メモリキャッシュ）、DisLRUCache、Transformation（ピクチャ処理）、Encerder（ローカルキャッシュメモリ）、Registry（ピクチャタイプおよび解像器配置）、Target（ターゲットモジュール）などに分類されます。
簡単に言えば、Glideはリソースをロードして表示するジョブを受け取り、Requestを作成してRequest Managerに渡し、RequestはEngineを起動してデータソースに行ってリソースを取得します。
GlideはDiskLRUCache、GifDecoderなどのオープンソースライブラリに依存してローカルキャッシュとGifピクチャの復号作業を完了します。
2.Glideのメリット
（1）画像キャッシュ->メディアキャッシュ
Glideは単なるピクチャーキャッシュではなく、Gif、WebP、サムネイルをサポートしています。ビデオでさえ、メディアキャッシュとして扱われるべきです。
(2)優先度処理対応
（3）Activity/Fragmentライフサイクルと一致し、trimMemoryをサポートします。
Glideは各contextに対してRequest Managerを保持しています。FrangentTransationを通じてActivity/Fragmentライフサイクルと一致しています。対応するtrimMemoryインターフェースがあります。呼び出しが可能です。
（4）okhttp、Volly対応
Glideのデフォルトは、UrlConnectionでデータを取得し、ok httpやVollyに合わせて使用することができます。実際にImageLoader、Picassoもok http、Vollyをサポートしています。
（5）メモリ友好
①Glideのメモリキャッシュにactiveのデザインがあります。
メモリキャッシュからデータを取るときは、一般的な実装用getではなく、Removeでこのキャッシュデータをソフト参照のactiveResource mapに入れて、参照数をカウントし、ピクチャローディング完了後に判断します。参照カウントが空であれば回収します。
②メモリキャッシュより小さい画像
Glide以url、viewwidth、viewheight、画面の解像度などを連携keyとして、処理後の画像をメモリキャッシュにキャッシュし、元の画像ではなくサイズを節約する。
③Activity/Fragmentライフサイクルと一致し、trimMemory対応
④画像はデフォルトではRGB_を使用します。565はARGB_ではありません888
解像度が悪いですが、画像はもっと小さいです。ARGB_にも配置できます。888です。
その他：Glideはsignatureを通じて、またはローカルキャッシュを使用しないで、サポートurlを期限切れにすることができます。
七、まとめ
三者全体として、ImageLoaderの機能及び代理が理解しやすい長さは一般的である。
Picassoコードは一つのカバンの下にしかありませんが、厳密な区分はありません。しかし、コードは簡単で、論理がはっきりしています。一、二時間で深い理解ができます。
Glideは機能が強いですが、コード量が多くて、流れが複雑です。問題が起きてから手がつけにくいように、深く把握した上で使うことを勧めます。
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。
全体の設計と原理からいくつかの写真キャッシュを比較して、彼らを使っていない友達も彼らのいくつかの特性上の実現を知ることができます。
一.四大画像キャッシュ基本情報
Universal ImageLoaderは、初期には多くのアプリケーションによって使用されています。
Picassoはスクウェアソースのプロジェクトであり、彼の主導者はJakeWharnであることから広く知られています。
GlideはGoogle社員のオープンソースプロジェクトで、Google Appに使われています。去年のGoogle I/Oで紹介されましたが、国内の資料は多くありません。
FreescoはFacebookが今年上半期にオープンした写真キャッシュです。
（1）二つのメモリキャッシュにNativeキャッシュを加えて三段キャッシュを構成しています。
（2）ストリーミング対応で、ウェブページのぼかした漸進的な表示画像と似ています。
（3）Gif、WebPなど、複数フレームの動画像のサポートがより良いです。
Freescoはまだ正式な1.0バージョンを発表していません。同時にFreescoのソースコードをよく知っている時間があまりないです。後はFreescoを含まないです。後で時間があれば、比較に参加します。
より多くの画像キャッシュが表示されます。Android画像キャッシュライブラリ
二、基本概念
正式に対比する前に、いくつかのピクチャキャッシュ共通の概念を理解する：
（1）Request Manager：モジュールの生成と管理をお願いします。
（2）Engine：エンジン部分は、タスクの作成（データの取得）を行い、スケジュール実行を行います。
（3）GetData Interface：データ取得インターフェースは、各データソースからデータの取得を担当しています。
メモリキャッシュからデータを取得し、DiskCacheはローカルキャッシュからデータを取得し、ダウンロード器はネットワークからデータを取得する。
（4）Displayer：リソース（ピクチャ）ディスプレイは、リソースを表示または操作するために使用されます。
例えばImageViewのように、これらのピクチャキャッシュはすべてImageViewだけではなく、他のViewおよび仮想Displayer概念をサポートしています。
（5）Processorリソース（写真）プロセッサ
資源の処理を担当します。例えば、回転、圧縮、切り取りなどです。
上記の概念の呼称は、異なるピクチャキャッシュにおいて異なることがあります。例えば、DisplayerはImageLoaderの中でImageAwareと呼ばれ、PicassoとGlideの中でTargetと呼ばれます。
三、共通の長所
1.使いやすい
一つのコードで画像の取得と表示が可能です。
2.配置可能度が高く、適応度が高い
画像キャッシュのダウンロード装置（再試行機構）、デコーダ、ディスプレイ、プロセッサ、メモリキャッシュ、ローカルキャッシュ、スレッドプール、キャッシュアルゴリズムなどは、大部分が簡単に構成できる。
適応度が高く、システム性能に応じてキャッシュ設定を初期化し、システム情報を変更した後に動的にポリシーを調整する。
例えばCPUコア数に応じて最大マージ数を決定し、利用可能メモリに応じてメモリのキャッシュサイズを決定し、ネットワークの状態が変化した場合に最大マージン数を調整するなどです。
3.多段キャッシュ
いずれも少なくとも2段階のキャッシュがあり、画像のロード速度を向上させます。
4.複数のデータソースに対応
複数のデータソース、ネットワーク、ローカル、リソース、Asetsなどをサポートします。
5.複数のDisplayerをサポートします。
ImageViewだけでなく、他のViewや仮想Displayer概念もサポートします。
他の小さな共通点は、動画サポート、トランスフォーム処理サポート、EXIF情報取得などです。
四、ImageLoaderの設計と長所
1.全体の設計と流れ
上はImageLoaderの全体設計図です。全体のライブラリはImageLoader Enggine、CacheおよびImageDown loader、ImageDecoder、BitmapDisplayer、BitmapProcessorの5つのモジュールに分けられています。ここでCacheはMemoryCacheとDiscerの2つの部分に分けられます。
簡単に言えば、ImageLoaderは画像をロードして表示するジョブを受け取って、ImageLoader Enggineに渡して、ImageLoader Enggineはタスクを配布して具体的なスレッド池に行って実行します。タスクはCacheとImageDownloaderを通じて画像を取得します。中間はBitmapProcessorとImagededer処理を経ます。最終的にBitmapに変換してBitmapDisplayerに渡してImageAwareに表示します。
2.ImageLoaderのメリット
（1）ダウンロードの進捗監査をサポートします。
(2)Viewスクロール中に画像の読み込みを一時停止することができます。
PauseOnScrrollListenerインターフェースにより、Viewスクロール中に画像のロードを一時停止することができます。
（3）デフォルトでは複数のメモリキャッシュアルゴリズムを実現します。 これらのピクチャキャッシュはいずれもキャッシュアルゴリズムを設定することができますが、ImageLoaderはデフォルトでは、Sizeが最大で最初に削除し、最小で最初に削除し、最近は少なくとも使用し、先に削除し、時間が一番長い場合は削除します。
(4)ローカルキャッシュファイル名規則の定義をサポートします。
五、Picassoデザインと長所
1.全体の設計と流れ
上はPicassoの全体設計図です。ライブラリ全体はDisplatch、Request Handler及びDownloader、PicassoDrawableなどのモジュールに分けられます。
DisplatchはActionの配信と処理を担当し、提出、一時停止、継続、キャンセル、ネットワーク状態の変化、再試行などを含む。
簡単に言えば、Picassoは画像をロードして表示するジョブを受け取り、Requestを作成してDispactchに渡し、Disparはタスクを具体的なRequest Handlerに配布し、タスクはMemoryCache及びHandlerを通じて画像を取得し、写真取得が成功したらPicassoDrawableを通じてTargetに表示します。
注意したいのは、上のDataのFile system部分で、Picassoはカスタムローカルキャッシュのインターフェースがなく、デフォルトはhttpのローカルキャッシュを使用し、API 9以上はhttpを使用し、以下はUrlconnectionを使用するので、カスタムローカルキャッシュが必要であれば、Downloaderを再定義する必要がある。
2.ピカソのメリット
（1）統計モニタ機能を持参する
画像キャッシュで使用されるモニタをサポートします。キャッシュの命中率、使用済みメモリのサイズ、節約された流量などが含まれます。
(2)優先度処理対応
各タスクスケジュールの前に優先度の高いタスクを選択します。例えば、AppページではBannerの優先度がIconより高い場合に適用されます。
（3）画像サイズ計算までの遅延に対応しています。ロードが完了しました。
（4）フライトモード対応、スレッド数はネットワークタイプによって変わります。
携帯電話を飛行モードやネットワークタイプに切り替えると、自動的にスレッド池の最大合併数が調整されます。例えば、wifiの最大合併は4、4 gは3、3 gは2です。
ここでPicassoは、CPUコアの数ではなく、ネットワークタイプによって最大の合併数を決定します。
（5）「なし」ローカルキャッシュ
ローカルキャッシュがないということは、ローカルキャッシュがないということではなく、Picasso自身が実現していないということで、スクウェアのもう一つのネットワークライブラリok httpに任せて実現したという利点は、Resonse HeaderのCache-ControlおよびExpiredに画像の期限切れを要求することによって実現できる。
六、Glideの設計と長所
1.全体の設計と流れ
上はGlideの全体設計図です。全体のライブラリはRequest Manager（要求マネージャ）、Enggine（データ取得エンジン）、Fetch（データ取得器）、MemoryCache（メモリキャッシュ）、DisLRUCache、Transformation（ピクチャ処理）、Encerder（ローカルキャッシュメモリ）、Registry（ピクチャタイプおよび解像器配置）、Target（ターゲットモジュール）などに分類されます。
簡単に言えば、Glideはリソースをロードして表示するジョブを受け取り、Requestを作成してRequest Managerに渡し、RequestはEngineを起動してデータソースに行ってリソースを取得します。
GlideはDiskLRUCache、GifDecoderなどのオープンソースライブラリに依存してローカルキャッシュとGifピクチャの復号作業を完了します。
2.Glideのメリット
（1）画像キャッシュ->メディアキャッシュ
Glideは単なるピクチャーキャッシュではなく、Gif、WebP、サムネイルをサポートしています。ビデオでさえ、メディアキャッシュとして扱われるべきです。
(2)優先度処理対応
（3）Activity/Fragmentライフサイクルと一致し、trimMemoryをサポートします。
Glideは各contextに対してRequest Managerを保持しています。FrangentTransationを通じてActivity/Fragmentライフサイクルと一致しています。対応するtrimMemoryインターフェースがあります。呼び出しが可能です。
（4）okhttp、Volly対応
Glideのデフォルトは、UrlConnectionでデータを取得し、ok httpやVollyに合わせて使用することができます。実際にImageLoader、Picassoもok http、Vollyをサポートしています。
（5）メモリ友好
①Glideのメモリキャッシュにactiveのデザインがあります。
メモリキャッシュからデータを取るときは、一般的な実装用getではなく、Removeでこのキャッシュデータをソフト参照のactiveResource mapに入れて、参照数をカウントし、ピクチャローディング完了後に判断します。参照カウントが空であれば回収します。
②メモリキャッシュより小さい画像
Glide以url、viewwidth、viewheight、画面の解像度などを連携keyとして、処理後の画像をメモリキャッシュにキャッシュし、元の画像ではなくサイズを節約する。
③Activity/Fragmentライフサイクルと一致し、trimMemory対応
④画像はデフォルトではRGB_を使用します。565はARGB_ではありません888
解像度が悪いですが、画像はもっと小さいです。ARGB_にも配置できます。888です。
その他：Glideはsignatureを通じて、またはローカルキャッシュを使用しないで、サポートurlを期限切れにすることができます。
七、まとめ
三者全体として、ImageLoaderの機能及び代理が理解しやすい長さは一般的である。
Picassoコードは一つのカバンの下にしかありませんが、厳密な区分はありません。しかし、コードは簡単で、論理がはっきりしています。一、二時間で深い理解ができます。
Glideは機能が強いですが、コード量が多くて、流れが複雑です。問題が起きてから手がつけにくいように、深く把握した上で使うことを勧めます。
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。