stand.fmにおける開発体験とパフォーマンスの向上 / Development Experience and Performance improvement

stand.fmにおける開発体験とパフォーマンスの向上エンジニア古川亘 2021/01/21 TECH STAND #3

自己紹介 Wataru Furukawa  エンジニア @ stand.fm  Twitter  GitHub  ブログ  @kfurumiya 
@kotofurumiya  https://sbfl.net/blog/     2020年11月にstand.fmに入社。   フロントエンド中心の技術スタックを活かして主にクライアント側を担当。   好きな言語  趣味  TypeScript / Rust  プログラミング / ゲーム / お絵描き    

本日話す内容 1. stand.fmの簡単な紹介  2. 開発現場における工夫  3. 便利コンポーネントの実装  4. コンポーネントのFC化  5.
ステート更新の最適化 

stand.fmの簡単な紹介 

技術スタック • クライアント側の技術スタック  ◦ React Native  ◦ React Native for
Web  ◦ Flow  ◦ Java / Objective-C / Swift 

開発現場における工夫 

開発現場における工夫 • サービスの規模拡大に伴う開発負担の増大  • 同時接続数の増加に耐えうる実行パフォーマンスの確保  • より快適で効率的な開発を目指す必要  • CI/CDの整備、品質管理の効率化  ◦
→ 本日はこちらは割愛  • 開発の快適性、パフォーマンス向上  ◦ → こちらのお話をします 

開発現場における工夫 • 開発の快適性  ◦ 内部コンポーネントの整備  ◦ レガシー資産の早めの置き換え  • パフォーマンスの向上（クライアント側）  ◦
大規模LIVEにおける更新頻度の抑制 

便利コンポーネントの実装 

便利コンポーネントの実装 • Portalを独自実装  ◦ React NativeにはPortalがなかったので  • Portal  ◦ もとはreact-domに存在する機能 
◦ コンポーネントを本来と異なる位置にレンダリング  • さまざまなユースケース  ◦ モーダル  ◦ トースト 

Portal機能

Portal機能 • ステート管理とレンダリング位置の分離  ◦ 例えばモーダルは画面のトップレベルに存在する  ◦ が、実際に制御を握っているのはツリーの下層の方  • Portalなしだと  ◦
Reduxなどのグローバルステートを経由して管理  ◦ 無駄なステートが増えて混乱しがち  • Portalありだと  ◦ モーダルのステートを最小のスコープで管理できる 

Portal機能 • React NativeにはPortalは無い  ◦ react-domの機能であってreactの機能ではないので…  • ネイティブアプリ開発において必要な場面は多い   ◦
トーストやモーダルは頻出する  ◦ モーダルのためにStoreを混沌とさせたくない 

コンポーネントのFC化 

コンポーネントのFC化 • stand.fmの開発は2018年開始  ◦ クラスコンポーネント全盛期  • 2019年にHooks正式実装  ◦ React界隈が一気に関数コンポーネントに傾いた 

コンポーネントのFC化 • ライブラリや資料などもHooks前提になりつつある  ◦ 関数コンポーネントのほうが情報を探しやすい  • 単純にHooksのほうがコードが読みやすい  ◦ ライフサイクルの処理を一箇所にまとめやすい  ◦
カスタムHooksによる記述の簡略化  • 置き換えよう！！！ 

コンポーネントのFC化

コンポーネントのFC化 • 現在も徐々に置き換え中  ◦ 大きいのはとりあえず済みました  • まだまだいっぱいあります  ◦ 全部置き換えるのを目指しています 

ステート更新の最適化 

ステート更新の最適化 • LIVE機能  • コメントでやりとり可能  • ギフト機能あり 

ステート更新の最適化 • 課題  ◦ SNSでフォロワー10万人越えの方のライブ  ◦ コメント流れる速度が速い  ◦ ギフトが大量に飛び交う  •
→ 端末の処理落ち  ◦ 音声再生にも影響が出る  ◦ 重すぎて接続が切れる 

ステート更新の最適化 • 重い原因  ◦ コメント取得ごとに再描画が走っている  ◦ 秒間100コメントなら秒間100回の再描画  • コメント描画更新の最適化  ◦
端末が処理落ちしない程度に抑える  ◦ なおかつ遅延を感じないようにする 

ステート更新の最適化 • 受信したコメントはバッファして30msごとにflush  ◦ 最長でも30msしか描画遅延が発生しない  ◦ 何百件コメントが来ようと30msごとにしか再描画されない  ◦ → 描画負担が低い、かつ予測可能になった 
• 大規模なLIVEにも耐えられるようになりました  ◦ コメント流速にかかわらず負担が一定 

まとめ 

まとめ • ユーザと開発者の両方に最適な体験を届けたい  ◦ そのためには快適に開発・利用できる環境が必要  • 便利コンポーネントの整備やリファクタリングは重要  ◦ 気持ちよく開発してもらう  •
アプリのパフォーマンスを維持することが大事  ◦ どんな状態でも体験を損なわないようにする 

stand.fmにおける開発体験とパフォーマンスの向上 / Development Experience and Performance improvement

stand.fmにおける開発体験とパフォーマンスの向上 / Development Experience and Performance improvement

stand.fm

More Decks by stand.fm

Other Decks in Programming

Featured

Transcript

stand.fmにおける開発体験とパフォーマンスの向上エンジニア古川亘 2021/01/21 TECH STAND #3

自己紹介 Wataru Furukawa  エンジニア @ stand.fm  Twitter  GitHub  ブログ  @kfurumiya

本日話す内容 1. stand.fmの簡単な紹介  2. 開発現場における工夫  3. 便利コンポーネントの実装  4. コンポーネントのFC化  5.

stand.fmの簡単な紹介

stand.fmの簡単な紹介

stand.fmの簡単な紹介

技術スタック • クライアント側の技術スタック  ◦ React Native  ◦ React Native for

開発現場における工夫

開発現場における工夫 • サービスの規模拡大に伴う開発負担の増大  • 同時接続数の増加に耐えうる実行パフォーマンスの確保  • より快適で効率的な開発を目指す必要  • CI/CDの整備、品質管理の効率化  ◦

開発現場における工夫 • 開発の快適性  ◦ 内部コンポーネントの整備  ◦ レガシー資産の早めの置き換え  • パフォーマンスの向上（クライアント側）  ◦

便利コンポーネントの実装

便利コンポーネントの実装 • Portalを独自実装  ◦ React NativeにはPortalがなかったので  • Portal  ◦ もとはreact-domに存在する機能

Portal機能

Portal機能 • ステート管理とレンダリング位置の分離  ◦ 例えばモーダルは画面のトップレベルに存在する  ◦ が、実際に制御を握っているのはツリーの下層の方  • Portalなしだと  ◦

Portal機能 • React NativeにはPortalは無い  ◦ react-domの機能であってreactの機能ではないので…  • ネイティブアプリ開発において必要な場面は多い   ◦

コンポーネントのFC化

コンポーネントのFC化 • stand.fmの開発は2018年開始  ◦ クラスコンポーネント全盛期  • 2019年にHooks正式実装  ◦ React界隈が一気に関数コンポーネントに傾いた

コンポーネントのFC化

コンポーネントのFC化 • 現在も徐々に置き換え中  ◦ 大きいのはとりあえず済みました  • まだまだいっぱいあります  ◦ 全部置き換えるのを目指しています

ステート更新の最適化

ステート更新の最適化 • LIVE機能  • コメントでやりとり可能  • ギフト機能あり

ステート更新の最適化 • 課題  ◦ SNSでフォロワー10万人越えの方のライブ  ◦ コメント流れる速度が速い  ◦ ギフトが大量に飛び交う  •

ステート更新の最適化 • 重い原因  ◦ コメント取得ごとに再描画が走っている  ◦ 秒間100コメントなら秒間100回の再描画  • コメント描画更新の最適化  ◦

まとめ

まとめ • ユーザと開発者の両方に最適な体験を届けたい  ◦ そのためには快適に開発・利用できる環境が必要  • 便利コンポーネントの整備やリファクタリングは重要  ◦ 気持ちよく開発してもらう  •