vearを支えるUnity as a Libraryの技術
こんにちは、vearの開発者のnoppeです。
vearはVRMアバターを使ったバーチャル自撮りアプリです。vearを触ったことのある方はお気づきかもしれませんが、このアプリは非常に自然な操作感を持ったアプリです。
ここで言う自然な操作感というのは、画面遷移のアニメーションやスクロールの慣性がApple純正のアプリと完全に同様であると言うことです。
通常Unityでアプリを開発する場合uGUIやnGUIを使ってボタンやスクロールを作りますが、それらはスクロール慣性や文字サイズなどにUnity独特のフィールがあります。この独特のフィールはアプリがどこかゲーム的で、UIを通して操作することを強くユーザー印象付けてしまいます。
多くのUnityアプリではアプリの世界観に合わせたUIを１から開発することで、OSの存在を忘れさせてこの印象を払拭することに成功していますがvearではあえてOSのUIを採用することにしました。
このエントリーでは、OSのUIを採用するために使われた「Unity as a Library」（以下UasL）という技術と、UasLを採用することで見えてきた可能性と制限に関して紹介します。
UasLとは
iOSではUnityで作られたアプリはUIWindowと言われるウィンドウの上で実行されます。全画面に表示されるのでイメージし辛いですが、UIWindowはデスクトップOSのウィンドウと同じ、アプリケーションを乗せるための枠です。
Unityアプリを含む全てのアプリはこのようにUIWindowの上で実行されています。通常のアプリ開発では、このウィンドウの上に動画を再生するプレーヤーやテキスト、画像などを乗せてアプリを作っていきます。Unityの場合はUnityを再生するプレーヤーを乗せています。
UasLとはこの仕組みを利用して、通常のUIKitアプリの中にUnityを再生するプレーヤーを埋め込む手法です。
UasLを使うメリット
先述したとおりUnityをアプリに埋め込むことで描画とUIを分離し、それぞれの特徴を活かしたアプリを作ることができます。
例えばペイントアプリであればUnityのハイパフォーマンスな描画エンジンを使いイラストを描き、投稿されたイラスト一覧をOS標準の滑らかなUIでスクロールして見ることができます。
また言語の壁は些細なことですが、当然UI側の実装はSwiftを開発言語として使うこともできます。強力な型システムのおかげで安全に開発することができます。
そして限定的なメリットですがARKitのアプリを作る際におすすめの手法でもあります。現在ARFoundationはUnity Editor上のシミュレートに対応していないため、修正するたびに毎回Unityビルドを経由して実機ビルド・転送という手順を踏んでデバッグ する必要があります。
UasLを利用すれば、事前にUnity上である程度自由度の高いメソッドを生やしてあとはSwiftの変更だけでアプリをデバッグ することができます。こうすることでUnityビルドを最小限に抑えつつ、高速に実機デバッグをすることができます。
UasLを使うデメリット
ここまでiOSだけの話をしていましたが、当然マルチプラットフォームに対応する場合はUnity以外の処理をOSごとに書く必要があります。
OSのデザインガイドラインに添ったアプリが作れる反面、その作業工数は大きく膨れます。現実的な工数を考えるとUnityのみで開発した方が良い場合も多いかと思います。
またメリットの点でも触れましたが、ObjCやSwiftと言ったC#以外の言語知識が必須になる点も人によってはコストになります。
さらにUnityのみの開発に比べEditor上で確認できる要素が減るためデバッグ のコストも増えるところにも注意が必要です。
UasLの辛いところ
パラメータがStringのみしか渡せない
アプリからUnityに対して渡せるパラメータはStringのみです。基本的に複雑な構造はjsonなどにエンコードしてUnityでデコードして扱うことになります。毎フレーム呼ぶような処理には向かないことが分かるかと思います。
また現実的に画像などのデータは一度書き出して渡すなど工夫する必要があります。
１つのレンダラしか使えない
UasLの制約によってアプリ内に複数のUnityを配置することはできません。頻繁に出たり消えたりするようなビューに使ったりテーブルの中に表示する場合は少し工夫が必要かもしれません。
シミュレータが使えなくなる（？）
Fatバイナリを吐かないようで、実機向けにframeworkを作ってしまうとシミュレータでビルドが通らなくなる。設定次第…？
どのようなアプリに向いているのか
UasLを採用するかどうかを見極める上で、指標となるのはUnityが描画するコンテンツがアプリのメインになるかどうかとアプリの世界観は独自のものであるかどうかです。
コンテンツがアプリのメインになるかどうかは、アプリがマップアプリやブラウザのようなUIに当てはめた時に上手くデザイン出来るかどうかで考えてみましょう。
Googleマップアプリ
起動直後からフルスクリーンでコンテンツが描画され、UIが浮かぶようなアプリになるのであればUasLは向いていると言えます。
これらは描画とUIが疎結合になっており、UIを通して描画領域を操作するという特徴があり相性がいいためです。
アプリの世界観は独自のものであるかどうかは、言い換えればUIの領域もアプリの世界観で描かれるべきなのかということです。
タップ時のエフェクトやアニメーションはそのアプリの世界観により没入させる効果があります。
そういった世界観を犠牲にしてまでOS標準のUIを使う必要はありません。
UasLはUIの手前に描画したりすることができないので、表現に制約がかかるとよろしくない場面などが無いかは慎重に見極めたい箇所です。
UasLの採用されているアプリ
知る限りmirrativと私のvearしか知りません、、ご存知の方やリリースしている方がいれば教えていただけると嬉しいです。
その他お問い合わせはこちら
🐦@noppefoxwolf
✉️ noppelabs[at]gmail.com