Unityのframework化を支える技術

Transcript

1. Wright Flyer Live Entertainment Unityのframework化を 支える技術
2. 自己紹介 • 清 貴幸 • WFLE, Inc. • エンジニア ◦ iOS ◦ Unity（NativePlugin） • 最近の事件 ◦ 港区に家を買おうとして心が 折れた ◦ 港区の家事情に詳しい人、仲 良くしてください
3. 発表の概要
4. Unityアプリをframework化 してネイティブiOSアプリに 組み込みたい!!
5. 背景
6. https://www.wantedly.com/companies/wrightflyer/post_articles/176535
7. これ https://www.wantedly.com/companies/wrightflyer/post_articles/176535
8. • iOSアプリを開発するために、まずUnityを入れる必要がある • Unityから出力したソースコードをimportしているためにクソ でかい差分が出やすい • .xcodeprojェ・・・ • 差分がでかいゆえにコンパイル時間がエグい • クリーンビルドで600sec前後 framework化前に発生していた問題
9. やったこと
10. • Unityアプリのembedded framework化 • framework開発環境の用意 • インタフェイス整備 • リリースフローの変更 • frameworkのリリース • ビルドしたframeworkの組み込み やったこと
11. Unityアプリの embedded framework化
12. • XcodeGenでframeworkビルド用プロジェクトを自動生成 • https://github.com/yonaskolb/XcodeGen framework開発環境の用意
13. • 最初はUnityから出力したxcodeprojをそのまま使うか迷った • 生成物なのでgit commitしづらい • 故にxcodeprojの拡張が大変になる • -> frameworkビルドできるxcodeprojを別途用意しよう • -> ぶっちゃけXcodeGenでの自動生成を試してみたかった framework開発環境の用意
18. • Unityで開発したアプリをCLIだけでframework化できるよう になった framework開発環境の用意
19. • ネイティブアプリからUnityの機能を呼び出すときのインタ フェイスを作る必要がある • 複数のNativePluginに実装が散らばっていてわかりづらい • Unity <-> ネイティブアプリの連携方法が統一されてない インタフェイスの整備
21. ライブ配信 機能UI Unity(C#) Unity Native Plugin (ObjC++) iOS App (Swift / ObjC) 3Dモデル表示 フェイストラッ キング 機能 ライブ 配信機能 Unity ランタイム インタフェイス なんらかの イベント通知 Unity ランタイム
22. ライブ配信 機能UI Unity(C#) Unity Native Plugin (ObjC++) iOS App (Swift / ObjC) 3Dモデル表示 フェイストラッ キング 機能呼び出し ライブ 配信機能 呼び出し Unity 機能呼び出し なんらかの イベント通知 framework フェイストラッ キング 機能 ライブ 配信機能 フェイストラッ キング デリゲート ライブ配信 デリゲート Unity ランタイム Unity ランタイム インタフェイス
23. • Unity <-> ネイティブアプリの連携方法が統一された • ネイティブアプリとUnityのインタフェイスが単純明快になっ た • iOSエンジニアにとってなじみのあるインタフェイスになった • デリゲートパターンを採用 • ライブ配信とフェイストラッキングのクラスをネイティブア プリプロジェクトに移動 • iOSエンジニアが修正しやすくなった インタフェイスの整備
24. リリースフローの変更
25. • submodule updateからframeworkリリースへ リリースフローの変更
26. REALITY iOS Repository REALITY iOS Proj REALITY Avatar Repository　 REALITY Avatar Unity Proj REALITY Avatar iOS Proj Submodule 1. Avatarの 　Xcode Projを出力 2. 必要なファイルをコピー 3. アーカイブ 4. IPA出力
27. RealityAvatar .framework GCS 6. IPA出力 REALITY iOS Repository REALITY iOS Proj RealityAvatar .framework REALITY Avatar Repository　 REALITY Avatar Unity Proj REALITY Avatar iOS Proj RealityAvatar .framework 5. アーカイブ 3. frameworkアップロード 1. AvatarのXcode Proj出 力後、コードコピー 2. frameworkのビルド 4. frameworkのダウンロード
28. • ネイティブiOSアプリを作るときはframeworkの依存解決する だけになった • frameworkへの依存解決はcurlでファイルを落として配置す るだけ • cocoapodsに対応させるか検討中 リリースフローの変更
29. 結果
30. • iOSアプリを開発するために、まずUnityを入れる必要がある • -> 初期開発時にUnityがなくてもビルド可能に！ • Unityから出力したソースコードをimportしているためにクソ でかい差分が出やすい • -> frameworkのlinkになり、xcodeprojの差分が出なくなった • 差分がでかいゆえにコンパイル時間がエグい • クリーンビルドで600sec前後 • -> 結果
31. • NativePluginを開発する際にxcodeprojが使えるように • もともとはUnityのディレクトリ以下にファイルがぽつんと置いて あった。。 • ネイティブから使えるUnity機能の一覧がframeworkのヘッダ に集約されて一覧性が向上した • 開発時にiOS Simulatorを利用しやすくなった • ソースコードimportだとここがかなりだるい 結果
32. やった感想
33. • NativePluginを開発する際にxcodeprojが使えるように • もともとはUnityのディレクトリ以下にファイルがぽつんと置いて あった。。 • ネイティブから使えるUnity機能がframeworkのヘッダに集約 されて一覧性が向上した • 開発時にiOS Simulatorを利用しやすくなった • UnityでSImulator向けコードを吐き出してframeworkビルドするだ け • lipoを使えばで1バイナリにもできる やった感想
34. • XcodeGenは普通に便利でネイティブアプリ環境にも入れたい • ただしcocoapodsとの相性問題が少々あるらしい • iOS開発者の負担は減ったが、Unity側開発機能のリリースが 複雑になった • 自動化可能であり、模索中 • Unityバージョンアップ時にメンテコストが掛かり続けるのを どうとらえるか • 年に1回の大掃除みたいなのが必要 やった感想
35. まとめ
36. • Unityアプリをframework化して組み込むとコンパイル時間等 の問題がなくなる • 仕組みの維持にメンテコストがかかるので、トレードオフは 考えよう • XcodeGenは良いもの まとめ
37. Appendix
38. Unity as a library
39. 比較（個人の感想） 清の手法 (beta)Unity as a library framework作成機能 メンテコスト 高 - NativePlugin 開発しやすさ 高 低 別プロジェクトへの 導入しやすさ 高 低 iOSエンジニア 親和性 高 中
40. • 機能的に足りないし、(betaなので)導入は先になりそう • いつかこれで良くなる日は来そう • frameworkのリリースフローの仕組み化はその後も運用可能 なので、その辺を頑張って行く 感想
41. Wright Flyer Live Entertainment Unityのframework化を 支える技術
42. Wright Flyer Live Entertainment Unityのframework化を 支えてた技術
43. ご清聴ありがとうございました