見出し画像

Now in REALITY Tech #97 Unityパフォーマンスチューニング勉強会をやった話

REALITY

こんにちは、アバターシステムチーム所属、Unity エンジニアの虹ゴリラです。

REALITY のアバターシステムチームではパフォーマンスチューニングに関する知識を深めるために週に一時間費やす形で「Unityパフォーマンスチューニング勉強会」を開催しました。
今回はその取り組みについてご紹介します。

勉強会の目的

REALITY のアプリは広い端末で動作することを目標としており、それを実現するためには一定水準のパフォーマンスを維持する必要があります。

ただ、アプリパフォーマンスの維持と言うのはある程度の知識が要求され、更に改善や性能低下した際の分析などにはプロファイラーの使い方と言った専門的な知識も要求されることが多いため、属人化しやすい傾向にあると感じています。

そこで今回は先述した目標を実現するための一環として、チーム全員で改めてパフォーマンスについて意識できるようにするために「パフォーマンスチューニング勉強会」を開催することにしました。

取り組んだ内容について

実際に取り組んだ内容としては CyberAgent さんが GitHub 上で公開している「Unityパフォーマンスチューニングバイブル」を教材として活用し、輪読会形式で進めることにしました。

「パフォーマンスチューニングバイブル」にはパフォーマンスチューニングを行う上での基礎知識の他、各種プロファイラーの紹介、Unity を使う上での Tips など多岐に渡って網羅されているため、今回の勉強会に於ける教材としては最適だと判断して活用させて頂きました。

輪読会の形式としてはメンバーで交代しながらある程度の区切りまで読み、それぞれの点について補足や意見交換などを交えて進めていきます。

他にも、プロファイリングツールの章では実際に UnityProfiler や Xcode などを起動してプロファイリングのデモを行い、パフォーマンス計測を行う上でのポイントなども交えて補足していきました。

やってみて

ところどころ他のイベントなどでスキップする回など有りつつも、おおよそ半年弱ぐらいで読了するところまで行けました。

とりあえず一通りやってみて終えた所感としては次のように感じています。

  • Unity 全般に於けるパフォーマンスチューニングについての知識の他、それぞれのメンバーが持っている知識を元に補足をしたり、現状のプロジェクトを踏まえた上での議論などを行うことが出来た

  • 人によってはあまり触れる機会のないネイティブのプロファイリングツールについて解説することが出来た

特に効果が大きいと感じたのは前者であり、メンバーそれぞれが持つ知識を共有したり議論できた他、実際に勉強会の場で出た内容を元に幾つかの改善案を入れることにも繋がりました。

主催してみてどうだったか

今回の勉強会は私が主催する流れとなりましたが、素直にやってよかったものだと感じております。

前述した通り、一人で書籍を読むだけでは得られないであろう知識(メンバー個人が持つ経験則やプロジェクト特有の知識など)を得ることが出来たり、チームメンバー集まってパフォーマンスに関するトピックについて議論する機会を設けることが出来ました。
これらは通常業務を行うだけでは中々得られないものだったかなと思います。

ただ、一方で勉強会の進行については課題に思っているところもあり、今回は輪読会の読み手こそ交代制でやったものの、ファシリテーターと議事録は私が補足を行いたい側面もあって一人で担当することにしました。
ただ、いざ一人でやってみると思ったよりも負荷が高いことがわかってきたので、次に開催する際にはファシリテーターと議事録係も交代制にしたりと定期的に振り返りながら開催できたらなと考えてます。

おわりに

今回はパフォーマンス改善の一環としてやった「Unityパフォーマンスチューニング勉強会」の取り組みについてご紹介させていただきました。

アバターシステムチームでは他にも Unity のパフォーマンス改善施策を行っているので、また別の機会にでもご紹介できればと思います。

おまけ

このパフォーマンスチューニング勉強会では、主催の趣味により、勉強会に関連したダジャレを隙あらば差し込む文化が形成されていました。
実際に勉強会最中に投稿されたダジャレを幾つか紹介します。

  • メモリ使用量をメモります

  • バッチ (処理) はバッチリ！

  • 再帰しすぎて再起不能

  • Queue が急に〜

  • 補完したデータを保管する

  • コードを書いて覚えるのは高度

  • 難題って何だい？

  • アセットの読み込みで焦っとらんか？

  • 第三章を参照してください

  • ソート処理はそーっとやる必要がある

    • 相当難しいですね

    • 悪い使い方は掃討しないと

  • 有線を優先したい

  • 重いと言う思いはしたくない

  • 死因は Scene だった

  • 非同期を使う動機がない

  • パフォーマンスに非道なことするような非同期は避けないと

  • null チェック一回違うぐらいなら、動作がヌルヌルになる。というほどでもないですよね