見出し画像

Now in REALITY Tech #87 AndroidのUnityViewの扱い方

こんにちは!REALITYでAndroidエンジニアをしている、ぴかです。
今回はREALITYのAndroidアプリにおける、UnityのView扱い方の課題や改善している部分をお伝えしたいと思います。

AndroidのUnityの実装について

前提として、REALITYの3D描画についてはUnityを利用していますが、3D描画を行わない画面や一部のUIについてはNativeのアプリとして開発していま
す。

配信画面 (Unity)
プロフィール画面 (Unity + Native)
ガチャリスト画面 (Native)

そのため、REALITYは基本的にNativeのアプリとしつつ、UaaL(Unity as a Library)を利用しながら、開発を行っています。
Nativeのアプリということで、Unityに対してはUnityを表示するViewの管理とUnityとのデータのやり取りが必要になります。
(Unity側もNative側がどういう動作や遷移を行っているかわからないので、Native側がある程度ハンドリングする必要がある。)

現状のUnity実装の課題

このViewとUnityの状態の管理がREALITYの開発の難しいところで、以下の実装が要件として求められます。

・Unityの起動状態ではUnityを起動しながら、UnityのViewを適切なView階層に配置・表示する
・Unityの停止状態ではUnityを停止しながら、UnityのViewを隠す、もしくは破棄する

このような要件に対して、比較的楽に実装できそうなのがUnityのViewを常に前面に配置しつつ、Unityの起動・停止を行う実装です。
View自体を破棄しないため、Unityの起動状態についてもNativeからハンドリングする要素が少なく、Viewについての管理も破棄を行わないため実装上のバグが起こりにくいと考えられます。
実際、REALITY AndroidのUnityの表示については上記の方法で行われてきました。

視聴中画面でのレイアウト
説明画像では真っ黒だが、アプリとしてはUnityが動作して、アバターが表示されている
UnityのView(青枠)が表示されている裏で遷移前の画面が残っている
ガチャリスト画面(Unityを使っていない画面)のレイアウト
Unityを使っていないのでUnityのViewは本来必要ないが、存在自体はしている
Unityは停止していて、View自体も非表示なので動作的には問題なさそうに見える

しかし、最近この方式の実装においても課題が出てきました。
Androidにおいては、画面遷移は一般的にはNavigationで行われますが、UnityのViewへの画面遷移がNavigationに対応できないので歪な実装になってしまいます。
また、現在のREALITYのプロフィール画面で行っているような、UnityとNativeを合わせたような一部の画面についても対応できません。

プロフィール画面 (Unity + Native)
他画面のように全画面表示すれば良いわけではないので、扱いを変える必要がある

プロフィール画面の実装については、過去のノートで紹介しています!

課題解決にむけて

これらの課題として実装を始めているのが、UnityのViewも含めてNativeのViewとして扱う実装です。
こちらの実装だと、親Viewの破棄と同時にUnityのViewも破棄されるので、前述の方法よりもUnityやViewの管理を適切に実施する必要がありますが、それ以上に現状の課題に対して向き合うために、こちらの実装へ移行を進めています。

配信画面 (Unity)
UnityのViewを遷移先のViewに含めている
以前の実装だと、裏側に遷移前のViewが残っていた

自分が配信画面については移行を担当したのですが、UnityのViewが二つ存在できない点やUnityの状態管理はハンドリングが難しく、開発中のバグ対応やデグレ確認にはかなりの時間を要しました。

現状の進捗

実はこの移行作業自体は結構進んでおり、配信の視聴画面とアイコン撮影の画面以外は新方式の実装で実装されています。
こちらの移行は実装箇所によっては作り直しのようになってしまい、動作自体は変わらないように努めていますが、どうしてもバグが発生してしまいがちなので丁寧に実装やテストをするように心がけています。

まとめ

このような大規模な影響がある技術的負債は、掛けるコストやユーザー影響の側面からなかなか着手することが難しい課題ですが、いずれ改善が必要な課題でもあり、将来的な開発速度の向上に起因することが多くあります。

影響度が大きな修正の場合は、どうしてもバグが発生する可能性も高くなってしまいますが、極力バグを出さない。むしろ一緒に改善したい。の意気込みで開発していきますので、今後ともよろしくお願いいたします!