趣味でつくる​ アバター×アバター​ マッチングアプリ~Performanceチューニング編~​

VRCLT #2 用です

Transcript

1. 趣味でつくる アバター×アバター マッチングアプリ ~Performanceチューニング編~ BOXP
2. 自己紹介 • 一箱さん (の体を借りたBOXP) • 某Web企業でソフトウェアエン ジニアをしています • 好きなLispはClojureです
4. 製作中のアプリ • VRChat、Virtual Castなどから 好みのアバターを自動で探して くれるサービス • IPhone・Android向けWebアプリ としてリリース予定 • VRじゃなくてごめんなさい • 所謂PWA(Progressive Web Apps)を目指して製作中
5. なぜWeb？ • 無名のアプリなので インストールの手間があるとその まま直帰してしまう… 多くの人に触ってほしい • このスライドも社内勉強会の資料 を再編集したもの 実験的な技術を試して 業務に活かしたい
6. なぜWeb？ • 無名のアプリなので インストールの手間があるとその まま直帰してしまう… 多くの人に触ってほしい • このスライドも社内勉強会の資料 を再編集したもの 実験的な技術を試して 業務に活かしたい
7. とは言え インストールの手間がなくても Webページがもっさりしていると 使ってもらえない
8. もっさりしないために Hito Hubで何をしたか
9. 状況に応じて 必要なパフォーマンス を満たす
10. Webアプリ 4つの側面 (RAILモデ ル) • Response: ユーザーの入力に対する応答中の状態 • Animation: アニメーション再生中の状態 • Idle: ユーザーの入力を待機している状態 • Load: コンテンツ読み込み中の状態 引用元: RAIL モデルでパフォーマンスを計測する https://developers.google.com/web/fundamentals/performance/rail
11. 快適な パフォーマンス の目安 •100ミリ秒以内の応答 •これよりも遅いと操作と反応のズレを感じる Response •10ミリ秒以内に画面をレンダリング •1000ms / 60fps - ブラウザによるレンダリング時間 (約6ms) =約10ms Animation •アイドル時間を利用したタスク分担 •100ミリ秒以上かかる処理はアイドル時間まで後回 し •ユーザー入力へのレスポンスが最優先 Idle •読み込みは1000ミリ秒以内に •1000ミリ秒より長いとユーザーの集中力が切れて しまう Load ※Google調べ
12. Hito Hubですべて満たすまで 最適化してみました
13. 全ての入力に対して 100ms以内に応答する 100ms以内に応答が間に合わ ない場合は別の応答を返す • Rippleを表示させるなど 応答処理と他の処理を同時に 実行させない • リソースの取得などは別スレッド (WebWorkerなど)で行うか後回しに する Response
14. アニメーションを60fps で動かす アニメーションが必要なカードだけ別 レイヤーに • will-change: transform;スタイルによって別レ イヤーへ • 重ね合わせによるピクセルの計算をスキッ プできる 透過・座標移動のみでアニメーション を実現させる • transform,opacityスタイルを使う Animation
15. 読み込み時間を 1秒以内に Load JavaScriptファイルは分割して 必要な分だけロードさせる • 追加のJavaScriptファイルが必要なと きにはじめてロードする 他の画面に必要なファイルを prefetchしておく • WebWorkerを使って画面の処理を 邪魔せず先読みしておく
16. 最適化の結果
18. 最適化の甲斐あって なんとかサクサク動くよう になった
19. ～Fin～
20. 最後に告知的なもの
21. 7月末までにリリース予定！
22. Thanks!