Caching.IsVersionCached(url, hash) ってどういう挙動？

概要

Caching.IsVersionCached(url, hash) の挙動がよくわからない。

ドキュメントにも書いてないし。

でも実装はされてて、Unity5.5p4とかだと使える。(もっと前から使える。)

で、この関数のどんな挙動が悩ましいのか、書いていく。

hashを使ったAssetBundleのDLについて

5.x系だと、こんな感じのメソッドを使ってAssetBundleをDLできるようになってる。

public static Networking.UnityWebRequest GetAssetBundle(string uri, Hash128 hash, uint crc);

ドキュメントはこれ。

とあるurlに紐づいてDLされているAssetBundleについて、このメソッドに渡したhash値がDL時のhash値と一致しなかったら、DLが発生する。

そうでない場合はAssetBundleがストレージにキャッシュされてるので、そこから取得する、みたいな。

で、だ。この関数には良いところがいっぱいあって。

・キャッシュに含まれていたら + hashが合致していたら、AssetBundleが取得できる

・キャッシュに含まれていなかったらAssetBundleをDL、取得できる

・キャッシュに含まれていなかったらAssetBundleをDL、キャッシュもする

・キャッシュに含まれていたら + hash合致しなかったら、やはり取得しに行く

・キャッシュに含まれていたら + hash合致しなかった場合、古いファイルは消える(消えますよね？消えますよね？？明文化されてない気がするけど！！

・crcで正しいファイルかチェックできる

などなど。hashが本当にいい仕事してる。versionのようなヘタレとは違うのだ。違うのだ。

で、次は、「AssetBundleむかしDLした気がするんだけど、このAssetBundleってあるんですか？」って確認したいだけの場合。

まあ、、、この機会を「実際に使用しないならいいじゃん！実際に使用するときはRequest使えばいいじゃん！」みたいな話で没シュートしたい場合、

かつ、そのためCaching.IsVersionCached(url, hash)がドキュメントに書いてないという事情な場合、話はシンプルにまとまりそう。

hashを使ったAssetBundleがキャッシュされているかどうかのチェックについて

本題。

ざっくりいうと、hashを使ったIsVersionCheckedは、どんなhashを渡してもtrueが返ってくるときがあるようだ。

サンプルを用意した。