Downloaded 32 times
![[UE4]自動テストでもっと楽したい！](https://cdn.slidesharecdn.com/ss_thumbnails/ue4automationtest-190527101956-thumbnail.jpg?width=640&height=640&fit=bounds)
Observableで非同期処理
- 1.
- 2. 自己紹介 • とりすーぷ（@toRisouP） • 株式会社バーチャルキャスト •Unityクライアント開発 • 人類を美少女にする仕事をしてます
- 3.
- 4.
- 5.
- 6. 非同期処理≠マルチスレッド処理 • 非同期だからといってマルチスレッド処理とは限らない • シングルスレッドでも非同期処理はできる •マルチスレッドでも同期処理で書くことはできる • 一緒くたにされることがよくあるが、厳密にいうと違う概念
- 7.
- 8.
- 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. 独自実装 • 非同期処理の機構を自前で作ってしまう方法 • 単純なものならわりとすぐ作れる •実行コンテキスト制御や、キャンセル周りを考えるとツライ
- 18.
- 19. 以前、話しました • Task vsObservable • https://niconare.nicovideo.jp/watch/kn3081
- 20.
- 21.
- 22. 今回話したい内容 • UniRx（Observable）の非同期処理への活用方法 • UniRxは「イベント処理のライブラリ」として浸透しちゃった •UniRxは非同期処理にも使えるよ、という話がしたい
- 23.
- 24. Observable • Reactive Extensionsに登場するメッセージ処理のオブジェクト •「ストリーム」とか呼んでたりするアレの正式名称 • Message Source + Operator + Scheduler で構成される
- 25.
- 26.
- 27. イベント処理 • 何かの条件を満たしたときにメッセージを発行する • メッセージを受け取った側が、何かの処理を実行する •発行されるメッセージ数は不定 （0個だったり、有限個だったり、無限だったり）
- 28. 非同期処理 • 処理が終わったときに、メッセージを発行する • メッセージを受け取った側が、何かの処理を実行する •発行されるメッセージ数は必ず1個 （成功 or 失敗 で必ずどちらかの結果を1つ返す）
- 29. Observableから見ると • イベント処理 • OnNextを複数個発行する（0～N個、無限もあり） •非同期処理 • OnNext必ず1つ発行する（成功時） • 失敗時はOnErrorを返す
- 30. どっちもObservableの表現範囲内 • 非同期処理もイベント処理も等価に扱える • メッセージの発行のパターンが異なるだけ •「イベント処理」のメッセージ長を1に固定したら「非同期処理」
- 31.
- 32.
- 33. コルーチンと比較 • コルーチンは結構プリミティブに近い作り • 非同期処理の機構だけど、それほど機能は多くない •実行結果を返せない、エラーハンドリングしてくれない、等 • Observableで書くと非同期処理がどれくらいキレイになるのか
- 34. 例：HTTP GET • WWWでGETする処理を比較 •コルーチンで書いた版 • コルーチンをObservableに変換した版
- 35. コルーチン版 • HTTP GETする •結果をログに出すだけ
- 36.
- 37.
- 38.
- 39.
- 40. コルーチン • コルーチンに結果を返す機能はない • デリゲートを使ったコールバックで無理やり返すしかない •結果をキャッシュしておいて後で使う、がやりにくい
- 41.
- 42. Observableの場合 • 結果を「IObservable<T>」で扱うことができる • 変数に代入して取り回せる •結果をキャッシュしておいて後で取り出せる（ 要PublishLast）
- 43.
- 44.
- 45.
- 46. 直列処理 • コールバック手法と相性がよくない • ネスト地獄になる •途中で処理分岐が入るとぐちゃぐちゃになる
- 47.
- 48.
- 49.
- 50.
- 51.
- 52. 並行処理 • Unityコルーチンでは並行で結果を待ち受ける機能はない • 実行はできるけど、結果を待てない •自作する必要がある • めんどい
- 53.
- 54.
- 55. コルーチンとの比較 まとめ • Observableを使えば楽になる部分が多い •コルーチンと比べて結果の取り扱いが非常に楽になる • 処理の連結も楽にできる
- 56.
- 57.
- 58.
- 59. 紹介する機能 • ContinueWith • エラーハンドリング •Observable.Start() • Observable.Create() • AsyncSubject • PublishLast() • Observable.FromCoroutine() • ToYieldInstruction()
- 60.
- 61. ContinueWith • Observableを直列に連結するときにつかうOperator • 引数はFunc<T, IObservable<TResult>> • SelectManyの軽量化版（OnNext 1回限定で動作）
- 62.
- 63. 失敗したときどうするの？ • 失敗時のリカバリをキレイに書ける？ • ログに出して終わり •リトライする • 別の処理にフォールバックする • 処理を諦める • 失敗を握りつぶす
- 64. Operatorでエラーハンドリング • ObservableはOperatorでエラーハンドリングできる • すごいいっぱい機能がある •async/awaitには無い、Observableの強み
- 65.
- 66.
- 67.
- 68.
- 69. OnErrorRetry • Retryの強化版 • Catch+ Retry • 挙動をかなり細かく制御できる
- 70.
- 71. エラーハンドリングまとめ • Operatorがかなり優秀 • 組み合わせるだけでそれなりのエラーハンドリングができる •Retryは使用箇所を見極めよう • リトライすれば問題が改善するかもしれない場面でのみ使おう • 良：ネットワーク通信（リトライで改善するかもしれない） • 悪：ローカルファイルの読み込み（ファイルが無い場合、リトライしても無い）
- 72.
- 73. AsyncSubject • 非同期処理向けSubject • メッセージを1個だけキャッシュする機能を持つ •OnCompletedすることで状態が確定する
- 74. 普通のSubject（AsyncSubjectではないやつ） • Subject • メッセージ発行の根源になるオブジェクト •IObservable<T>とIObserver<T>を両方とも実装している
- 75.
- 76.
- 77.
- 78. 用途 • 非同期処理の結果通知にそのまま使える • JavaScriptのPromiseみたいな使い方をする •処理の結果をキャッシュして保持させる • 1回実行した非同期処理の結果を使いませる
- 79. 応用例：コンポーネントの初期化順序 • コンポーネントの初期化順序が問題になる場面 • シーン開始直後などの初期化フェーズ •Aが先に実行されてないと、Bの処理で失敗する • 苦肉の策でScript Execution Orderでゴリ押し解決するの…？
- 80. 例 • PlayerProvider :Playerを生成して提供する • PlayerInitializer : 生成されたPlayerの初期設定を実行する
- 81.
- 82.
- 83. 例：コンポーネントの処理順序 • この２つのコンポーネントは実行順序が重要 • PlayerProvider-> PlayerInitializer • 順序が崩れるとエラーが出て動かない
- 84. 非同期処理にして解決する • 「初期化は非同期処理が連鎖する」という考え方に切り替える • 非同期的にPlayerが初期化される、と考える •PlayerInitializerはその非同期処理を待つ
- 85.
- 86.
- 87. 実行順序を気にしなくてよくなった • 必ずPlayerProvider ->PlayerInitializerの順番で実行される • AsyncSubjectを使えば非同期処理に変換できる • もしPlayerProviderの処理が後から 本当に非同期処理になっても、PlayerInitializer側は変更不要
- 88. ちなみに：await • AsyncSubjectはAwaitable • async/awaitで待機できる •IObservableのGetAwaiter()は、内部でAsyncSubjectに変換している
- 89.
- 90. AsyncSubject まとめ • 非同期処理を扱うためのSubject •そのまま非同期処理の結果通知に使える • コンポーネントの順序関係の整理にも使えそう • 後から本当の非同期処理が混ざってきても対応できる • async/awaitが使えるなら記法もほとんど変えずに済む
- 91.
- 92.
- 93.
- 94. Observableの性質 • 基本的に、Subscribe()されるまで動かない • Subscribe()される前の状態は「仮止め」みたいな状態で放置される •Subscribe()されると、はじめてインスタンス化されて動く • こういう状態のObservableを「Cold Observable」と呼ぶ
- 95.
- 96.
- 97.
- 98.
- 99. Cold Observable • 仮止め状態で浮いているObservableのこと •Subscribeされて初めてインスタンス化して起動する • Subscribeされた回数分インスタンス化される
- 100.
- 101.
- 102.
- 103.
- 104. LINQと多重foreach • こういう書き方をするとちゃんと動かない ← ここ ←ここ １回目のforeachと、２度目のforeachとで、 別々のWebSocketClientが生成されてしまう
- 105.
- 106.
- 107.
- 108.
- 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()を事前に実行すればよいじゃん！
- 113.
- 114.
- 115. 例：Subjectを使ってHot変換 • Subjectを使って、対象を先にSubscribe()する • 以降のObserverはSubjectの方を代わりにSubscribeする ←ここのSubscribe()でObservable.Intervalが起動する
- 116.
- 117. AsyncSubjectでもHot変換できる • Subjectの代わりにAsyncSubjectも使える • 結果をキャッシュするという性質がObservableに付与できる •非同期処理を扱うObservableと相性がとても良い
- 118.
- 119.
- 120.
- 121. Hot変換 まとめ • ColdObservableという性質を覚えよう • Subjectを使えばHotに変換できる • AsyncSubjectでHot変換すると非同期処理との相性がよくなる
- 122.
- 123.
- 124. 仲間たち（中のSubjectが異なる） • Publish() • Subject •Publish(T initValue) • BehaviorSubject • PublishLast() • AsyncSubject • Replay() • ReplaySubject
- 125. PublishLast()の使い方 • Observableの末尾につけて、その後にConnect()を呼ぶ • 返り値はIConnectableObservable •中でAsyncSubjectを作って、Subscribeしてくれる • ただしIConnectableObservableのリークには注意
- 126. PublishLast()を使うメリット • Observableを先走りさせることができる • 非同期処理を先に実行しておける •結果をキャッシュできる • 結果を後から好きなタイミングで取り出せる • 同じ処理を重複して実行させなくてすむ
- 127.
- 128. PublishLast()を使うデメリット • 「失敗」もキャッシュしてしまう • キャッシュされた結果に対して、Retryはしても無意味 •エラーハンドリング不可能になってしまう
- 129.
- 130.
- 131.
- 132. PublishLast()の使いどころ • 失敗がありうる場所では使わない方がいいかも • PublishLast()する前にエラーハンドリングを書く •PublishLast()を使わずにColdのままにしておく • このあたりはケース・バイ・ケース
- 133. PublishLast() まとめ • PublishLast()でお手軽にHot変換ができる •非同期処理との相性がよい • ただし、デメリットもある点に注意
- 134.
- 135.
- 136.
- 137.
- 138. Observable.Start()はCold • Observable.Start()は、Subscribe()しないと起動しない • 先に処理を走らせておいて、 後から結果を取り出したいときは、PublishLast()を使おう •Observable.ToAsync()…？知らない子ですね…。
- 139. Observable.Start() まとめ • 同期処理を非同期処理化するのに便利 •サクッとマルチスレッド処理化できてよい
- 140.
- 141.
- 142.
- 143.
- 144.
- 145.
- 146. 用途は無限にある • なんでもできる • 中でスレッド起動してマルチスレッド処理 •既存の非同期処理を隠蔽
- 147.
- 148.
- 149.
- 150.
- 151. SubscribeOn() • Subscribe()を実行するコンテキストを切り替える機能 • 指定したScheduler上でSubscribe()を実行する •例：ThreadPool上にスイッチしてからSubscribe() • 例：Unityメインスレッドに戻ってきてからSubscribe()
- 152.
- 153.
- 154.
- 155. SubscribeOn()と組み合わせる • SubscribeOn()でThreadPoolを指定 • 処理をThreadPoolに移動できる •ObserveOnMainThread()で結果メインスレッドに戻す
- 156. Observable.Create() + SubscribeOn() •Observable.Createの実行コンテキストを切り替えられる • 呼び出し側でマルチスレッド処理に変更できる
- 157. Observable.Create まとめ • なんでもできる •既存の非同期処理をObservableに変換したりできる • SubscribeOnと組み合わせるとより便利 • とりあえず中身を同期で書いておいて、 実行時にマルチスレッドで非同期化できる
- 158.
- 159.
- 160.
- 161. 種類 • Observable.FromCoroutine /FromMicroCoroutine • コルーチンが終了するのを待てる • Observable.FromCoroutineValue • コルーチンのyield return した値を取り出せる • Observable.FromCoroutine<T> / FromMicroCoroutine<T> • コルーチンから任意のメッセージを発行できる
- 162.
- 163.
- 164.
- 165. 使いみち • コルーチンから結果を取り出すことができるようになる • コルーチン最大の欠点を解消できる •手続き処理からObservableを作れる • Operatorだけでは表現しにくい処理がコルーチンを使うと 比較的かんたんに書けたりすることもある
- 166.
- 167. Observable.FromCoroutineまとめ • コルーチンからObservableへ変換できる • コルーチンから結果を取り出すのが容易になる •手続き処理ベースでObservableを作れる
- 168.
- 169.
- 170.
- 171.
- 172.
- 173. 使いみち • async/awaitっぽいことがコルーチンで実現できる • 非同期処理を同期っぽく書くことができる •async/awaitと比べると冗長ではある
- 174. 合わせ技 • Observable.FromCoroutine &ToYieldInstruction • かなりの表現力が得られる • async/awaitがないUnityバージョンでも十分戦えるだけの力はある
- 175.
- 176.
- 177.
- 178.
- 179.
- 180.
- 181.
- 182.
- 183.
- 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.
- 190.
- 191. まとめ • 非同期処理とは何なのかを覚えよう • 結果を待たない処理 •いろんな手法でコストを下げることができる • Observableは非同期処理に使える • UniRxはイベント処理以外にも使える • Hot/Coldの性質だけは本当に注意