Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up
for free
stand.fmにおける開発体験とパフォーマンスの向上 / Development Experience and Performance improvement
stand.fm
January 21, 2021
Programming
1
610
stand.fmにおける開発体験とパフォーマンスの向上 / Development Experience and Performance improvement
stand.fm
January 21, 2021
Tweet
Share
More Decks by stand.fm
See All by stand.fm
standfm
0
41
standfm
0
21
standfm
1
810
standfm
5
18k
Other Decks in Programming
See All in Programming
meemeelab
0
310
yoshinoriiiii
0
110
tkow
1
130
afilina
PRO
0
150
korosuke613
2
270
hyodol2513
0
630
heistak
2
130
madai0517
1
210
kyokomitsuoka
0
110
takapdayon
0
180
shiz
1
110
koheisakata
0
180
Featured
See All Featured
shlominoach
176
7.5k
garrettdimon
288
110k
cherdarchuk
71
260k
malarkey
392
61k
lauravandoore
10
1.6k
hatefulcrawdad
257
17k
shpigford
165
19k
colly
188
14k
zakiwarfel
88
3.4k
chrislema
173
14k
ddemaree
273
31k
marktimemedia
7
400
Transcript
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の簡単な紹介
stand.fmの簡単な紹介
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にも耐えられるようになりました ◦ コメント流速にかかわらず負担が一定
まとめ
まとめ • ユーザと開発者の両方に最適な体験を届けたい ◦ そのためには快適に開発・利用できる環境が必要 • 便利コンポーネントの整備やリファクタリングは重要 ◦ 気持ちよく開発してもらう •
アプリのパフォーマンスを維持することが大事 ◦ どんな状態でも体験を損なわないようにする
None