Observableで非同期処理
•
5 recomendaciones•10,646 vistas
Unity非同期完全に理解した勉強会での発表資料です https://connpass.com/event/95696/
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Más de torisoup
Más de torisoup (15)
Último
Último (9)
Observableで非同期処理
- 2. 自己紹介 • とりすーぷ（@toRisouP） • 株式会社バーチャルキャスト • Unityクライアント開発 • 人類を美少女にする仕事をしてます
- 3. 非同期について
- 4. 非同期処理って何？
- 6. 非同期処理≠マルチスレッド処理 • 非同期だからといってマルチスレッド処理とは限らない • シングルスレッドでも非同期処理はできる • マルチスレッドでも同期処理で書くことはできる • 一緒くたにされることがよくあるが、厳密にいうと違う概念
- 7. 非同期処理の難しさ
- 9. 非同期処理の難しいところ • 実行結果の取り扱い • 直列/並行処理 • エラーハンドリング • 実行キャンセル • 実行コンテキストの制御（マルチスレッド時の制御）
- 10. 非同期処理 vs 人類 • 非同期処理へ無防備に立ち向かうと人は死ぬ • 非同期処理は愚直に書くとすぐ手に負えなくなる • いろいろな対策手法が考案されてきた
- 11. 非同期処理の手法
- 12. Unityで今の所使えるもの • Unityコルーチン • async/await + Task • UniRx ( Observable ) • UniRx ( UniRx.Async ) • 独自実装
- 13. Unityコルーチン • Unityメインスレッド上で処理を待ち受ける機構 • 結果を返すことを考慮していない • GameObjectと処理がひもづく
- 14. async/await + Task • C#の言語機能として用意されている機構 • Unityの場合は.NET 4.xモードにしたら使える • サクッと非同期処理が書けて非常に使いやすい
- 15. UniRx ( Observable ) • UniRxのメイン機能 • Taskの拡張版みたいなもの • 同梱されているOperatorやSchedulerが便利
- 16. UniRx ( UniRx.Async ) • ascyn/awaitとTaskをUnity向けに最適化したもの • 詳しくはneueccさんの講演で
- 17. 独自実装 • 非同期処理の機構を自前で作ってしまう方法 • 単純なものならわりとすぐ作れる • 実行コンテキスト制御や、キャンセル周りを考えるとツライ
- 19. 以前、話しました • Task vs Observable • https://niconare.nicovideo.jp/watch/kn3081
- 20. ここまでが前置き
- 21. 本題
- 22. 今回話したい内容 • UniRx（Observable）の非同期処理への活用方法 • UniRxは「イベント処理のライブラリ」として浸透しちゃった • UniRxは非同期処理にも使えるよ、という話がしたい
- 23. Observable
- 24. Observable • Reactive Extensionsに登場するメッセージ処理のオブジェクト • 「ストリーム」とか呼んでたりするアレの正式名称 • Message Source + Operator + Scheduler で構成される
- 26. イベント処理と非同期処理
- 27. イベント処理 • 何かの条件を満たしたときにメッセージを発行する • メッセージを受け取った側が、何かの処理を実行する • 発行されるメッセージ数は不定 （0個だったり、有限個だったり、無限だったり）
- 28. 非同期処理 • 処理が終わったときに、メッセージを発行する • メッセージを受け取った側が、何かの処理を実行する • 発行されるメッセージ数は必ず1個 （成功 or 失敗 で必ずどちらかの結果を1つ返す）
- 29. Observableから見ると • イベント処理 • OnNextを複数個発行する（0～N個、無限もあり） • 非同期処理 • OnNext必ず1つ発行する（成功時） • 失敗時はOnErrorを返す
- 30. どっちもObservableの表現範囲内 • 非同期処理もイベント処理も等価に扱える • メッセージの発行のパターンが異なるだけ • 「イベント処理」のメッセージ長を1に固定したら「非同期処理」
- 31. Observableのメリット
- 32. コルーチンと比較してみよう
- 33. コルーチンと比較 • コルーチンは結構プリミティブに近い作り • 非同期処理の機構だけど、それほど機能は多くない • 実行結果を返せない、エラーハンドリングしてくれない、等 • Observableで書くと非同期処理がどれくらいキレイになるのか
- 34. 例：HTTP GET • WWWでGETする処理を比較 • コルーチンで書いた版 • コルーチンをObservableに変換した版
- 35. コルーチン版 • HTTP GETする • 結果をログに出すだけ
- 37. Observable化 • 中身はコルーチンだけど、ガワはObservableになった • 「Observableで包んだ」というのが大事 • これだけで十分使えるようになる
- 40. コルーチン • コルーチンに結果を返す機能はない • デリゲートを使ったコールバックで無理やり返すしかない • 結果をキャッシュしておいて後で使う、がやりにくい
- 42. Observableの場合 • 結果を「IObservable<T>」で扱うことができる • 変数に代入して取り回せる • 結果をキャッシュしておいて後で取り出せる（ 要PublishLast）
- 43. Observableで結果を扱う
- 46. 直列処理 • コールバック手法と相性がよくない • ネスト地獄になる • 途中で処理分岐が入るとぐちゃぐちゃになる
- 50. コールバックではすぐ破綻が見える • 正常系の処理だけでもすでに読みにくい • エラーハンドリングが入るとさらに処理が分岐する • 途中で例外飛んだらどうするの？
- 51. Observableで直列処理を書く • ContinueWith (またはSelectMany)で連結するだけ • フラットな形式で書ける
- 52. 並行処理 • Unityコルーチンでは並行で結果を待ち受ける機能はない • 実行はできるけど、結果を待てない • 自作する必要がある • めんどい
- 55. コルーチンとの比較 まとめ • Observableを使えば楽になる部分が多い • コルーチンと比べて結果の取り扱いが非常に楽になる • 処理の連結も楽にできる
- 57. 覚えておきたいUniRxの機能
- 59. 紹介する機能 • ContinueWith • エラーハンドリング • Observable.Start() • Observable.Create() • AsyncSubject • PublishLast() • Observable.FromCoroutine() • ToYieldInstruction()
- 60. ContinueWith
- 61. ContinueWith • Observableを直列に連結するときにつかうOperator • 引数は Func<T, IObservable<TResult>> • SelectManyの軽量化版（OnNext 1回限定で動作）
- 62. エラーハンドリング
- 63. 失敗したときどうするの？ • 失敗時のリカバリをキレイに書ける？ • ログに出して終わり • リトライする • 別の処理にフォールバックする • 処理を諦める • 失敗を握りつぶす
- 64. Operatorでエラーハンドリング • ObservableはOperatorでエラーハンドリングできる • すごいいっぱい機能がある • async/awaitには無い、Observableの強み
- 69. OnErrorRetry • Retryの強化版 • Catch + Retry • 挙動をかなり細かく制御できる
- 71. エラーハンドリングまとめ • Operatorがかなり優秀 • 組み合わせるだけでそれなりのエラーハンドリングができる • Retryは使用箇所を見極めよう • リトライすれば問題が改善するかもしれない場面でのみ使おう • 良：ネットワーク通信（リトライで改善するかもしれない） • 悪：ローカルファイルの読み込み（ファイルが無い場合、リトライしても無い）
- 72. AsyncSubject
- 73. AsyncSubject • 非同期処理向けSubject • メッセージを1個だけキャッシュする機能を持つ • OnCompletedすることで状態が確定する
- 74. 普通のSubject（AsyncSubjectではないやつ） • Subject • メッセージ発行の根源になるオブジェクト • IObservable<T>とIObserver<T>を両方とも実装している
- 77. AsyncSubjectの使い方
- 78. 用途 • 非同期処理の結果通知にそのまま使える • JavaScriptのPromiseみたいな使い方をする • 処理の結果をキャッシュして保持させる • 1回実行した非同期処理の結果を使いませる
- 79. 応用例：コンポーネントの初期化順序 • コンポーネントの初期化順序が問題になる場面 • シーン開始直後などの初期化フェーズ • Aが先に実行されてないと、Bの処理で失敗する • 苦肉の策でScript Execution Orderでゴリ押し解決するの…？
- 80. 例 • PlayerProvider : Playerを生成して提供する • PlayerInitializer : 生成されたPlayerの初期設定を実行する
- 81. 例：PlayerProvider
- 83. 例：コンポーネントの処理順序 • この２つのコンポーネントは実行順序が重要 • PlayerProvider -> PlayerInitializer • 順序が崩れるとエラーが出て動かない
- 84. 非同期処理にして解決する • 「初期化は非同期処理が連鎖する」という考え方に切り替える • 非同期的にPlayerが初期化される、と考える • PlayerInitializerはその非同期処理を待つ
- 85. 例：非同期化
- 87. 実行順序を気にしなくてよくなった • 必ずPlayerProvider -> PlayerInitializerの順番で実行される • AsyncSubjectを使えば非同期処理に変換できる • もしPlayerProviderの処理が後から 本当に非同期処理になっても、PlayerInitializer側は変更不要
- 88. ちなみに：await • AsyncSubjectはAwaitable • async/awaitで待機できる • IObservableのGetAwaiter()は、内部でAsyncSubjectに変換している
- 90. AsyncSubject まとめ • 非同期処理を扱うためのSubject • そのまま非同期処理の結果通知に使える • コンポーネントの順序関係の整理にも使えそう • 後から本当の非同期処理が混ざってきても対応できる • async/awaitが使えるなら記法もほとんど変えずに済む
- 91. PublishLast()
- 93. Hot変換？
- 94. Observableの性質 • 基本的に、Subscribe()されるまで動かない • Subscribe()される前の状態は「仮止め」みたいな状態で放置される • Subscribe()されると、はじめてインスタンス化されて動く • こういう状態のObservableを「Cold Observable」と呼ぶ
- 99. Cold Observable • 仮止め状態で浮いているObservableのこと • Subscribeされて初めてインスタンス化して起動する • Subscribeされた回数分インスタンス化される
- 104. LINQと多重foreach • こういう書き方をするとちゃんと動かない ← ここ ← ここ １回目のforeachと、２度目のforeachとで、 別々のWebSocketClientが生成されてしまう
- 109. LINQとRxはよく似ている • ObservableとEnumerableが双対の関係 • 双対の概念だけあって、結構似ている • LINQのときの対処方も、Observableへ適用できるのでは？
- 110. Cold to Hot • Cold ObservableをHotにするには？
- 111. Cold to Hot • Cold ObservableをHotにするには？ • LINQでいう「foreachを事前に実行する」的なことをすればよい
- 112. Cold to Hot • Cold ObservableをHotにするには？ • LINQでいう「foreachを事前に実行する」的なことをすればよい • Subescirbe()を事前に実行すればよいじゃん！
- 115. 例：Subjectを使ってHot変換 • Subjectを使って、対象を先にSubscribe()する • 以降のObserverはSubjectの方を代わりにSubscribeする ← ここのSubscribe()でObservable.Intervalが起動する
- 117. AsyncSubjectでもHot変換できる • Subjectの代わりにAsyncSubjectも使える • 結果をキャッシュするという性質がObservableに付与できる • 非同期処理を扱うObservableと相性がとても良い
- 119. AsyncSubjectでHot変換 • 先に処理を実行しつつ、その結果をキャッシュできる 関数を呼んだ時点でObservable.FromCoroutineが実行 （コルーチンが稼働しはじめる）
- 121. Hot変換 まとめ • Cold Observableという性質を覚えよう • Subjectを使えばHotに変換できる • AsyncSubjectでHot変換すると非同期処理との相性がよくなる
- 122. PublishLast() の話にもどる
- 124. 仲間たち（中のSubjectが異なる） • Publish() • Subject • Publish(T initValue) • BehaviorSubject • PublishLast() • AsyncSubject • Replay() • ReplaySubject
- 125. PublishLast()の使い方 • Observableの末尾につけて、その後にConnect()を呼ぶ • 返り値はIConnectableObservable • 中でAsyncSubjectを作って、Subscribeしてくれる • ただしIConnectableObservableのリークには注意
- 126. PublishLast()を使うメリット • Observableを先走りさせることができる • 非同期処理を先に実行しておける • 結果をキャッシュできる • 結果を後から好きなタイミングで取り出せる • 同じ処理を重複して実行させなくてすむ
- 128. PublishLast()を使うデメリット • 「失敗」もキャッシュしてしまう • キャッシュされた結果に対して、Retryはしても無意味 • エラーハンドリング不可能になってしまう
- 132. PublishLast()の使いどころ • 失敗がありうる場所では使わない方がいいかも • PublishLast()する前にエラーハンドリングを書く • PublishLast()を使わずにColdのままにしておく • このあたりはケース・バイ・ケース
- 133. PublishLast() まとめ • PublishLast()でお手軽にHot変換ができる • 非同期処理との相性がよい • ただし、デメリットもある点に注意
- 135. Observable.Start()
- 136. Observable.Start() • Task.Run()とほぼ同じ機能 • Func<TResult>を実行し、結果をOnNext()として出力する • Schedulerの指定も可能
- 138. Observable.Start()はCold • Observable.Start()は、Subscribe()しないと起動しない • 先に処理を走らせておいて、 後から結果を取り出したいときは、PublishLast()を使おう • Observable.ToAsync()…？知らない子ですね…。
- 139. Observable.Start() まとめ • 同期処理を非同期処理化するのに便利 • サクッとマルチスレッド処理化できてよい
- 140. Observable.Create()
- 142. 使い方
- 146. 用途は無限にある • なんでもできる • 中でスレッド起動してマルチスレッド処理 • 既存の非同期処理を隠蔽
- 149. ニフクラSDKをObservable化
- 150. ニフクラSDKをObservable化
- 151. SubscribeOn() • Subscribe()を実行するコンテキストを切り替える機能 • 指定したScheduler上でSubscribe()を実行する • 例：ThreadPool上にスイッチしてからSubscribe() • 例：Unityメインスレッドに戻ってきてからSubscribe()
- 155. SubscribeOn()と組み合わせる • SubscribeOn()でThreadPoolを指定 • 処理をThreadPoolに移動できる • ObserveOnMainThread()で結果メインスレッドに戻す
- 156. Observable.Create() + SubscribeOn() • Observable.Createの実行コンテキストを切り替えられる • 呼び出し側でマルチスレッド処理に変更できる
- 157. Observable.Create まとめ • なんでもできる • 既存の非同期処理をObservableに変換したりできる • SubscribeOnと組み合わせるとより便利 • とりあえず中身を同期で書いておいて、 実行時にマルチスレッドで非同期化できる
- 161. 種類 • Observable.FromCoroutine / FromMicroCoroutine • コルーチンが終了するのを待てる • Observable.FromCoroutineValue • コルーチンのyield return した値を取り出せる • Observable.FromCoroutine<T> / FromMicroCoroutine<T> • コルーチンから任意のメッセージを発行できる
- 163. 例：コルーチンからObservableへ
- 164. 例：コルーチンからObservableへ
- 165. 使いみち • コルーチンから結果を取り出すことができるようになる • コルーチン最大の欠点を解消できる • 手続き処理からObservableを作れる • Operatorだけでは表現しにくい処理がコルーチンを使うと 比較的かんたんに書けたりすることもある
- 167. Observable.FromCoroutineまとめ • コルーチンからObservableへ変換できる • コルーチンから結果を取り出すのが容易になる • 手続き処理ベースでObservableを作れる
- 168. ToYieldInstruction()
- 170. 使い方
- 173. 使いみち • async/awaitっぽいことがコルーチンで実現できる • 非同期処理を同期っぽく書くことができる • async/awaitと比べると冗長ではある
- 174. 合わせ技 • Observable.FromCoroutine & ToYieldInstruction • かなりの表現力が得られる • async/awaitがないUnityバージョンでも十分戦えるだけの力はある
- 175. 合わせ技
- 176. 合わせ技
- 177. 合わせ技
- 179. 止まらない例
- 184. ToYieldInstruction() まとめ • コルーチン上でObservableを待機できる • OnCompleted()がくるまで待ち受ける • 非同期処理の待機に使える • async/awaitっぽくObservableが待てる • Observable.FromCoroutine()とあわせるとさらにつよい
- 185. まとめ
- 186. 非同期処理 • 結果をすぐに返さない処理 • 結果を待たずに関数呼び出しが終了する処理 • マルチスレッド処理とは別の概念
- 187. 非同期処理の手法 • 非同期処理はやり方がいくつかある • async/await + Task • Unityコルーチン • Observable • UniRx.Async
- 188. 結局何を使えばいいの？ 1. async/awaitを最優先に使う 2. async/awaitが使えない環境の場合、 またはasync/awaitでは表現力が足りない場合、 Observable(UniRx)を使う 3. Observableも使えない場合は独自機構を作ってがんばる
- 189. Observableは非同期処理に使える • イベント処理だけでなく、非同期処理にも応用ができる • Observableには非同期処理で使うと便利な機能がたくさんある • ただしHot/Coldの性質だけは注意
- 190. 本当にまとめ
- 191. まとめ • 非同期処理とは何なのかを覚えよう • 結果を待たない処理 • いろんな手法でコストを下げることができる • Observableは非同期処理に使える • UniRxはイベント処理以外にも使える • Hot/Coldの性質だけは本当に注意