UniTask - Unity + async/awaitの完全でハイパフォーマンスな統合

2018-07-12

Unityでasync/await使えてハッピー。が、しかしまだ大々的に使われだしてはいないようです。理由の一つとして、Unityが標準でサポートする気が全くなさそう。少なくとも、Unityがフレームワークとしてasync/awaitには何一つ対応していない。async/awaitという道具立てだけじゃあ何もできないのです、フレームワークとして何らかのサポートがなければ機能しないわけですが、なんと、何もない……。

何もないことの理由はわからないでもないです。パフォーマンス面で不満/不安もありそうですし、マルチスレッドはC# Job System使ってくれというのは理にかなっている（私もそちらが良いと思います、つまりTaskのマルチスレッドな機能は原則使わない）。とはいえ、async/awaitは便利なので、このまま、便利だけど性能は微妙だから控えようみたいな扱い（あ、それ知ってる、LINQだ）になるのは嫌なのよね。まぁLINQは局所的なので使わないのは簡単なのだけど（実際、最近は私もあまりLINQ書いてないぞ！遅いからね！）、async/awaitは割と上位に伝搬していって汚染気味になるので、そもそも一度どこかで使うと使わない、という選択肢が割と取りづらいので、ならいっそむしろ超究極パフォーマンスのasync/awaitを提供すればそれで全部解決なのである。

という長ったらしい前置きにより、つまり超究極パフォーマンスのUnityのasync/await統合を提供するライブラリを作りました。場所は（面倒くさいので）UniRxに同梱です。というわけでなんと久しぶりにUniRxも更新しました……！(主にReactivePropertyが高速になりました、よかったよかった。PRとかIssueのチェックはこれからやります、いや、まず重い腰を上げたというのが何より大事なのですよ！)

GitHub/UniRx と、アセットストアに既に上がっています。

UniTask

何ができるか、について。

// この名前空間はasync有効化と拡張メソッドの有効化に必須です
using UniRx.Async;

// UniTask<T>をasyncの戻り値にできます、これはより軽量なTask<T>の置き換えです
// ゼロ（or 少しの)アロケーションと高速な実行速度を実現する、Unityに最適化された代物です
async UniTask<string> DemoAsync()
{
    // Unityの非同期オブジェクトをそのまま待てる
    var asset = await Resources.LoadAsync<TextAsset>("foo");

    // .ConfigureAwaitでプログレスのコールバックを仕込んだりも可能
    await SceneManager.LoadSceneAsync("scene2").ConfigureAwait(new Progress<float>(x => Debug.Log(x)));

    // 100フレーム待つなどフレームベースの待機(フレームベースで計算しつつTimeSpanも渡せます)
    // (次の更新でフレーム数での待機はDelayFrameに名前変えます）
    await UniTask.Delay(100); // be careful, arg is not millisecond, is frame count

    // yield return WaitForEndOfFrameのような、あるいはObserveOnみたいな
    await UniTask.Yield(PlayerLoopTiming.PostLateUpdate);

    // もちろんマルチスレッドで動作する普通のTaskも待てる（ちゃんとメインスレッドに戻ってきます）
    await Task.Run(() => 100);

    // IEnumeratorなコルーチンも待てる
    await ToaruCoroutineEnumerator();

    // こんなようなUnityWebRequestの非同期Get
    async UniTask<string> GetTextAsync(UnityWebRequest req)
    {
        var op = await req.SendWebRequest();
        return op.downloadHandler.text;
    }

    var task1 = GetTextAsync(UnityWebRequest.Get("http://google.com"));
    var task2 = GetTextAsync(UnityWebRequest.Get("http://bing.com"));
    var task3 = GetTextAsync(UnityWebRequest.Get("http://yahoo.com"));

    // 並列実行して待機、みたいなのも簡単に書ける。そして戻り値も簡単に受け取れる（これ実際使うと嬉しい）
    var (google, bing, yahoo) = await UniTask.WhenAll(task1, task2, task3);

    // タイムアウトも簡単にハンドリング
    await GetTextAsync(UnityWebRequest.Get("http://unity.com")).Timeout(TimeSpan.FromMilliseconds(300));

    // 戻り値はUniTask<string>の場合はstringを、他にUniTask（戻り値なし）、UniTaskVoid（Fire and Forget）もあります
    return (asset as TextAsset)?.text ?? throw new InvalidOperationException("Asset not found");
}

提供している機能は多岐にわたるのですが、

Unityの非同期オブジェクトをawaitできるように拡張（最速で動くように細心の注意を払って対応させています）
コルーチンやUniRxで出来るフレームベースのawaitサポート(Delay, Yield)
戻り値をTupleで受け取れるWhenAll, どれが返ってきたかをindexで受け取れるWhenAny, 便利なTimeout
標準のTaskよりも高速でアロケーションの少ないUniTask[T], UniTask, UniTaskVoid

となっています。で、何が出来るのかと言うと、ようはコルーチンの完全な置き換えが可能です。async/awaitがあります、っていう道具立てだけだと、何もかもが足りないんですね。ちゃんと機能するようにフレームワーク側でサポートさせてあげるのは必須なのですが、前述の理由（？）どおり、Unityはサポートする気が1ミリもなさそうなので、代わりに必要だと思える全てを提供しました。

Taskを投げ捨てよ

目の付け所がいかれているので、Taskを投げ捨てることにしました。Taskってなんなの？というと、asyncにする場合戻り値がTaskで強要される、という型。そして究極パフォーマンスの実現として、このTaskがそもそも邪魔。なんでかっていうと、歴史的経緯によりそもそもTaskは図体がデカいのです。異様に高機能なのは（TaskSchedulerがどうだのLongRunningがどうだの)、ただたんなる名残（或いは負の遺産）でしかない。アドホックな対応を繰り返すことにより(言語/.NET Frameworkのバージョンアップの度に)コードパス的に小さくはなっていったのですが(async/awaitするためだけには不要な機能がてんこ盛りなのだ！)、もういっそ全部いらねーよ、という気にはなる。

そこでC# 7.0です。C# 7.0からasyncの戻り値を任意の型に変更することが可能になりました。詳しくは言語仕様のAsync Task Types in C#に書いてありますが、Builderを実装することにより、なんとかなります。

というわけで、UniRx.Asyncでは軽量のTaskであるUniTaskと、そのためのBuilderを完全自前実装して、Unityに最適化されたasync/awaitを実現しました。

代わりにC# 7.0が必須のため、現状ではIncremental Compilerを導入する必要があります（現状のUnity 2017/2018はC# 6.0のため)

Incremental Compilerではなくても、恐らくUnity 2018の近いバージョンではC#のバージョン上がりそうな気配なので、先取りするのは悪くないでしょう。

PlayerLoop

UniRx.AsyncはUniRxに依存していません。そのため、GitHubのreleasesページではUniRxを含まないパッケージも提供しています。併せて使ったほうがお得なのは事実ですが、なしでも十分に機能します。

さて、UniRxではMainThreadDispatcherというシングルトンのMonoBehaviourにMicroCoroutine(というイテレータを中央管理するもの)を駆動してもらっていましたが、今回スタンドアロンで動作させるため、別の手段を取りました。それがPlayerLoopです（詳しくはテラシュールブログの解説が分かりやすい）。

これをベースにUpdateループをフックして、await側に戻す処理を仕掛けています。

Multithreading

掲げたのはNo Task, No SynchronizationContext。何故かというと、そもそもUnityの非同期って、C++のエンジン側で駆動されていて、C#のスクリプティングレイヤーに戻ってくる際には既にメインスレッドで動くんですよね。例えば AsyncOperation.completed += action とか。コルーチンのyield retunもそうですね、PlayerLoop側で処理されている。ようするに、本来SynchronizationContextすら不要なのです、全てメインスレッドで動作するので。

通常のC#はスレッドベースで、Windows FormsやWPF, ASP.NETなど諸々の事情を吸収するために存在していたわけですが、Unityだけで考えるなら完全に不要です。他のものにはないフレーム毎に駆動することと、本体がC#ではなくC++側にあるということが大きな大きな違いです。async/awaitやTask自体は汎用的にする必要があるため、それらの吸収層が必要（SynchronizationContext）なわけですが、当然ながらオーバーヘッドなので、取り除けるなら取り除いたほうが良いでしょう。そのために、UniTaskの独自実装も含めて、全てのコードパスを慎重に検討し、不要なものを消し去りました。

UniTaskはどちらかというとJavaScript的（シングルスレッドのための非同期の入れ物）に近いです。Taskは、そうした非同期の入れ物に加えてマルチスレッドのためなどなど、とにかく色々なものが詰まりすぎていて、あまりよろしくはない。非同期とマルチスレッドは違います。明確に分けたほうが良いでしょうし、UnityではC# JobSystemを使ったほうが良いので、カジュアルな用途以外（まぁラクですからね）ではマルチスレッドとしてのTaskの出番は少なくなるでしょう。

嬉しいこととして、スレッドを使わないのでWebGLでもasync/awaitが完全に動作します。

Rx vs Coroutine vs async/await

もう結論が出ていて、async/await一本でOK、です。まずRxには複数の側面があって、代表的にはイベントと非同期。そのうち非同期はasync/awaitのほうがハンドリングが用意です。そしてコルーチンによるフレームベースの処理に関してはUniTask.DelayやYieldが解決しました。ので、コルーチン→出番減る, async/await → 非同期, Rx → イベント処理というように分離されていくと思われます。

C# Standard vs Unity

正直なところ私は別にUnityがC#スタンダードに添わなくてもいいと思ってるんですよね。繰り返しましが、Unityの本体はC++の実行エンジンのほうで、C#はスクリプティングレイヤーなので。C#側が主張するよりも、C++に寄り添うことを第一に考えたほうが、よい結果がもたらされると思っています。よりC#に、というならPure C#ゲームエンジンでないとならないですが、商業的にはほぼ全滅であることを考えると、Unityぐらいの按配が実際ちょうどいいのだろうな、と。理想もいいんですが、ビジネスとしての成功がないと全く意味がないので。

と、いうわけで、C# JobSystemは大歓迎だしBurst Compilerは最高 of 最高なわけですが（そしてECSなんてそもそもオブジェクト指向ですらなくなる）、さて、Task。UniTaskの有用性や存在意義については、よくわかってもらえたと思います！そのうえで、それを分かったうえでもノンスタンダードな選択を取るべきなのか論は、それ自体は発生して然りです。

まぁ、まずUnityだとそもそもC# 7.0が来たら片っ端からValueTask（という、TとTaskのユニオンがC# 7.0から追加された）に置き換え祭りは発生するでしょう。実際async祭りで組むと、「同期で動くTask」がどうしても多く発生してしまい、無駄なアロケーション感半端ないので、ValueTask主体のほうがよい。

更にその上で.NET Core 2.1ではValueTaskにIValueTaskSourceという仕掛けが用意されて、これは何かと言うと、やっぱりasync/awaitの駆動においてTaskを無視するための仕組みです（現状はSystem.IO.Pipelinesというこれまたつい先週ぐらいに出た機能のみ対応）。そう、別にUnityだけじゃなくて通常の.NETでもTaskはオーバーヘッドと認識されているのだ……。

つまりなんというか、そう、そもそもC#本流ですら割と迷走しているのだ……。存在すると思っているStandardなんてもはやないのだ……。てわけで、別にUniTask、いいんじゃない？とか思ってしまいますがどうでしょう。どうでしょうね、それはさすがにポジショントークすぎにしても。

ようはポリシーとして、asyncで宣言した際に、TaskにするかValueTaskにするかUniTaskにするかを迫られます。逆に言えばそれだけです。あれ、意外と人畜無害。そう、意外と人畜無害なのです。よし、なら、とりまやってみるか。いいんじゃないかな？別に最悪、一括置換で戻したり進めたり割と容易なので。あと、ちなみに、UniTaskがUnityでデファクトスタンダードになれば、尚更迷う必要性はなくなるので、むしろ是非みんなでデファクトスタンダードまで持っていきましょう:)

まとめ

非同期革命の幕開け！そもそもこれぐらいやらないと世論は動かない、というのもあるので、フルセットでどーんと凄い（っぽい）（実際凄い）のを掲示することにはめちゃくちゃ意味があります。UniTaskが流行っても流行らなくても、この掲示にはめちゃくちゃ意味があるでしょう。UniRx.Asyncが何を実現したかを理解することは非常に重要です、教科書に出ますよ！

それと、UniRx全然更新していなくてごめんなさい、があります。ごめんなさい。今回、ReactivePropertyのパフォーマンス向上を（ようやく）入れたり、今後はちゃんと面倒みていくのでまたよろしくおねがいします。

Open Collective/UniRxというところで寄付/スポンサー募集もはじめたので、よければ個人/企業で入れてくれると嬉しいですね……！今ならUniRxのGitHubページのファーストビューにロゴが出るので、特に企業などはアピールポイントです……！

Microsoft MVP for Visual Studio and Development Technologies(C#)を再々々々々々々受賞しました

2018-07-02

新規は毎月で、更新は7月に統一という周期らしく、全然忘れていたのですが、当日はインターネット的にはそわそわした空気を感じたりなかったりはします。変わらず、Visual Studio and Development Technologies、つまりC#を受賞しました。

↑このリングに一個足されます（後日発送）

去年はMessagePack for C#やUtf8Jsonといった、世界的にもヤバいレベルのライブラリの作成（とその実装詳細の紹介）が、最も直接的な成果ですね。私が担っているのはOSSと、実践的で先鋭的なC#、その実証と共有というところであり、世界的に見ても成果を示せているという自信もあり、またMVPはその客観的な証明と考えています。偉そう！まぁ実際成果はえらい。

毎年、今までの延長線じゃない何かをやりたいんだ！と言いつつ、手癖のバリエーション勝負になってる気がしなくもないのがどうなのよ、と思うところもあるのですが、まぁそれはそれでしつこく繰り返すことで、ちゃんと深化しているので、よしとはしておきましょう。近年は C# x 無限大のパフォーマンス、を勝負の軸にしているのですが、結構意義はあると思います。

4月の退職エントリでは、これから何をやっていくのか模索中、という感だったのですが、結果的に今は、割とちゃんと会社を立てて、その名義で仕事を受けています。New World, Inc. ← 未だに何もデザインされていない。UnityやgRPC関連でのアドバイスとかやっていますので、興味あればお問い合わせくだしあ。

去年よりも上を、去年よりも上を、とハードルは無限に高くなっていくので、個人にせよ会社にせよ、世界にインパクトを残していける何かをやっていこう、というのが目標ですね。手元でも一つ二つ、仕込んでいるのがあるのできっと近いうちにお見せ出来ると思います。願わくばそれでチャリンチャリンできるといいんですが（笑）、まぁできなくてもそれはそれですねん。