渋谷ほととぎす通信

「Unityをわかりやすく」初心者のためのゲーム作りブログ

Unity アプリ容量を減らすための工夫

Unity アプリ容量を減らすための工夫

こんにちは、エンジニアのオオバです。

iPhoneアプリを開発してて困ることの1つに、
Wi-Fiを使わずにダウンロード可能アプリ容量制限があります。

100MB

この容量を超えるとアプリダウンロードがWi-Fi経由のみになるため、新規ユーザー数に大きな影響を与えます。


その日は突然やってきました。

「アプリの申請作業が終わったー!!!」

と思っていたら、、、 アップルから『100MB超えそうです』というメールが届きました。

この問題にぶつかった場合、非常に困るのは長く運用しているアプリです。
リリース当初では考えられていなかった、機能や仕組みが入っており、
それらに引きずられて組み込みのUIやエフェクト、SEなどがアプリ内に溜まっていきます。

売上目標によるスケジュール的なプレッシャーで、オンスケ重視。
それによって突貫作業。その作業内容が後任に引き継がれず、その人が突然プロジェクトを去ってしまう。

結果、開かずのソースが生まれてしまうことはよくある話です。

チームのベテランの誰かが言ってましたが、

「あのファイルは、決して開いてはいけないよ」と。


このようなプロジェクト状況は、全くもってNGなのですが長く運用していると起こりえます。

そして起こってしまったので、100MB以内にアプリサイズをどうやって減らしたかを説明していきます。

👉DOTweenの教科書を読んでUnityアニメーションをプログラミングしてみよう!

解決手段の模索

怪しいところは何点かありました。

  • Resourcesフォルダにゴミファイルが残っている
  • ダミーの画像を本番で参照しているところがある
  • スプラッシュ画像が豪華
  • サウンドファイルがアプリに内包されている
  • サウンドファイルの無音部分がある
  • 32bitフルカラーが必要でない画像がある
  • 2048☓2048のアトラス画像が大量にある
  • fbxが大量にアプリに内包されている
  • ゲームエフェクトデータがアプリに内包されている

などなど。他にもあったような気がします。

出来そう所から着手

この中から最短で効果が大きいものを抽出するとコチラ。

  • Resourcesフォルダにゴミファイルが残っている
  • ダミーの画像を本番で参照しているところがある
  • スプラッシュ画像が豪華
  • サウンドファイルがアプリに内包されている

おそらくこの4つを何とかすれば今回の申請は切り抜けられるだろうという感覚でした。

Resourcesフォルダにゴミファイルが残っている

Resourcesフォルダとは言わずも知れたUnityにとっては特別なディレクトリです。このフォルダ配下にあるものは、文字列指定でオブジェクトを取得することが出来ます。非常に便利な機能です。

非常に便利ですが、ゴミファイルが残っていると、そのゴミファイルもアプリに内包されるため、無駄な容量として計上されてしまいます。便利なのですが、扱いには十分注意しないといけません。

こちら500KB減らすことが出来ました。

ダミーの画像を本番で参照しているところがある

これは開発中にダミーデータを使用していると起こりえる現象です。先のResourcesフォルダに入っていなくても、参照さえあれば、実際使用していなくても、使用しているものと判断されてアプリに内包されてしまいます。

リリース当初は容量もそこまで大きくないので、気づき辛いということもあります。
定期的なリファクタリングを行うことも大事だと思いました。

こちら220KB減らすことが出来ました。

スプラッシュ画像が豪華

スプラッシュ画像とは、アプリを起動した際に表示される固定の画像のことです。
一見容量をあまり食いそうにない部分に見えますが、侮ってはいけません。

スプラッシュ画像を全面フルカラーで描画しているかなり大きな容量になります。
こちらを白ベタ + 中央ロゴのようなシンプルな形にすることで6MB減らすことが出来ました。

サウンドファイルがアプリに内包されている

サウンドファイル(主にBGM)が圧迫していました。
アセットバンドル化して必要なときにロードしてアプリ内にキャッシュするという方法を取りました。

ただ途中から仕組みを変更するというのは大変で、色んな所でBGM制御処理があったので、デバッグ作業が非常に大変でした。
その苦労のおかげで、8MBほど減らすことが出来ました。

合計15MBくらいを確保することができ、無事に切り抜けることが出来ました。

まとめ

今回解決に導いたのは、スプラッシュ画像の簡素化サウンドファイルの外部化だったわけですが、サウンドファイルの外部化は、リリース時の設計に入れるべきだと思います。リリース当初はそんな余裕がなかったのかもしれませんが、アプリ開発上、時間が経つ (運用している) と詰んでしまう設計は避けたいものです。

大事なのは突貫作業は極力避け、常にアプリ容量の事を頭の片隅に置いて開発をすることなのではないかと思います。

オススメ記事