表題の通り、Unity2017.4→2018.4にアップデートした時のハマった点や、普段アップデートする時に意識してる事などを紹介できればなといった感じです。
Unityのアップデート作業を初めてやる方や、あと来年2017から2018へ移行する稀有な運命の方がググった時に何か参考になれば幸いです。
ちなみにバージョンを上げる事になった経緯としてはAndroidの64bit対応がUnity5を除くバージョンの場合は8月までに対応必須だったからです。
ゲーム事業部、技術部所属の須藤(@p_chin)です! この記事はTech KAYAC Advent Calendar 2019 Migration Trackの23日目の記事となります。
大まかな作業段取り
Unityバージョンの選定
基本運用中タイトルなので最新のメジャーバージョンにてLTSリリースである4のマイナーバージョンあたりが出てる場合はそれを選択しています。
今回は.net4.0を2018から使える様になってるのでメンバーのテンションは高い状態でした。
試しに動かしてみる
ゲームが前のバージョンと同じ様に動くか?を見るんですが、だいたいAssetBundle(以下AB)にしてるアセットの互換性がなかったりで死ぬパターンがよくあります。
後述しますがUnity2017-18間では主にshader周りで自分のプロジェクトでは互換性が崩れていたのを確認できました。
アップグレードして出てしまった問題を全て潰す
言うは易しですが、一番重く辛い作業ですね。
詳細は後述しています。
他の開発branchへのmergeタイミングを調整
問題を潰し切ったら次はアップグレードを受け入れるタイミングをPMやQA担当とすり合わせします。
(ちなみに前提としてバージョン管理にはgitを使用してます)
よくあるのが端末の環境依存や、NativePluginを使用してる機能で問題がある場合が過去のアップグレードで多かった印象です。
開発側で対応完了した後、2018化したbranchにて一週間ほど致命的なバグがないか狙ってるアプリバージョンのbranchを毎日mergeしてビルドを作り直した状態でQAを行います。
事前にチームメンバーにアップグレードのアナウンスをする
自分のチームではアーティスト、プランナーもUnityを使って仕事をしてるので広域に渡ってUnityバージョン移行の段取りを指揮する必要があるので、案内文を作ります。
内容としては
- 『N日までにinstallしておいてね』
- 『分からなかったらエンジニアに聞いてね』
- 『新しいgit-repositoryをcloneしておいてね』
- 『{2018対応のbranch名}をcheckoutして一回新しいUnityで開いておいてね』
- 『2017で作ってたアプリが本番から消えるまでは複数バージョンを使って仕事するのでUnityHubを紹介するので使ってね』
...などです。
各スタッフのUnityやgitに関するリテラシーは様々なので手厚くサポートが必要でした。
理想的なやり方してるプロジェクトだとUnityの外でデータやアセットをエンジニア以外が作れる環境があるのかもしれませんが、ツールを作りきる時間がなかったので自分のプロジェクトではUnityEditorにかなり頼っています。
対応完了
めでたい!!!
QA中に課金など主要機能で重篤なバグが出なかった事を確認できたら2018対応を狙ってるバージョンのbranchに一応Unity使用者の準備が整ってることを確認してからmergeします。
作業中に発生した問題
shaderの互換性崩れ
自分のチームではキャラモデルに適用してるKamakuraShaderと、エフェクトなどに利用してるUnityの標準shaderあたりが対象でしたので、全てそれに関連するABを作り直しました。
逆にそれ以外のアセットの互換性はUnity2017で作成したABを2018で読み込んでも問題なかったので、無駄にユーザーにアセットをDLし直させる必要は無いのでrebuildしませんでした。
やった事としては2018の対応branchでABのビルドする時にはshaderに依存してるかをチェックし、依存してるアセットのみビルド対象にする処理を書き、実行させていました。
QAの為に毎日別のbranchの修正を2018対応branchに取り込んでいるので、これによって更新の手間が楽になりました。
CrashlyticsでiOSのレポートが通知されない
Unity関係あるか不明ですが同時にFirebase Crashlytics v6.0.0にアップデートした所、なぜかクラッシュレポートされない問題が起きていました。
これに関しては謎だったのですがアプリのビルド時に BuildOptions.AllowDebugging
を抜いたらビルド時のsymbolから --enable-debugger
が抜けた様で問題なくなりました。
UniversalApkのサイズが50MB増えた
なぜかapkの中に含まれる /lib/armeabi-v7a/libil2cpp.so
のサイズが 3倍になった現象でした。
調査していくと、Monoのsymbolが入ってる so ファイルに問題が起きてる様でした。IL2CPPでビルドしてるのに謎です。
最終的にはこちらに関してもリリースビルドで試した所、余計なMonoのライブラリが除外されたからかapkサイズが戻ったので --enable-debugger
のデバッグ用のsymbolのせいでした。Unityのビルドシステム側のバグ。。。?とりあえず対処療法で治ったので以降は深追いしていません。
UI.Textの拡張したComponentでバグった
unity2018でUnityEngine.UI.Textに変更が入っていたので、その変更分を追従し忘れていました。
ちなみにローカライズ対応で指定したRectに収まらない文字数だった場合に横に頂点を潰してRect内に収める様なComponentを作っていました。
拡張先のComponentでは2018でメッシュの頂点をキャッシュから取ろうとすると取れない時があったらしく、大元のText.csの中身を真似する形で問題を解消しました。
unity issue tracker で報告されてたバグを修正した結果、バグの挙動を期待してたコンポーネントがバグってしまった様です。
UI: Fixed issue with Font Sizes that are too big for Rect Transform causing "Argument Out Of Range" error.
Unityをアップデートした場合に見るべきだと思う観点
QAに先行で重篤なバグを見つけてもらう為に以下のケースを優先してもらってました。
以下は実際にQAに共有した箇条書きです
今回はshaderの互換性が崩れてたので見た目も重点的に見ていました。
- 各種NativePluginの更新があったので、それらに関する機能
- SNS連携(データ引き継ぎ) android/ios
- LINE
- 課金 android/ios
- GooglePlayGameServiceへのサインイン android
- リモートプッシュ通知 android
- SNS連携(データ引き継ぎ) android/ios
- ゲームの見た目への変化(描画周りの更新があったので、何か軽微な問題が出てるかもしれません)
- アウトゲームのUIの見た目
- インゲームの3D表現周りの見た目
- キャラモデル
- 建物モデル
- エフェクト...etc
エンジニアは以下も事前に確認しておくと安心かと思ってます
- 通信切断時のエラー&リカバリ処理
- 画面遷移時の割り込み操作
- 発熱、バッテリー消耗が激しい
- ABの読み込み耐久テスト
- Loadを繰り返してクラッシュしないかなど
- ビルド後のサイズが急激に増えてないか
- 各画面でのメモリ使用量が急激に増えてないか
- 1フレームの処理時間が急激に増えてないか?
- 特にアクセスの多い画面やバトルなどの様に特に速度が求められる場面でのチェックは優先的に
- Unityが提供してるclassを継承してる機能が問題なく動くか?
- UI.Textなどは自分の周りでも拡張してる人が多いので特に注意かも
リリース前にUnity2018に上げておけば楽だったのでは?
Unity2018.1が出た時点でリリース前のQAフェーズに入ってしまってたので無難に2017.4のLTSリリースのバージョンを選択肢しました。
2019年夏にAndroid64bit対応に向けて確実にUnityをアップデートする必要がありましたが、Unityのメジャーバージョンが安定するまでは最低でもマイナーが2になるまではかかるという宗教を自分は信じてるので安全側に倒した判断をしていました。