2015年を振り返る
- 2015-12-31
振り返るシリーズ第四弾。去年の目標は
テーマは「クライアントサイドとサーバーサイドをC#で統一することのメリットの実証」「さらにリアルタイムネットワークもC#で統一」「のためのヒットアプリケーションの創出」です。指向はあんま変わってないんですが、より具体的に。来年は動く年かな、といったところ
ようするに会社(グラニ/CTO)でゲーム出して実証する。であり、結果としては……。はい。なので、本当に来年こそはね。というところです。
C#
今年はVS2015のリリースということもあり、かなりRoslynに傾倒しました。その集大成としてのまとめは実例からみるC#でのメタプログラミング用法集にスライドで出してますが、その後にもAnalyzerだけではなく、Roslyn C# Scriptingによる実行できるコンフィグの手法と実活用例やWorkspace APIを使ったプロジェクトコードからのT4生成での応用例といった形で、ただたんに触ってみた、ではなくて、実用的にどう使えるのか、の応用例をきっちり掲示できたんじゃないかと思います。これらの話は実際に使っているもので、便利、かつ世界が広がったのは確かなので、Roslynはこれからどんどん応用的に使われるといいかな。
また、いつになくライブラリ書いてました。会社で必要だから作ってったという面も大きいんですけれど、こうして並べると、実際結構やりましたね、えらいえらい。
まずAPIサーバーとしてLightNodeという自家製フレームワークを採用しているので、Glimpse対応とSwagger対応を入れてます。この対応は大正解で、もはやGlimpseとSwaggerなしでAPI開発していくのは無理ゲーとすら思える。超絶便利。Glimpseは主要開発者がMicrosoft入りしてより専任して開発することになったのと、Swaggerはもはやウェッブ標準といってもいい立ち位置を確立したということで、どちらもメジャーなテクノロジとなったことも含めて、技術選定にも成功したと言えるでせう。ASP.NET 5がまだまだ時間かかるので様子見したのも含めて、現状での最適解ではあるんじゃないかな、と。
RedisライブラリのCloudStructuresもGlimpse対応とStackExchange.Redis対応によって、相当リッチなものになりました。特にGlimpseのは相当気合入れたので充実してて実用度超絶高い。とはいえ本体部分は原則的には薄いラッパーなので、粛々とやってきます、というところですね。
LINQ to BigQueryはLINQPad Driverを作りました！これで実用度が飛躍的に上がりました。世間的にもデータ分析はBigQueryで決まりだよね！という流れが出来上がった年なわけですが、ここも乗り遅れずというか、むしろ引っ張る側に回れたのではないかと自負するところです。あとLINQPadにも相当詳しくなった。
今年最後の新顔はEtwStreamで、↑でLINQPadに詳しくなった結果、応用例が頭に浮かんで一気に実用に載せられました。ETW(Event Tracing for Windows)のビューアーとしてまともに使える世界唯一の解といっても過言ではない（むしろ今までのフベンサがヤバすぎた……）。年末にはRoslyn C# Scriptingによる実行できるコンフィグというコンセプトを打ち出したOut-of-Process Serviceも追加していて、来年はこれの稼働実績を作っていきたいところです。
変わり種だけど誰にとっても実用度100億なのはOpen on GitHubというVS拡張で、もはやこれなしでぎっはぶでコミュニケーションを取るのは無理なのでは疑惑もあるほどに神拡張。地味に12/29にVer 1.4.0のアップデート出してます。
そしてUniRx。今年はお陰様で大躍進の年で、GitHubスター順でも、GitHubで公開されてるUnity用ライブラリでは世界4位と、中々に中々の感じで、いやほんと良かった。
年の始めではReacitvePropertyやPresenterBaseの導入によるModel-View-(Reactive)Presenterというコンセプトの確立が地味に大きめ（ちなみに私は設計とかってこのレベルの話こそ最も大事だと思ってて、コードを小奇麗にするようなレベルの話は設計、ですかねえ？とは思ってる）。真ん中でObservableTriggers、そして年末駆け込みのUniRx 5.0で完全書き直しによるパフォーマンスとデバッガビリティの向上。もはやUniRxなしで書けと言われると困りすぎるぐらいに必要不可欠な存在となれました。
UniRxが成功したポイントは、Reactive Extensions自体が素晴らしいコンセプトで実績もある、というのも勿論そうなんですが、UniRx自体の、Unityへフィットさせるための繋ぎ方の工夫の面も大きいとは自負してます。あまり頭でっかちにならずに柔軟に作り込めたのが良かった。ReacitvePropertyなんかも、実装はシンプルですが、（.NET版を作った時の）コンセプト立証と実装には普通に時間かけてたし、そもそもコロンブスの卵的なところもありましたし、更にそのUnity化でも、削ぎ落とし方には相当神経使ってます（ゴテゴテ足すだけが設計ではない）。
また、お陰様でUnityのスクリプティングと、そしてRxには詳しすぎるほどに詳しくなれました、というかRxに関しては実際隅から隅まで理解した……。
現在未公開だけど予定があるものとしてはPhotonWireというUnity/Photon Server用の非同期RPCフレームワークがあります。これは来年の初頭に公開できればな、ですかねー。
お仕事
書いたライブラリは基本的に会社でフルに使ってるものなので、成果っちゃあ成果です。が、集中力散漫な年でした。成果として些かライブラリ過多になったのは、それが時間の捻出が比較的しやすい（土日とかにちょっと徹夜して気合いれればグッと形にできたりするんで）というのが大きいですね。細切れな時間で、いまいちうまくプロダクトそのものにコミットできなかったのは減点度大きめで、非常に良くない。ライブラリ側の成果と相殺してプラマイゼロと言いたくはあるんですが、私的な理想像とは離れたところにあるので、まぁ、60点ぐらい……（ちょっと甘め）
いろいろと白髪が増える、ハゲる。といったぐらいな感じです、うみぅ。来年は100点目指します。
ゲームとか音楽とか
今年はライブにまぁまぁ行ったんですが、年末のKing Crimsonの来日講演が震えすぎたのでそれが全て。生きててよかったというか生きてるうちに生で聴けることがあるなんて……！内容もばっちしで、いやはやホンモノは永遠にホンモノであり続ける、というかホンモノであり続けようとする姿勢に感服するばかりです。この編成での本気のライブ版が早く出てほすぃ。
面白かったといえばSquarepusherの来日講演も見に行ったのですが、実に面白かった。サイトでは360度動画が公開されてますが、そうした全方位動画やプロジェクションマッピング、VRの未来すら感じられて、思い出すと行けて本当に良かったなぁ。
ゲームはDownwellがオモシロイッス。
漫画は、iPhone 6s Plusを買ってから、スマフォで本や漫画が十分に読めるようになってしまって革命的に体験が変わった。いやあ、大画面スマフォ（ファブレット）は良いですね！一度体験すると、もう小さいのには戻れない。というわけで基本Kindleで買ってiPhoneで読むというインスタントな生活になりました。今年読んだ中だとヴァーチャル・レッドが良かったかなぁ、終始、陰鬱な空気が流れていて息苦しいんだけどどこか心地良くもある。気に入りすぎてKindleで読んだ後に実書籍のほうも買ったんですが装丁がよく出来てて、そちらも満足度高し。
来年
シンプルに、全力で仕事してゲーム出す。ですね。それ以外なし。もちろん、それはC#を全方面で活かした実証結果として成り得るものです。絶対。これは絶対。
私個人としてはヌルヌルとC#でのスクリプティングにだけ篭もりすぎた感あるので、UniRxも一段落したことだし（ちなみに、もう少し性能向上のためのアップデートが控えていてというか現在審査中なので年明け早々にそれはリリースされるでしょう）、シェーダーをそれなりにすらすら書ける程度にはグラフィック処理もできるようにってのは年頭の宿題にしておきます。
UniRx 5.0 - 完全書き直しによるパフォーマンス向上とヒューマンリーダブルなスタックトレース生成
- 2015-12-21
UniRx(Reactive Extensions for Unity)のVer 5.0が昨日、AssetStoreにリリースされました。前回が4.8.2で6月なので、半年ぶりで、今回はメジャーアップデートとなります。現在の最新であるUnity 5.3（の新機能）に対応というのもあります、が、今回の目玉は書き直しです。半年間なにやっていたかというと、書き直そう！いよいよやっと重い腰を上げてスタックトレースに優しいコードにしよう！と思い立って始めてみたもののメンドウくささが極まって挫折して放置。してたんですが、先月ぐらいに、いい加減に手を付けたくて、ちょっとうちの会社の仕事時間を貰ってゴリゴリ進めてやっと終わりました。
とりあえず分かりやすい成果としては、スタックトレースです。
var rp = new ReactiveProperty<int>();
rp.Where(x => x % 2 == 0)
.Select(x => x * x)
.Take(10)
.Subscribe(x => Debug.Log(x));
rp.Value = 100;
という人畜無害なコードがあるとして、以前のスタックトレースはこうです。
言ってることはわからんでもないコンパイラ生成の何かと、多量の中間物で埋まっていて、実に読み取りにくい。この程度のメソッドチェーンならまだマシで、もっと長大で、複雑なオペレータが絡んでる場合は困難極まってました。私も何度文句を言われて平謝りしたか分からないぐらいです。しかし、今回のバージョンからはこうです。
自動生成コードなし、中間物ナシ。圧倒的な読みやすさ！また、これはそのまま、書いたとおりに動いているということの証左でもあります。実行パイプラインの無駄がスタックトレースに出ているままに皆無になったので、パフォーマンスにも寄与しています（書き換えた今では、もはや前のが厚すぎた説はありますけれど、それはまぁ言わんといてください……）
実装はかなりメンドウで、ラムダ式を使うと問答無用でコンパイラ生成のクラスが吐かれてしまうので、ひたすら名前付きのクラスを作っていくお仕事をしました（一個のオペレーターにつき2~3のクラスを要求する、オーバーロードがあればその分だけ……）。また、Unityのコンソールの出力に合わせた細かい調整を施すことによって（＋通常のスタックトレースへの吐かれ方に対しても調整して）作りました。すっかりスタックトレースのことを考えたプログラミングができる脳みそが出来上がったんですが、基本的に面倒くさ度100なので、ふつーのゲーム側のコードでは考えたくないしやりたくもないしやらなくていいと思ふ。
性能改善
じゃあ前のは遅かったのかよ、と言われると、うーん、そんなでもないですよ？、とは言いたいのですけれど、まぁカタログスペック的には実際3~10倍ぐらい速くなってます。これはねぇ、例えばMySQL 5.7が5.6の3倍速い！なるほど、じゃあ5.6はゲロ遅なのか？そうじゃあないっしょー、みたいな話なのですが、実際速くなったのは誰にとっても私にとっても嬉しい話です。
しかし、パフォーマンス低いとか気になるとか、漠然とした話で、何も言ってないに等しいんです。もちろん、3~10倍速くなったというのも何も言っちゃあいないです。プログラムの抱えている範囲に対して広すぎる、漠然としすぎていて何ら指標になっちゃいません。というのは気をつけてください。Rxのパフォーマンスを測るにあたって、フェーズ的に3つあって、
- Observableを構築するフェーズ(さすがにこれはほとんど無視していい)
- Subscribe = Observerを構築するフェーズ
- OnNext
それぞれは独立して考える必要があります。また、ReactivePropertyはSubscribeと同時にOnNextも一回入るのでSubscribe + OnNextである、などなどがあるので、どこをどう測りたいかを明確にし、どう測るかを考えないとザルな結果になります。
基本的に、Rxのチェーンの寿命は長いのでOnNextの性能を最重要視して見るべきです。ここの区別は非常に大事です、長ければチェーン構築コストは相対的に無視できる範囲に収まるのでマイクロな結果で想像するのは違うってものです。が、初回に大量にSubscribeが発生するといった、ローディング的な意味合いでは、Subscribeのフェーズも鑑みる必要があります。
んで、これもザックリとしすぎでアレなんですが、OnNextは3~5倍ぐらい、Subscribeに関しては10~20倍速くなりました。OnNextは全体的なパイプラインの最適化のオペレーターの実装調整が効いてるんですが、Subscribeは抜本的に最適化/単純化したので、以前と全然違う結果になってます。これは、社内で大量のSubscribeがシーンロード初回に発生するという事案がありまして、Subscribeを改善しない限りロード長過ぎで終わぽ、だったのでなんとかしました、はい、すびばせん今まで手付かずで……（ちなみに本家Rx.NETとやり方変えてるので本家Rx.NETよりも速い）
あとのところはオペレーター次第です。WhereとかSelectとか、単純な奴は実装変わってないんで大差ないんですが、一部のメソッドの実装が素朴でしょっぱかったので、そういうのはきっちり直してるので以前のと全然性能変わってきてます。特にObserveOnが顕著かな。また、Observable.IntervalやTimerなどの一部の時間系メソッドも構造がガラッと変わってるので(MainThreadScheduler/ThreadPoolSchedulerが使われる場合には最適化パスを通るようにしてる)、かなり良好な結果が得られるのではないかと。
全体的にGCゴミも減ってます。まだもう少し減らせるポイントが残ってるので、次のマイナーアップデートではその辺の処理をする予定デス。
リリースノート
今回の。
破壊的変更:
iOS/AOTサポートは切りました。IL2CPPしかサポートしません。
Unit/Tuple/CancellationToken/TimeInterval/Timestampedをclassからstructに変えました。
MainThreadDispatcher.Postのメソッドシグネチャが変わり、T stateを要求します。
ObservableMonoBehaviour/TypedMonoBehaviourがObsoleteになりました。
AotSafe Extensions(WrapValueToClass)を消しました。
InputField.OnValueChangeAsObservableをOnValueChangedAsObservableにリネームしています(Unity 5.3の場合。Unity 5.3でInputField側で同様の変更が入っているため)
Subscribe in SubscribeでのException Durabilityを保証します。
追加メソッド/クラス:
Observable.ForEachAsync
Observable.Take(duration)
Observable.Aggregate
Observable.Zip(T3~T7)
Observable.CombineLatest(T3~T7)
Observable.Start(function, timeSpan)
Observable.ToYieldInstruction in Unity 5.3
Observable.DoOnError
Observable.DoOnCompleted
Observable.DoOnTerminate
Observable.DoOnSubscribe
Observable.DoOnCancel
Observable.CreateSafe
Progress
StableCompositeDisposable
MultilineReactivePropertyAttribute
その他色々修正:
色々色々(詳しくはGitHubのとこの正式なリリースノート見てくだしあ)
破壊的変更といっても、直撃することはないんじゃないかなあ、と思ってます。ただ社内ではUnit/Tupleのstructへの変更で引っかかったりはしました(想定外にもnullが代入されている場合があった！)。それは適切にdefault使うのと、Tupleに関してはTuple?にするなりする程度で対応はできます。struct化はAOTサポートを切ることで躊躇いなくできるようになって、ヨイことだなー、と。コードも全体的にAOTサポートのための余計なコードを順次切り落としています（パフォーマンスロスに繋がっていたので）。その辺はIL2CPPバンザイ、ですかねえ。
vs IL2CPP - Runtime UnitTest Runnner
IL2CPP万歳と言ったそばから言うのもアレですが、IL2CPP苦しい……。コンパイル死ぬほど遅いし、というのはおいておいても、まだ地雷は埋まっていて、たまに踏んで死ぬんですよね。その場合IL2CPPのバグなんで報告して直してもらうってことになるんですが、それはそれとして、なんで死ぬのかがAOTの場合は想像ついたし対処も比較的容易だったんですが、IL2CPPは踏むまで地雷かどうかを察知することが不能な上に、踏んだら踏んだで、何を踏んだからこうなったかがイマイチ分からなくて最小ケース作ってバグレポも辛いケースもちらほら。
とはいえ、それなりに安定してきてるのは確かだと思います。偉い。そこは賞賛されるべき。
のはいいんですが、実行するまで分からないじゃ（特にライブラリ側としては）困るので、iOS実機でユニットテストを動かしたいと思いました。Unity 5.3からEditor Test Runnerなども標準で入ってきましたが、端的に言えば、欲しいのはそれじゃない。実機で動かしたいの！エディターでの実行はどうでもいいの！
エディター上での実行も大事なんですが、元々UniRxは.NET用ライブラリとしても動くように設計されていて、ユニットテストも.NET用ライブラリとしてMSTestで書かれている（！）という特殊な環境なので、エディターでのテストサポートは完全に不要なのです。いや、だってVSのテストランナー使ったほうがやりやすいじゃん？
そうやってユニットテスト自体は書かれてるし、さすがに実機用に別のを書きなおすのは不可能なので、このユニットテストを実機で動かせるように持ってければそれでいいんだよねー。
ここで出てくるのがRoslyn。Roslynを使ってユニットテストプロジェクト内のユニットテストを、ソースコードのファイル単位ではなく、解析可能な構文木単位で取得し、T4 Text Templateで整形して吐き出せちゃえばいいんだ、という合わせ技で運搬することに成功しました。VS2015だから出来るハック、VS2015最高……。さすがにコード持ってくだけではMSTestの実体がなくて動かないんですが、そこは適当にモック(Shim)を用意して回避しました。
エクストリーム雑なUI。エラーが出た場合は赤くなってExceptionを表示します。これで、ちゃんとiOS/IL2CPPで全部パスしてるのを確認済みです。
ちなみにこのRoslyn + T4でコード生成するテクニック、今回のように別プロジェクトをターゲットにして運搬するというのもいいんですが、自プロジェクトを対象にすることもできます。T4で生成するためのコードのタネって、今まではT4側に書くしかなくて面倒だったんですが、もうその制限はありません。ありとあらゆるソースコードがコード生成のためのタネとして使えます。メタプログラミングの扉をまた一つ開いてしまった。
このテクニックは私の発明じゃなくてRoslynをT4テンプレート内で使う - ぷろじぇくと、みすじら。から拝借してますので、気になる人はそちらの記事をどうぞ。ｌ
Unhandled Exception Durability
UniRx 5.0の変更のうち、ちょっとだけ重要なのがUnhandled Exception Durabilityというコンセプト。です。これは、Rxでイベントハンドリングするのはいいんだけどエラーでるとイベント購読が吹っ飛ぶの困るんだよねー、に対するUniRxからの回答ということで。内容ですが、Subscribe in Subscribe時の例外を外側に伝搬「しない」ことを保証しています（逆に言えば実は4.8では保証されてなくて解除されたりしてました。ちなみにRx.NETでも保証されてなくて解除されたりされなかったりします、ここはUniRx独自で挙動を明言する形に倒しています)。伝搬しない、というのは握りつぶすという意味ではなくて、ObservableのDispose処理を行わない、という意味です（例外自体はグローバルに飛ぶのでUnityのConsoleにExceptionが表示されるし、ログイベントでちゃんと捉えられます）
button.OnClickAsObservable().Subscribe(_ =>
{
// もし内側でエラーが発生しても、外側のOnClickがデタッチされることはない
ObservableWWW.Get("htttp://error/").Subscribe(x =>
{
Debug.Log(x);
});
});
エラーハンドリングは難しい問題で、RxJavaのErrorHandlingの章を読んでも別にそんなワカラナイよね、とかって感じではある。UniRxでは Retry/OnErrorRetry でハンドルできなくはなく、まぁそれがスタンダードなRx WayではあるんですがRxJS の Operators (6) - Observable のエラーハンドリングのまとめコメント「これで本当にエラーハンドリングに十分なのか不安です。」とあるように、実に不安です。
で、入力用のハンドラーが吹っ飛ぶのは致命傷なので、どうしても救いたいその辺のとこに関してはSubscribe in Subscribeで処理するのがいいんじゃないかなー、というのを提唱します。入力イベントを合成したいって局面も多いと思うので、それはそれで合成してもらったうえで（そして、その合成パイプラインに関してはエラーが出ないよう厳重に作る！）、それを入力ストリームだと考えて、そこから先はSubscribe in Subscribe。あまり格好の良いものではないのも事実ですが、現実的っちゃあ現実的かなー、と。ちなみにこの挙動を保証するのはUniRxだけだと思うので他のRx系に持ってっても動きません（多分）
なお、Subscribe in Subscribeでの例外で解除されないのは最上流がHot Observableのものだけです。HotとColdに関してはRxのHotとColdについてなどを参照するといいと思いますが、とりあえず具体的にHotなのはUniRxデフォルトでは FromEvent/Subject/ReactiveProperty/ObservableTriggers/UnityUI.AsObservable です。ようはイベント的なやつです。Coldなのは Return/Interval/Timer/FromCoroutine などで、これらは例外で解除されます（そうじゃないとTimerとか無限に動き続けられても危なくて困るでしょ？FromCoroutineだって途中でエラーが出てる状態なのに回られても困るでしょ？）
CustomYieldInstuction
書き直しはいいんだけど、何か新機能ないと寂しいよなー、ということで、Unity 5.3用に一つ入れました。Unityブログでもカスタムコルーチンとして紹介されていますが、Unity 5.3からCustomYieldInstructionが搭載されました。というわけでUniRxもUnity 5.3以上ならToYieldInsturctionメソッドが使えるようになっています。
IEnumerator TestNewCustomYieldInstruction()
{
// Rx Observableをyield returnで待ちます.
yield return Observable.Timer(TimeSpan.FromSeconds(1)).ToYieldInstruction();
// スケジューラを変える(Time.scaleを無視する)とかも当然可能
yield return Observable.Timer(TimeSpan.FromSeconds(1), Scheduler.MainThreadIgnoreTimeScale).ToYieldInstruction();
// 戻り値を得る場合はObservableYieldInstructionを変数に取れば、Result/Errorで受け取れます
var o = ObservableWWW.Get("http://unity3d.com/").ToYieldInstruction(throwOnError: false);
yield return o;
if (o.HasError) { Debug.Log(o.Error.ToString()); }
if (o.HasResult) { Debug.Log(o.Result); }
// 当然こういう長めのものだって自由に書けます
yield return this.transform.ObserveEveryValueChanged(x => x.position)
.FirstOrDefault(p => p.y >= 100)
.ToYieldInstruction();
}
今までもToAwaitableEnumerator/StartAsCoroutineというメソッドで同様なことを出来るようにしていたのですが、ToYieldInsturctionのほうが効率的だし、使いやすいです。ToYieldInsturctionによるObservable->Coroutine変換のオーバーヘッドはないといっても過言ではない！Unity 5.3最高！
ちなみに、このToYieldInsturctionはCustomYieldInstructionクラスを実装してません。Unity 5.3のカスタムコルーチン対応というのは、yield returnでIEnumeratorを受け取ると毎フレームMoveNextを呼び出して待機する、というのが正しい話です。CustomYieldInstructionはあくまでIEnumerator実装のためのちょっとしたヘルパーなので、別にそれにこだわる必要はありません、ということで普通に独自の軽量なIEnumerator実装を刺しています。
ちなみに実行されるタイミングはCustomYieldInstructionの説明によると after MonoBehaviour.Update and before MonoBehaviour.LateUpdate だそうなので、実行タイミング調整のネタに使えるかもしれません。
まとめ
実際のトコver 2.0なんですが、諸事情で4始まりなのでver 5.0です！Unityのメジャーバージョンと偶然揃ったしいっか、という気がしますね！今回のコードはかなり自信あって、パフォーマンスがー、な局面であってもお薦めできます。どうせ、ライトウェイトを冠した超機能限定版の同じようなものを実装するなら、性能面であっても素直にUniRxを使ったほうがいいでしょう。と、言えます。言えます。
今月頭に書いたUnity 5.3のMulti Scene EditingをUniRxによるシーンナビゲーションで統合するなどのように、UniRxを前提に置くことで、やれることが大幅に広がります。根底から入れれば全体のプログラミングの世界観が（良くも悪くも）大きく変わります。が、まぁそれはエキセントリックすぎるということであれば、触りは単純なところからでも全然アリかな、とは。思います。特に非同期/マルチスレッド関連は、変なライブラリ入れるよりもずっと良いでしょう。
ところで半年前、今年6月に第一回UniRx勉強会を開催しましたが、第二回の需要ってありますか？もしありましたら、その前に発表者が必要！なので、是非話したい！人は、私のTwitterかメールかに連絡ください。開催するにも発表者いなければ開催もなにもないですからね……！
ついでにもはや触れちゃいけない扱いの気がしなくもないUnity アセットコンテストというのに応募していたのですが結果発表……。
Roslyn C# Scriptingによる実行できるコンフィグの手法と実活用例
- 2015-12-13
Advent Calendar大遅刻組です。というわけでC# Advent Calendar 2015の10日目です！なんで遅刻したかというと、記事のネタのためのライブラリを作るのに思いの外時間がかかってしまったから…… コンセプトも固まってたしプロト実装も済んでたんですが、最終的な形に落としこむのが想定よりちょっと割と大変だった……。すびばせんすびばせん。
どうやらC# Advent Calendarは2011年から書いてるので5回目ですね、へぇー。過去を振り返るとModern C# Programming Style Guide、モダンつってもC# 4.0時代ですが、今ぱっと見直すと別にここで言ってることは今も変わらないですね、これに5.0, 6.0の話を足せばいいだけの話で。2012年はMemcachedTranscoder - C#のMemcached用シリアライザライブラリということで、このライブラリは別に私自身も使ってないので割とどうでもいー、んですが、まぁシリアライザにまつわる諸々についての知見が少しは入ってる模様。2013年の非同期時代のLINQはいい話だなー、これがC# 5.0のModern Styleの追記差分みたいなもので、実際、今現在においては超絶大事な部分。2014年はVS2015+RoslynによるCodeRefactoringProviderの作り方と活用法で、C# 6.0ではないですが、その世代ではAnalyzerは中心になってくるので、これがC# 6.0の差分といってもいいでしょう。多分きっと。
Roslyn C# Scripting
Roslyn、Compiler as a Serviceとか言ってましたが、やっぱスクリプティングが華形だと思うのです。が、しかし。が、しかし。今の今までRoslynに関する話題で、Scripting APIに関するお話はあまり上ってませんでした。理由は単純で、今の今まで未完成品だったから。先月末に出たVisual Studio 2015 Update 1でC# Interactiveが、そして同時にNuGetでもMicrosoft.CodeAnalysis.CSharp.Scriptingで、現在は1.1.1が配布されることにより（ところでこれのパッケージ名が中々定まらなくて実際これであってるのか不安だけどLast updatedが2015/12/3なのでこれでいいでしょう、まだDL数が405ですけど！）やっと全てのピースが揃った感じです。
Scriptingについてのドキュメントは、RoslynのWikiにある2つのページを見ておけば十分でしょう。Interactive-Windowには、csxの仕様っぽいもの、特殊なDirectiveの説明があります(#rとか#loadとか)。Scripting-API-Samplesにはプログラムから触った時のAPIとしてどんなものを持ってるか、どういう風に使えるかが書いてあります。かなりシンプルなので、そんな難しくなくすぐ使えます。
ちなみにC# Interactiveはまだまだ全然使えないって感じなので、期待するほどのものでもないですね。csxもエディタサポートが実質、シンタックスハイライトぐらいなので厳すぃ。黙ってLINQPad使いましょう、課金しましょう。
Roslyn時代のコンフィグ
最近というか数年前からずっと構造化ログにご執心で、EtwStream - ETW/EventSourceのRx化 + ビューアーとしてのLINQPad統合というのを作ってたんですが、今回はそれに、ファイル等への出力プラグイン(Sink)と外部サービス(EtwStream.Service)を作りました。アプリケーションから出力されるログは、ETWというWindows内部に流れてる高速なロギングストリーム機構を通して、別プロセスのEtwStream.Serviceで受け取ります。ログは特に最近ではファイル出力など比較的安定性が保証されているものだけでなく、ネットワークを通じて配信するケースも少なくありません。ログの扱いが別プロセスに別れることにより、アプリケーションに与える影響が少なくなるほか、アプリケーションの状態(アプリ自体の終了/デプロイでの入れ替わり等)に気を配る必要もなくなります。
というのが外部サービスであることの意義なのですが、問題はコンフィグです。コンフィグ。元々EtwStreamはObservableEventListenerという、IObservble<LogEvent>の形でログをストリームで受け取り、それをRxで自由にフィルタしたりグルーピングしたりマージしたりなんでも出来ますよね、という究極の自由度がウリでした。しかしコンフィグです、Rxのその柔軟性をコンフィグで実現するのは不可能です。物凄く機能を削った単純なSubscribeで我慢するか、あるいは超絶複雑なXMLでそれっぽいものを構築するか(log4netやNLogのXMLコンフィグが死ぬほど難解で複雑なのは、ログのルーティング自体が複雑で、それをコンフィグで表現することが困難だということなのです）になります。
せっかく、ログを現代的なReactive Extensionで表現することができたのに、外部サービスにした途端に破棄しなければならないのか。それでいいわけがなく、そこでC# Scriptingの出番になります。EtwStream.Serviceはコンフィグをconfiguration.csxとして、以下のように書きます。
// configuration.csx
// 5秒 or 1000件でバッファリング(ふつーのRxのBufferを利用)
// 出力フォーマットは普通にFunc<TraceEvent, string>で整形できる！
ObservableEventListener.FromTraceEvent("SampleEventSource")
.Buffer(TimeSpan.FromSeconds(5), 1000, EtwStreamService.TerminateToken)
.LogToFile("log.txt", x => $"[{DateTime.Now.ToString("yyyy/MM/dd hh:mm:ss")}][{x.Level}]{x.DumpPayload()}", Encoding.UTF8, autoFlush: false)
.AddTo(EtwStreamService.Container);
基本的に完全にC#そのものなので、全てのRxのメソッドが使えて自由に合成・ルーティングが可能です。これはIn-Processで書いてる際（普通のロガーとしてC#コードで埋め込む場合）もOut-Of-Process Serviceでコンフィグとして書く場合も（ほぼ）同じコードで表現できるということです。もちろんC#で書けるということは、 System.Configuration.ConfigurationManager.AppSettings から設定を引っ張ってきたり、ネットワーク通信して何か引っ張ってきたりとかも自由自在やりたいほーだいです。
例えばこれをNLogで表現すると
<targets>
<default-wrapper xsi:type="BufferingWrapper" bufferSize="1000" flushTimeout="5000" />
<target name="file" xsi:type="File" fileName="log.txt" keepFileOpen="true"
layout="[${date:format=yyyy/MM/dd hh\:mm\:ss}][${level}]${message}" />
</targets>
<rules>
<logger name="*" minlevel="Debug" writeTo="file" />
</rules>
になります。NLogの独自フォーマットルールに従って書く必要があるし、メッセージ書式も独自テンプレートになります。とはいえ、これはまだ単体なので遥かにマシで、色々複合的なことをやろうとするとすぐに膨れ上がって意味不明なことになるのは、みんな経験のあることなのではないでしょうか？
バイナリがEtwStream/releases/EtwStream.Serviceに転がってるので、是非ちょっとだけ遊んでみてくださいな。
仕組み
csxをEvaluateしてるだけです。基本的にcsxの実行は即座に終わります、ObservableEventListenerをSubscribeしているだけですから。しかし、csxが終了してもSubscribeは生き続けています！（言われてみると当たり前のようで、最初はそうなの？と違和感はありました）。それにより、流れてくるログは（別スレッド上の)ObservableEventListenerを流れて、csx上のRxを通りcsx上でのSubscribeにより処理され続けます。というわけで、EtwStream.Serviceのcsxは、ただのXMLコンフィグがcsxに変わっただけ、ではなく、このcsxはコンフィグのようでコンフィグじゃなく、実行コードそのものなのです！
終了処理に関しては、ホスト側から渡しているTerminateTokenと、AddToを通してSubscriptionを登録していることにより制御されています。csxの評価としての実行が終わっていても、裏で生き続けている限り同じ参照を持っているので、ホスト側から干渉することが可能です。なので、ServiceのStopイベント時にはTerminateTokenにCancel命令をホストが出すことにより、Rxの残ってるBufferが送り出され、AddToで受け取っているSubscriptionを待つことにより、溜まったログの処理が完了するまで待機するといった、安全な終了処理を可能にしています。この辺はRxをフル活用してパイプライン組んだ成果ということで。
再びエディタとしてのLINQPad
さて、csxで書けるところのイイトコロはC#なのでコンパイルエラーも検出できるしシンタックスハイライトもあるし、などなど、なのですが、エディタサポートは……。Visual Studio 2015のUpdate 1によって確かにシンタックスハイライトはついた、が、それだけ……。IntelliSenseもDLL読み込ませたり色々しなければなので実質使えないみたいなもので厳しい……。
そこで出てくるのがLINQPad。
EtwStream.LINQPadには、EtwStream.Serviceのcsxで渡されてくるEtwStreamServiceクラスのShim成分が入っているので、csxと互換性があって、LINQPadで実際にコンパイルできる/動かして確認した結果をcsxに持っていくことが可能です。（というようなことが出来るようにAPIを調整したんです……）。C# Interactiveが使い物にならならいなら使い物になるまで我慢する、のではなくて、一時凌ぎでもなんでも、他の現実的な解法を探すのが正すぃ。クソだクソだと文句だけ言ってても何も動きませんしね。必要なのは今この場でどうするか、それだけ。
Topshelf
Windowsサービスの実装にはTopshelfというライブラリを用いています。これは、最高に良いです。もはやこれなしでWindowsサービスを実装するのは考えられません！Visual Studioのテンプレートからふつーにサービスを作ると、なんかゴチャゴチャしたのが吐かれてよくわからない上に実行も面倒だし（いちいちinstallしたくないでしょ？）デバッグも困難だし、実にヤバい最低な開発環境。Topshelfで作るとコンソールアプリケーションと同じ感覚で作れます。また、成果物のexeは、そのまんまふつーにコンソールアプリケーションとしても動くので、EtwStream.Serviceの場合、ビューアーとしてLINQPadを要求していましたが、EtwStream.Service.exeを実行すれば普通にビューアーになります(csxで書き出し先をConsole(LogToConsole)にすれば色分けもしてくれる）。サービスとしてのインストールは「install」をつけて実行するだけ。素晴らしい。
日本語ではWindowsサービスを楽に開発～TopShelf～やTopShelf によるWindowsサービスの配置をDSCで自動化してみように説明ありますが、本当に簡単なので、サービスを作る機会がある人は是非使ってみてください。超お薦め。
ファイル出力時のロガーのパフォーマンス
今回ロガーを全部自作する都合上、さすがに単純なファイル書き出しと、ローテーションするファイル書き出しは用意しとかないとなぁ、ということで作ったんですが(FileSink, RollingFileSink)、作ってる上でなんとなく気づいたことなど。
そもそもファイルに吐くっていうこと自体がレガスィーで好きじゃないんですが、それはそれとしてもやはり重要なのは間違いありませんし、普通に使います。で、特にInProcessでのロギングの場合、これに気を配らないと普通にパフォーマンス上のボトルネックになってしまったりするわけですねー。さて、で、パフォーマンスは設定が全てです。とりあえず、バッファリングと非同期の二つのオプションを探しましょう。まず、ファイルに吐く場合のパフォーマンスはバッファするかしないかで全く変わるし、逆にバッファさえすればよほどタコな実装じゃない限りはそんな差はなくふつーに性能出ます（多分）。もう一点はasyncですね、これは別に大抵は非同期I/Oじゃなくて別スレッドで書くってだけのパターンなんですが、これが有効だとロガーの動作がアプリケーション自体に一切影響しなくなりますので。まぁバッファを有効にしてれば、例えば1000件に一回書く設定だったら1/1000回以外は書き込み処理に時間喰われることはなくなるので、ほぼ無視できてあってもなくても大差なくなるんですが、（起こるかもしれない）ちょっとしたスパイクは抑制できるかもしれません。また、あえてバッファはオフにしてasyncだけオン（+即時Flush)にすれば、ログが中々Flushされなくてリアルタイムで確認したいのにイライラ、というのがなくなって良いかもしれません。この辺は好みとか要件しだいで。
とりあえず言えるのはデフォの設定がどうなってるかはともかく、ノーバッファでノーエーシンクだと当然のように遅いです。更に設定によってはファイルストリームを都度閉じるか開きっぱがオプションになってるものもありますが、これは当然、開きっぱじゃないとゲロ遅いです。そういう項目がオプションにある場合は注意しましょう。デフォが都度閉じるだったりしてね……(NLogがそうです。NLogのデフォルトは安全寄りに倒し過ぎでパフォーマンスがヤヴァいことになってるので、NLog使う場合はそれなりに弄ったほうがいいでしょう。かといって他のロガーもそう変わりはなくて、大抵はそれなりに弄らないと遅いです）
かわりに、バッファや非同期ってのはログの消失の危険性があります。書いた瞬間には保存されてないってことですからね、アプリケーション終了への耐性が低くなります。気の利いたロガーは、可能な限り、終了を検知して(AppDomainが消える時のイベントとかをハンドリングして)、残ってるバッファを出力しに行ったり非同期の終了を待機しに行ってくれたりはしますが、パーフェクトではありません。例えばAppDomain.ProcessExitのタイムアウトは既定で2秒です。2秒以内にフラッシュが完了する保証はないわけで、そこで完了できなければログロストです。
それを避けるには、「パフォーマンス低下を承知してバッファや非同期オプションを使わない」というのも手ですが、EtwStreamは更に2つの選択肢を提供してます。一つは「Out-Of-Process Serviceでのログ収集」。ETWへのログ出力はほぼノーコストで即時に吐けるのでアプリケーションへの影響は一切無い上に、それを外部サービスで取り出せば、出力側の終了の影響を全く受けません。ただし当然、受け取る側の外部サービスが死んだらロストするという危険性はありますがね！そこに関しては知らんがなというかshoganaiというか精一杯堅牢性を高めますとしか言い様がないですにぇ。
もう一つは、プログラム的に終了が完全に待機できるSubscriptionシステム。もともとEtwStreamは設定をC#で、Rxで書く必要があるので、購読状態に関して100%コントロールできます。というわけでその辺に仕掛けを入れといて
static void Main()
{
// ApplicationStartの部分でこの2つを用意する
var cts = new CancellationTokenSource();
var container = new SubscriptionContainer();
// でログの設定する
ObservableEventListener.FromTraceEvent("SampleEventSource")
.Buffer(TimeSpan.FromSeconds(5), 1000, cts.Token)
.LogToFile("log.txt", x => $"[{DateTime.Now.ToString("yyyy/MM/dd hh:mm:ss")}][{x.Level}]{x.DumpPayload()}", Encoding.UTF8, autoFlush: false)
.AddTo(container);
// --- 実際にアプリが動いてる部分 --- //
// アプリが終了した時のイベントのところでハンドリングする(Form_ClosedでもApplication_Endでもなんでもいいですが)
cts.Cancel(); // CancellationTokenのCancelによりBufferの残りが吐き出される
container.Dispose(); // Subscriptionの完了を待機する
}
といった風にすれば、100%コントロールされて停止時のログ処理を完了させられます。csxでもEtwStreamService.TerminateTokenとか渡していたのと同じことをやればいいということで。
100%コントロールできる代わりに、逆にEtwStreamは自分でコントロールしないかぎりは、気の利いた終了の検知とか組み込んでないので、待たなければふつーにバッファは消えます。これに関しては、10年前はゴテゴテとブラックボックスの中で気の利いたことをしてくれるのが正義だったかもしれませんが、2015年の現代では仕組みはシンプルに、薄くしたうえで、自分でコントロールさせるのが正義だと思ってます。そういう流儀。どっちが正しいってこともないですが、まぁ、今風なんじゃないかな？
ついでに言えば、EtwStreamのFileSinkやRollingFileSinkのパフォーマンスはバッファしてる前提同士で比較しても、他のよりも高い性能を誇ります。理由は幾つかあって、そもそも性能を意識して書いてるから。というのと、.NET 4.6以外をサポートする気がないのでasync/awaitやTPL全開でコードを書いてるから。オプション自体も同期処理は一切なくて、書き出しは非同期I/Oのみに限定などの割り切り。そして、通常はログフォーマット整形などに独自テンプレート的なのを挟まなきゃいけないところを、csxのお陰でFuncで処理できるため、そもそもコードパスに一切のオーバーヘッドがない。C# Scriptingによるコンフィグはパフォーマンスにも寄与するわけです。
しかしまぁ、JavaではBlitz4jやlog4j2のAsynchronous Loggerなどのスピード競争があるのに、.NETの牧歌的なこと、といった感じは否めませんねぇ。そんなだから私のとりあえずの雑実装でもfastestになってしまうわけで……。
出力先
EtwStreamが提唱するのは構造化ログ(Structured/Semantic Log)ですし、テキストログが終着点ではありません！テキストログは無視して、構造化されたペイロードを、そのままAzure EventHubsやAmazon Kinesis、Google BigQueryのStreaming Insertに流して、ただたんに溜めるのではなくて、即座に分析可能な状態にするのが理想形です。特にお薦めなのは、というか弊社で使ってるのはGoogle BigQueryです。事例として株式会社グラニの Google Cloud Platform 導入事例: 「using CSharp;」という軸と BigQuery の活用で、先進性を求め続ける。を掲載してもらいました:)
今のとこEtwStream用のBigQuerySinkはないんですが（！）そのうち公開するかされるかするんじゃないでしょーか多分きっと。（本当はそれも作って持ってきたかったんですがもう完全に時間切れでして、すでに大遅刻だし……）。そういえばあとFromTraceEventでRegisteredTraceEventが取れるようになりました。これはつい数日前のTraceEventライブラリのアップデートでそうなったから、というだけなんですが、今まで取れてなかったんですよねー。これで大丈夫。というのと、SLABのOut-of-Process Serviceじゃダメな理由に.NET 4.6からEventSourceに追加されたself-describing events（超重要！）に対応してないとか色々あるんですが、そういった話はまたの機会にでも。
まとめ
ロガーの未来はこうあるべきだ、という構想自体は1年以上前からあったんですが、Roslyn C# Scripting APIが正式リリースされてやっと作れた！あと、基本的にはMicrosoft Patterns & PracticesのSemantic Logging Application Block(SLAB)の影響が濃くはあるんですが、更新されなすぎだし、v3はElastic Search + LogStash + Kibana on Azureとか言ってて、マジで終わってるなという感じでもはや見限るしかない……。P&Pは相変わらず本当にやっぱダメですねーという残念さ加減。なにがPatterns & Practicesだよっていう。
csxでコンフィグするライブラリとしてConfigRというのがあるんですが、XMLをcsxで置き換えるだけじゃ、あんま意味がないかな。必要なのは、コンフィグができることじゃなくて、それそのものが実行されて自走することだというのに気づいたので、使うことはなかったし、多分他のアプリケーションでもConfigRを使うことはないと思います。XMLはいうて設定ファイルとしては悪くないんですよねー、XSLTなんかもやり過ぎなければ良い機構ですし。逆にJSONを設定ファイルとして使うのは最低最悪なチョイス(なのでDNXへのやる気が0.1ミリも起きない)
何れにせよ、徐々にではあるでしょうが、csxの面白い活用例というのはどんどん出てくるのではないかと思います、と言いたいんですがfsxが別に対して面白い活用はされてないことを考えるとそんなに出てこないかもしれませんね、とも思いますが、いえいや面白い活用例はやっぱ出てくるかもしれません。batをcsxにしましたとかってだけだと別に面白くもないし意味もそんなにないですからねー、まぁあってもいいけど。もっと本質的に変わるような事例が増えてくれれば何よりです。
Unity 5.3のMulti Scene EditingをUniRxによるシーンナビゲーションで統合する
- 2015-12-03
今回はUnity Advent Calendar 2015のための記事になります。昨日はtsubaki_t1さんによるUnity初心者を脱するためのデバッグ入門…的なやつでした。私はとりあえずVisual Studioでアタッチしてステップ実行、でしょうか……。最近はiOSのIL2CPPのスタックトレースが行番号出してくれなくて禿げそうというのが社内のホットトピックスらすぃ。
去年もUnity Advent Calendarには参加していて、その時はUnityのコルーチンの分解、或いはUniRxのMainThreadDispatcherについてという内容でした。今回も引き続き、私の作成しているUniRx - Reactive Extensions for Unityのお話ということでお願いします。とはいえ、中身的にはMulti Scene Editingや、シーン間での引数渡しをやるのにどうすればいいのか、みたいなところなので、Rxのメソッドは特に説明なくバンバン出てきますが、Rxワカラナイ人はそのへんは雰囲気で流し読みしてもらって、シーン遷移についてのお話を読み取ってもらえれば嬉しいですねん。
Multi Scene Editing
Multi Scene Editingは初出が2014/8/4のUnity Blogの記事でしょうか、1年経ってやっと正式リリース、までまもなく！ですね、5.3から搭載されることになりました。実際どういうことになるかというと、ヒエラルキーウィンドウがこんな感じに。
シーン加算で読み込んだシーンがヒエラルキー上でもきっちり分けられます。DontDestroyOnLoadがついたものは専用のところに隔離される。シーンを削除する場合も、そのまま指定してサクッと消したり、マージできたりと、随分とシーン管理がやりやすくなりました。Unity 5.3からはいよいよシーン加算で管理する時代が到来する！
コード的にはUnityEngine.SceneManagement.SceneManagerに全部のAPIがつまってます。基本的にはLoadScene/Asyncか、UnloadSceneぐらいで事足りるのではないでせうか。
// SceneA -> SceneBへボタン押したら加算
// 別にRx使う必要性はないけど無駄に使うエディション
button.OnClickAsObservable()
.SelectMany(_ => SceneManager.LoadSceneAsync("SceneB", LoadSceneMode.Additive).AsObservable())
.Subscribe(_ => { /* 完了時の処理何かあれば */ });
この程度だとRx使う必要性はゼロですが、一応、LoadSceneAsyncの戻り値であるAsyncOperationはAsObservableで直接サクッとRx的に変換可能です。
シーン間に引数を渡す
どういうこっちゃって話ですが、新しいシーンに遷移なり加算したいってことは、引数を渡したくて然りだと思うのです。そのシーンを表示する際の初期引数が。例えばアイテム一覧画面から、アイテムの詳細画面を出すなら、アイテムのIDを渡したいよね、とかね。別にAndroidやiOSアプリでも、ウェブのURLのクエリストリングなりなんなりでも、そんなのは普通によくある話です。さて、SceneManagerはその辺りのことは、別になにも面倒みてくれません。じゃあグローバル変数を経由してやりとりするのかというと果てしなくビミョウというかスパゲティ化まったなし。せっかく画面画面がシーンで独立しているなら、値の依存関係もシーン内に抑えてやりたい。
というわけで、遷移/加算時に引数を渡せるシーン遷移機構を作りましょう。
材料として使うのはUniRxのPresenterBaseです。これは何かというと、子要素の初期化の順序をコントロールするのと、値の受け渡しができる仕組みです。ご存知のとおりUnityのGameObjectの初期化順序は不定(Execution Orderでおおまかに指定できるけど、細かいコントロールのために使うものではない)ですが、PresenterBaseの管理下におくことで、Startフェーズにて決められた順序で起動するようにコード上で設定できます。
この性質は、シーンに引数が渡される、つまり全てのルートになるという条件にぴったりです！というわけで、引数を受け取るための基底クラス、SceneBaseをPresenterBaseを継承して作りましょう。
public abstract class SceneBase : PresenterBase
{
// これがシーン遷移時にセットされる引数を表す
public object Argument { get; set; }
// 受け渡されたかどうかを管理するフラグ
public bool IsLoaded { get; set; }
protected override void OnAwake()
{
// 初期化が完了した際はロード済みと強制的にマークするおまじない
this.InitializeAsObservable().Subscribe(_ => IsLoaded = true);
}
}
こんなもので、割とあっさりめに。実際のシーンのクラスは
// このどうでもいいクラスを引数として渡していくということにする
public class Nanika
{
public int HogeHoge { get; set; }
public string Hugahuga { get; set; }
}
// 遷移元クラス、適当なボタン押したらSceneBに遷移する
public class SceneA : SceneBase
{
public Button button;
protected override IPresenter[] Children
{
get { return EmptyChildren; }
}
protected override void BeforeInitialize()
{
}
protected override void Initialize()
{
button.OnClickAsObservable().Subscribe(_ =>
{
// 直接SceneManager.LoadSceneAsyncを呼ぶのではなく、
// 独自に作成したNavigationService.NavigateAsync経由で引数を渡して遷移/加算する
var arg = new Nanika { HogeHoge = 100, Hugahuga = "Tako" };
NavigationService.NavigateAsync("SceneB", arg, LoadSceneMode.Additive).Subscribe();
});
}
}
// 遷移先クラス、Argumentに引数が渡されてきてる
public class SceneB : SceneBase
{
protected override IPresenter[] Children
{
get { return EmptyChildren; }
}
protected override void BeforeInitialize()
{
}
protected override void Initialize()
{
// 前のシーンから渡された引数が取れる
var arg = Argument as Nanika;
Debug.Log("HogeHoge:" + arg.HogeHoge + " HugaHuga:" + arg.Hugahuga);
}
}
ちょっと長いですが、言いたいのは遷移元ではNavigationService.NavigateAsyncを使って引数を渡して遷移先を指定する。遷移先ではArgumentに渡されたものをキャストして取り出す。といった感じです。
作る上での制約としては、必ず各シーンに単一のSceneBaseがヒエラルキーの頂上にある必要があります。こんな感じに。
うーん、随分と大きな制約であり不格好ですね……、この手の制約は実際のトコ、ないほうが望ましいです。別に、この手のヘンテコな制約をつけるのがアーキテクチャ、ではないです。自由なほうがよほど良いのです。とはいえしかし、どうにもならなかったので、そこは受け入れるしかなかったということで。この辺が今のところの手札でできる精一杯の形かなぁ。
NavigationService
では、肝心要のNavigationServiceの実装を見ましょう！
public static class NavigationService
{
public static IObservable<Unit> NavigateAsync(string sceneName, object argument, LoadSceneMode mode = LoadSceneMode.Single)
{
return Observable.FromCoroutine<Unit>(observer => HyperOptimizedFastAsyncOperationLoad(SceneManager.LoadSceneAsync(sceneName, mode), observer))
.Do(_ =>
{
// 型ベースでたぐり寄せる。Find系は避けたいとはいえ、シーン遷移時に一発だけなのでコスト的には許容できるでしょう。
var scenes = GameObject.FindObjectsOfType<SceneBase>();
var loadedScene = scenes.Single(x => !x.IsLoaded); // 一個だけになってるはず #雑
loadedScene.IsLoaded = true;
loadedScene.Argument = argument; // PresenterBase.BeforeInitializeが走る前にセットする
});
}
static IEnumerator HyperOptimizedFastAsyncOperationLoad(AsyncOperation operation, IObserver<Unit> observer)
{
if (!operation.isDone) yield return operation;
observer.OnNext(Unit.Default);
observer.OnCompleted();
}
}
なんてことはなく、LoadSceneAsyncが完了した時点でヒエラルキーに新しいシーンがぶちまけられているので、それのBeforeInitializeが走る前にArgumentにセットしておいてやる、というだけの割と単純なものです。ポイントは、BeforeInitializeの走るタイミングはStartということです。順序的に、LaodSceneAsyncが完了した時点で、新しいシーンのGameObjectのAwakeは走っています。なので、Awakeの前にArgumentを渡すのは何をどうやっても不可能です。しかし、Startの前に割り込むことは可能です。そこでルールとして遷移先のシーンでの初期化はStart以降に限定し(PresenterBaseがその辺を抽象化しているので実装者が意識する必要はない)、NavigateAsyncでは可能な限り最速のタイミングでArgumentをセットしにいきます。その秘訣がHyperOptimizedFastAsyncOperationLoadというフザケタ名前のコルーチンです。
yield return null vs yield return AsyncOperation
別にHyperOptimizedFastAsyncOperationLoadの中身は、見たまんまの超絶単純な yield return AsyncOperation です。そして、それこそが秘訣なのです。何を言ってるかというと……
IEnumerator WaitLoadAsyncA(AsyncOperation operation)
{
while (!operation.isDone)
{
yield return null;
Debug.Log(operation.progress); // 読み込み状態のプログレス通知
}
}
IEnumerator WaitLoadAsyncB(AsyncOperation operation)
{
yield return operation;
}
両者の違い、分かるでしょうか？ WaitLoadAsyncA のほうはプログレスを受け取るためにyield return nullでisDoneを監視するスタイル。WaitLoadAsyncBは直接待つスタイル。結果的に、どちらも待つことができます。プログレス通知は大事なので、WaitLoadAsyncAのようなスタイルを多用するほうが多いのではないかなー、と思います。WWWとか。が、しかし、両者には非常に大きな違いがあります。それは、完了時のタイミング。
わざわざ無駄に画像を作ってまで声を大にして言いたいんですが、直接AsyncOperationをyieldすれば、AwakeとStartの間に割り込めます。yield return nullでは普通に1フレ後になるのでStartまで完了しちゃってます。これは超絶デカい違いです、この微妙なコントロールが死ぬほど大事です。きっと役に立ちます。どこかで。ちなみに一番最初に説明したAsyncOperation.AsObservableという神メソッドはyield return nullで待ってます。クソですね。カスですね。ゴミですね。すみません……（これは次のUniRxのリリースではプログレス通知を使わない場合は直接yieldするように変更します、それまでの間は手動コルーチン作成で対応してください）
もう一つ、コルーチンの駆動を各SceneのStartCoroutineで行うと、LoadSceneMode.Single（遷移）の場合、遷移元シーンが破壊された瞬間に紐付いてるコルーチンも強制的に止まる（そしてDestroyは遷移先シーンのAwakeの前）ため、Argumentを渡すという行為は不可能です。が、UniRxのFromCoroutineで駆動させると、中立であるMainThreadDispatcherによるコルーチン駆動となるため、元のシーンが壊れるとかそういうのとは無関係にコルーチンが動き続けるため、その手の制限と付き合わなくても済みます。この辺は実際UniRx強い。
シーン表示を遅らせる
実は、今のとこ別にRx使う必要性はあんまありません、なくても全然出来るレベルです（まぁコルーチンが破壊される件は回避しにくいですが）。それではあんまりなので、もう一歩次のレベルに行きましょう。例えばシーン遷移時に、引数を元にネットワークからデータを読み取って、その間はNow Loadingで待つ。ダウンロードが完了したら表示する。こうした、なんとなく良くありそうな気がする話を、NavigationServiceで対応させてみましょう。
この、あんまり良くわからない例、SceneAボタンを押すとヒエラルキーにSceneBが表示されているけれど画面上には表示されていない、実際にはネットワークからデータをダウンロードしていて、それが完了したら、その結果と共にSceneBが表示される。というものです。なるほど……？
まず、SceneBaseにPrepareAsyncメソッドを追加します。
public abstract class SceneBase : PresenterBase
{
public object Argument { get; set; }
public bool IsLoaded { get; set; }
// このPrepareAsyncメソッドを新設する
public virtual IObservable<Unit> PrepareAsync()
{
return Observable.Return(Unit.Default);
}
protected override void OnAwake()
{
this.InitializeAsObservable().Subscribe(_ => IsLoaded = true);
}
}
PrepareAsyncが完了するまで表示を待機する、といった感じで、それをIObservableによって表明しています。これで遷移先のSceneBクラスを書き換えると
public class SceneB : SceneBase
{
public WwwStringPresenter display; // インスペクターから貼り付けてUnityEngineによるデシリアライズ時にセットされる(Awake前)
string wwwString = null;
protected override IPresenter[] Children
{
get { return new[] { display }; } // Sceneにぶら下がってる子をここで指定する（コードで！原始的！）
}
// 呼ばれる順番はPrepareAsync -> BeforeInitialize -> Initialize
public override IObservable<Unit> PrepareAsync()
{
var url = Argument as string; // 前のシーンからURL、例えば http://unity3d.com/ が送られて来るとする
// ネットワーク通信が完了するまでこのシーンの表示を待機できる
// (もし自分で試して効果が分かりにくかったら Observable.Timer(TimeSpan.FromSeconds(5)) とかに差し替えてください、それで5秒後表示になります）
return ObservableWWW.Get(url)
.Select(x => // 本当はForEachAsyncを使いたいのですがまだ未リリース。
{
wwwString = x; // 副作用さいこー
return Unit.Default;
});
}
protected override void BeforeInitialize()
{
// この時点で通信が完了してるので、小階層に渡す。
display.PropagateArgument(wwwString); // PresenterBase.PropagateArgumentで伝搬するルール
}
protected override void Initialize()
{
}
}
変えたところは、PrepareAsyncでWWW通信を挟んでいるところ。これが完了するまではシーン全体の表示が始まらない(BeforeInitializeが呼ばれない)です。表示に関しては、この程度の超絶単純な例では直接SceneBにTextをぶら下げたほうがいいんですが、無駄に複雑にするために、ではなくてPropagateArgumentの例として、もう一個、下にUI要素をぶら下げてます。それがWwwStringPresenterで、
public class WwwStringPresenter : PresenterBase<string>
{
public Text displayView;
protected override IPresenter[] Children
{
get { return EmptyChildren; }
}
protected override void BeforeInitialize(string argument)
{
}
// 親からPropagteArugmentで渡されてくる
protected override void Initialize(string argument)
{
displayView.text = argument;
}
}
こんな感じに、親(この場合だとSceneB)から値が伝搬されます、適切な順序で（ふつーにやってるとGameObjectの生成順序は不定なので、値の伝搬というのは単純なようで深く、やりようが色々あるテーマだったり）。さて、一見複雑というか実際、色々ゴテゴテしてきてアレな気配を醸しだしてきましたが、実際どんな状態なのかというと、こんな感じ。
この分かったような分からないような図で言いたいことは、値の流れです。シーン間はNavigateAsyncによりArgumentが引き渡され、シーン内ではPresenterBaseによって構築されたチェーンがPropagateArgumentにより、ヒエラルキーの上流から下流へ流れていきます。これにより、グローバルでの変数保持が不要になり、値の影響範囲が局所化されます。スコープが狭いというのは基本的にいいことです、見通しの良さに繋がりますから。分かっちゃいても実現は中々むつかしい、に対する小道具を色々揃えておくと動きやすい。
NavigateAsync最終形
おお、そうだ、PrepareAsyncに対応したNavigateAsyncのコードを出し忘れている！こんな形になりました。
public static class NavigationService
{
public static IObservable<Unit> NavigateAsync(string sceneName, object argument, LoadSceneMode mode = LoadSceneMode.Single)
{
return Observable.FromCoroutine<Unit>(observer => HyperOptimizedFastAsyncOperationLoad(SceneManager.LoadSceneAsync(sceneName, mode), observer))
.SelectMany(_ =>
{
var scenes = GameObject.FindObjectsOfType<SceneBase>();
var loadedScene = scenes.Single(x => !x.IsLoaded);
loadedScene.IsLoaded = true;
loadedScene.Argument = argument;
loadedScene.gameObject.SetActive(false); // 一旦非Activeにして止める
return loadedScene.PrepareAsync() // PrepareAsyncが完了するまで待つ
.Do(__ =>
{
loadedScene.gameObject.SetActive(true); // Activeにして動かしはぢめる
});
});
}
static IEnumerator HyperOptimizedFastAsyncOperationLoad(AsyncOperation operation, IObserver<Unit> observer)
{
if (!operation.isDone) yield return operation;
observer.OnNext(Unit.Default);
observer.OnCompleted();
}
}
足したコードは、Argumentをセットしたら即座にSetActive(false)ですね。これで画面に非表示になるのは勿論、Startも抑制されます。そうしてStartが止まっている間にPrepareAsyncを呼んでやって、終わったら再度 SetActive(true) にする、ことによりStartが発生しだして、PresenterBaseの初期化機構が自動で上流→下流への起動を開始します。
まとめ
実際にはPrepareAsyncだけでは足りなくて、シーンから出る時、シーンから戻ってきた時、機能としてシーンをキャッシュしてやろうとか、遷移でパラメータ渡ってくる前提だと開発時にパラメータが足りなくてダルいので任意で差し込めるようにする/開発用デフォルト用意するとか、色々やれることはあります、し、やったほうがいいでしょふ。それらも全てUniRx上で、IObservableになっていることにより、表現がある程度は容易になるのではないかと思います。非同期を表現する入れ物、が必要だというのは至極当然の答えになるのですけれど、そこにUniRxが一定の答え、定番を提供できているんじゃないかなー、と思いますね！些か長い記事となってしまいましたが、これに限らず応用例の発想に繋がってくれれば何よりです。
Advent Calendarの次は、@Miyatinさんです！
UniRx vNext
ところで実はいまものすごい勢いで作り変えています！性能もかなり上が（って）るんですが、割と分かりやすく大きいのは、スタックトレースが物凄く見やすくなります。意味不明度が極まった複雑なスタックトレースはRx名物でデバッガビリティが最低最悪だったのですが、相当まともになってます。例えば、以下の様なふつーのチェーンのDebug.Logで表示されるスタックトレースは
var rxProp = new ReactiveProperty<int>();
rxProp
.Where(x => x % 2 == 0)
.Select(x => x)
.Take(50)
.Subscribe(x => Debug.Log(x));
rxProp.Value = 100;
Before
After
劇的！Unityのスタックトレースの表示形式に100%フォーカスして、読みやすさ第一にハックしたので、圧倒的な読みやすさだと思います。スタックトレース芸極めた。普通にWhere.Select.Take.Subscribeがそのまま表示されてますからね。勿論、メソッドコール数が減っているのは単純に性能にも寄与しています。ここまでやれば文句もないでせう。
そんなvNextの完成時期ですが、今までやるやる詐欺すぎたのですが、そろそろ実際本当に出します。来週ぐらいには本当に出します。これは意地でも仕上げます（想像通りだけれど作業量は多いわコーナーケースの想定が複雑すぎて頭が爆発しそうになるしで辛い……）。というわけでもうちょっとだけ待っててください。