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ページのファーストビューにロゴが出るので、特に企業などはアピールポイントです……！