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

by stand.fm

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