検証結果 - mao-test-h/SeekableAesAssetBundle GitHub Wiki

簡単な検証結果を雑に纏める。

以下の要件で暗号化済みのAssetBundleをランタイム上で復号し、ロードまでに用いたメモリ使用量を計測。

  • 巨大なサイズ(4096x4096)の画像8枚を格納。ランタイム上ではこの8枚を全てロードする。
    • ※圧縮効率を落とすために1枚は敢えてノイズ画像にしてみたり。
  • 圧縮形式はLZ4(LZMAなんて無かった...)
    • AssetBundleのファイルサイズはオリジナルで大体100MBぐらい。暗号化後も同じく100MBぐらい。
  • AssetBumdleのロードに用いるAPIはLoadFromMemoryとLoadFromStreamのみ。
    • ※暗号化されているのでLoadFromFileは未使用。

読み込み前の状態

  • 【Used Total】 : 40.1 MB
    • Unity : 34.9 MB
    • Mono : 464.0 KB
  • 【Reserved Total】 : 89.6 MB
    • Unity : 82.3 MB
    • Mono : 0.6 MB

▼ LoadFromMemory

File.ReadAllBytesでメモリに全展開した後に復号を掛けている。 掛けたbyte[]をそのままLoadFromMemoryに投げてロード。

  • 読み込み後
    • 【Used Total】 : 0.77 GB
      • Unity : 157.7 MB
      • Mono : 112.0 MB
    • 【Reserved Total】 : 0.92 GB
      • Unity : 310.3 MB
      • Mono : 117.2 MB

▼ LoadFromStream

独自の暗号化用Streamを実装。 FireStreamで読み込んだバイナリをそのまま独自Streamに投げた上で、最終的なStreamをLoadFromStreamに渡している。

  • 読み込み後
    • 【Used Total】 : 0.52 GB
      • Unity : 19.3 MB
      • Mono : 0.7 MB
    • 【Reserved Total】 : 0.58 GB
      • Unity : 70.3 MB
      • Mono : 0.8 MB

▼ 気になる点

  • LoadFromStreamのマネージドヒープ(Mono)の使用量削減についてはある程度納得できるが...何故かネイティブメモリ(Unity)の使用量も大きく減っている。ひょっとしたらStream側はUnloadUnusedAssetsに相応する処理を呼び出してゴニョゴニョしていたりと最適化が掛かっているのかもしれないが...中で何をやっているのか...。