stand.fmにおける開発体験とパフォーマンスの向上 / Development Experience and Performance improvement
by
stand.fm
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
stand.fmにおける開発体験と パフォーマンスの向上 エンジニア 古川 亘 2021/01/21 TECH STAND #3
Slide 2
Slide 2 text
自己紹介 Wataru Furukawa エンジニア @ stand.fm Twitter GitHub ブログ @kfurumiya @kotofurumiya https://sbfl.net/blog/ 2020年11月にstand.fmに入社。 フロントエンド中心の技術スタックを活かして主にクライアント側を担当。 好きな言語 趣味 TypeScript / Rust プログラミング / ゲーム / お絵描き
Slide 3
Slide 3 text
本日話す内容 1. stand.fmの簡単な紹介 2. 開発現場における工夫 3. 便利コンポーネントの実装 4. コンポーネントのFC化 5. ステート更新の最適化
Slide 4
Slide 4 text
stand.fmの簡単な紹介
Slide 5
Slide 5 text
stand.fmの簡単な紹介
Slide 6
Slide 6 text
stand.fmの簡単な紹介
Slide 7
Slide 7 text
技術スタック ● クライアント側の技術スタック ○ React Native ○ React Native for Web ○ Flow ○ Java / Objective-C / Swift
Slide 8
Slide 8 text
開発現場における工夫
Slide 9
Slide 9 text
開発現場における工夫 ● サービスの規模拡大に伴う開発負担の増大 ● 同時接続数の増加に耐えうる実行パフォーマンスの確保 ● より快適で効率的な開発を目指す必要 ● CI/CDの整備、品質管理の効率化 ○ → 本日はこちらは割愛 ● 開発の快適性、パフォーマンス向上 ○ → こちらのお話をします
Slide 10
Slide 10 text
開発現場における工夫 ● 開発の快適性 ○ 内部コンポーネントの整備 ○ レガシー資産の早めの置き換え ● パフォーマンスの向上(クライアント側) ○ 大規模LIVEにおける更新頻度の抑制
Slide 11
Slide 11 text
便利コンポーネントの実装
Slide 12
Slide 12 text
便利コンポーネントの実装 ● Portalを独自実装 ○ React NativeにはPortalがなかったので ● Portal ○ もとはreact-domに存在する機能 ○ コンポーネントを本来と異なる位置にレンダリング ● さまざまなユースケース ○ モーダル ○ トースト
Slide 13
Slide 13 text
Portal機能
Slide 14
Slide 14 text
Portal機能 ● ステート管理とレンダリング位置の分離 ○ 例えばモーダルは画面のトップレベルに存在する ○ が、実際に制御を握っているのはツリーの下層の方 ● Portalなしだと ○ Reduxなどのグローバルステートを経由して管理 ○ 無駄なステートが増えて混乱しがち ● Portalありだと ○ モーダルのステートを最小のスコープで管理できる
Slide 15
Slide 15 text
Portal機能 ● React NativeにはPortalは無い ○ react-domの機能であってreactの機能ではないので… ● ネイティブアプリ開発において必要な場面は多い ○ トーストやモーダルは頻出する ○ モーダルのためにStoreを混沌とさせたくない
Slide 16
Slide 16 text
コンポーネントのFC化
Slide 17
Slide 17 text
コンポーネントのFC化 ● stand.fmの開発は2018年開始 ○ クラスコンポーネント全盛期 ● 2019年にHooks正式実装 ○ React界隈が一気に関数コンポーネントに傾いた
Slide 18
Slide 18 text
コンポーネントのFC化 ● ライブラリや資料などもHooks前提になりつつある ○ 関数コンポーネントのほうが情報を探しやすい ● 単純にHooksのほうがコードが読みやすい ○ ライフサイクルの処理を一箇所にまとめやすい ○ カスタムHooksによる記述の簡略化 ● 置き換えよう!!!
Slide 19
Slide 19 text
コンポーネントのFC化
Slide 20
Slide 20 text
コンポーネントのFC化 ● 現在も徐々に置き換え中 ○ 大きいのはとりあえず済みました ● まだまだいっぱいあります ○ 全部置き換えるのを目指しています
Slide 21
Slide 21 text
ステート更新の最適化
Slide 22
Slide 22 text
ステート更新の最適化 ● LIVE機能 ● コメントでやりとり可能 ● ギフト機能あり
Slide 23
Slide 23 text
ステート更新の最適化 ● 課題 ○ SNSでフォロワー10万人越えの方のライブ ○ コメント流れる速度が速い ○ ギフトが大量に飛び交う ● → 端末の処理落ち ○ 音声再生にも影響が出る ○ 重すぎて接続が切れる
Slide 24
Slide 24 text
ステート更新の最適化 ● 重い原因 ○ コメント取得ごとに再描画が走っている ○ 秒間100コメントなら秒間100回の再描画 ● コメント描画更新の最適化 ○ 端末が処理落ちしない程度に抑える ○ なおかつ遅延を感じないようにする
Slide 25
Slide 25 text
ステート更新の最適化 ● 受信したコメントはバッファして30msごとにflush ○ 最長でも30msしか描画遅延が発生しない ○ 何百件コメントが来ようと30msごとにしか再描画されない ○ → 描画負担が低い、かつ予測可能になった ● 大規模なLIVEにも耐えられるようになりました ○ コメント流速にかかわらず負担が一定
Slide 26
Slide 26 text
まとめ
Slide 27
Slide 27 text
まとめ ● ユーザと開発者の両方に最適な体験を届けたい ○ そのためには快適に開発・利用できる環境が必要 ● 便利コンポーネントの整備やリファクタリングは重要 ○ 気持ちよく開発してもらう ● アプリのパフォーマンスを維持することが大事 ○ どんな状態でも体験を損なわないようにする
Slide 28
Slide 28 text
No content