Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
stand.fmにおける開発体験とパフォーマンスの向上 / Development Expe...
Search
stand.fm
January 21, 2021
Programming
1
7.4k
stand.fmにおける開発体験とパフォーマンスの向上 / Development Experience and Performance improvement
stand.fm
January 21, 2021
Tweet
Share
More Decks by stand.fm
See All by stand.fm
stand.fm会社紹介資料
standfm
0
530
stand.fmのTypeScriptへの移行と活用/migrating-to-typescript-standfm
standfm
0
2.3k
stand.fmの最近の取り組み: アプリ起動速度の改善/improvement-of-speed-startup-app
standfm
4
2.6k
ReactNative製アプリがAndroidだと遅いという問題に立ち向かった話/the problem that React Native apps are slow on Android
standfm
1
3.1k
LIVEの負荷対策と監視について / About LIVE load countermeasures and monitoring
standfm
0
8.4k
声でつながる、 優しい世界を創るUI/UX
standfm
4
520
stand.fm(Android)におけるreact-native-track-playerの改善/Improvement of react-native-track-player on standfm Android app
standfm
0
340
React NativeアプリでコラボLIVE配信 / Collaboration Live Streaming with React Native App
standfm
1
3.9k
エンジニア向け会社紹介資料 / company deck for engineers
standfm
7
67k
Other Decks in Programming
See All in Programming
Deoptimization: How YJIT Speeds Up Ruby by Slowing Down / RubyKaigi 2025
k0kubun
0
860
Rollupのビルド時間高速化によるプレビュー表示速度改善とバンドラとASTを駆使したプロダクト開発の難しさ
plaidtech
PRO
1
180
プロダクト横断分析に役立つ、事前集計しないサマリーテーブル設計
hanon52_
2
450
Vibe Coding の話をしよう
schroneko
10
2.6k
PHPで書いたAPIをGoに書き換えてみた 〜パフォーマンス改善の可能性を探る実験レポート〜
koguuum
0
170
Lambda(Python)の リファクタリングが好きなんです
komakichi
3
210
Empowering Developers with HTML-Aware ERB Tooling @ RubyKaigi 2025, Matsuyama, Ehime
marcoroth
2
740
リアルタイムレイトレーシング + ニューラルレンダリング簡単紹介 / Real-Time Ray Tracing & Neural Rendering: A Quick Introduction (2025)
shocker_0x15
1
310
Defying Front-End Inertia: Inertia.js on Rails
skryukov
0
490
ウォンテッドリーの「ココロオドル」モバイル開発 / Wantedly's "kokoro odoru" mobile development
kubode
1
140
Enterprise Web App. Development (1): Build Tool Training Ver. 5
knakagawa
1
120
Sharing features among Android applications: experience feedback
jbvincey
0
110
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Being A Developer After 40
akosma
91
590k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.7k
Scaling GitHub
holman
459
140k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.1k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.8k
Site-Speed That Sticks
csswizardry
5
500
Optimising Largest Contentful Paint
csswizardry
36
3.2k
Building an army of robots
kneath
304
45k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
A better future with KSS
kneath
239
17k
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