Best practices: Async vs. coroutines - Unite Copenhagen 2019
•Als PPTX, PDF herunterladen•
7 gefällt mir•21,949 views
Before async was introduced in Unity 2017, asynchronous routines were implemented using coroutines and/or callbacks. This video covers the benefits of async over coroutines. You'll see how one example problem – building an asynchronous prompt popup – can be solved using async vs coroutines. Speaker: Johannes Ahvenniemi - Seriously Digital Entertainment Watch the session here: https://youtu.be/7eKi6NKri6I
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Best practices: Async vs. coroutines - Unite Copenhagen 2019
Ähnlich wie Best practices: Async vs. coroutines - Unite Copenhagen 2019 (20)
Mehr von Unity Technologies
Mehr von Unity Technologies (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Best practices: Async vs. coroutines - Unite Copenhagen 2019
- 2. Async vs Coroutines: Best Practices Johannes Ahvenniemi Lead Programmer, Seriously Digital Entertainment
- 3. About me 3 — Started with: BASIC — First published “indie” game: Java — First professional job: ActionScript 3 (Flash) — Favourite language: C++ — More tools in the box: C#, Clojure, Lua, JavaScript, OpenGL… — Unity developer since 2014 — Struggling with “callback hell”
- 5. Coroutines 5 — Useful for spanning logic across multiple frames — Cooperative multitasking (Single threaded) — Clever utilisation of C# generators (IEnumerators) — This talk is about Unity’s Coroutines, not generators — Familiar from Go, Lua, Python and many other languages
- 6. async/await 6 — Not intended for replacing Coroutines — Useful for handling non-blocking IO (and long lasting routines, i.e. threads) — Old C# feature (originating from F# (originating from Haskell)) — Now also in JavaScript, Python, Dart, C++, Rust… — Finally introduced in Unity 2017
- 7. Comparison
- 8. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 9. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 10. 10 Disclaimer: The following examples aren’t production quality. They are full of memory leaks and bad practices. Don’t just copy these examples into your product!
- 11. Coroutine Doesn’t have return values IEnumerator Start() { IEnumerator enumerator = SelectButton(); yield return enumerator; Button selectedButton = (Button)enumerator.Current; Assert.IsTrue(selectedButton != null); Debug.Log(selectedButton.name); } static IEnumerator SelectButton() { Button selectedButton = null; Button[] buttons = FindObjectsOfType<Button>(); foreach (Button button in buttons) { Button b = button; b.onClick.AddListener(() => selectedButton = b); } while (selectedButton == null) { yield return null; } yield return selectedButton; } 11 Async Has return values async void Start() { Button selectedButton = await SelectButton(); Debug.Log(selectedButton.name); } static async Task<Button> SelectButton() { Button[] buttons = FindObjectsOfType<Button>(); var tasks = buttons.Select(PressButton); Task<Button> finishedTask = await Task.WhenAny(tasks); return finishedTask.Result; } static async Task<Button> PressButton(Button button) { bool isPressed = false; button.onClick.AddListener(() => isPressed = true); while (!isPressed) { await Task.Yield(); } return button; }
- 12. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 13. Coroutine Can’t run synchronously IEnumerator Start() { Debug.Log($"Frame: {Time.frameCount}"); yield return Function(); Debug.Log($"Frame: {Time.frameCount}"); } static IEnumerator Function() { if (false) yield return null; } 13 Async Can run synchronously async void Start() { Debug.Log($"Frame: {Time.frameCount}"); await Function(); Debug.Log($"Frame: {Time.frameCount}"); } static async Task Function() { if (false) await Task.Yield(); } Outputs: Frame: 1 Frame: 2 Outputs: Frame: 1 Frame: 1
- 14. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 15. 15
- 16. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 17. Coroutine Doesn’t support try/catch public class Root : MonoBehaviour { IEnumerator Start() { try { yield return MainMenu(); } catch (Exception) { SceneManager.LoadScene("Error"); throw; } } } 17 Async Supports try/catch public class Root : MonoBehaviour { async void Start() { try { await MainMenu(); } catch (Exception) { SceneManager.LoadScene("Error"); throw; } } } Compiler error! Works!
- 18. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 19. 19 Coroutine Doesn’t preserve call stack Async Preserves call stack
- 20. 20 Coroutine Doesn’t preserve call stack Async Preserves call stack
- 21. 21 Coroutine Doesn’t preserve call stack Async Preserves call stack
- 22. 22 Async call stack in the profiler :(
- 23. 23 Mind the stack! Watch out for asset references in the stack! UnloadUnusedAssets will unload the assets but might cause surprises My suggestion: Don’t await non-additive scenes from non-additive scenes
- 24. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 25. Coroutine Always shows exceptions void Start() { this.StartCoroutine(Function()); } static IEnumerator Function() { yield return null; Debug.Log("About to throw exception"); throw new Exception(); } 25 Async Can hide exceptions void Start() { Function(); } static async Task Function() { await Task.Yield(); Debug.Log("About to throw exception"); throw new Exception(); }
- 26. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 27. Coroutine Doesn’t always exit IEnumerator ShowEffect(RawImage container) { var texture = new RenderTexture(512, 512, 0); try { container.texture = texture; for (int i = 0; i < 100; ++i) { /* * Update effect */ yield return null; } } finally { texture.Release(); } } 27 Async Always exits async Task ShowEffect(RawImage container) { var texture = new RenderTexture(512, 512, 0); try { container.texture = texture; for (int i = 0; i < 100; ++i) { /* * Update effect */ await Task.Yield(); } } finally { texture.Release(); } } Leaks if owning MonoBehaviour is destroyed! Never leaks!
- 28. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 29. Coroutine Lifetime tied to a MonoBehaviour IEnumerator Start() { this.StartCoroutine(this.Rotate()); yield return new WaitForSeconds(1.0f); Destroy(gameObject); } IEnumerator Rotate() { while (true) { transform.Rotate(Vector3.forward, 1.0f); yield return null; } } 29 Async Lifetime handled manually async void Start() { this.Rotate(); await Task.Delay(1000); Destroy(gameObject); } async void Rotate() { while (true) { transform.Rotate(Vector3.forward, 1.0f); await Task.Yield(); } } Throws NullRef Exception!Stops silently!
- 30. 30 Async Lifetime handled manually Fixed? No. async void Start() { var cts = new CancellationTokenSource(); this.Rotate(cts.Token); await Task.Delay(1000); cts.Cancel(); Destroy(this.gameObject); } async void Rotate(CancellationToken ct) { while (!ct.IsCancellationRequested) { this.transform.Rotate(Vector3.forward, 1.0f); await Task.Yield(); } }
- 31. Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers Coroutine Async Doesn’t have return values Has return values Can’t run synchronously Can run synchronously Doesn’t work without the engine Works without the engine Doesn’t support try/catch Supports try/catch Doesn’t preserve call stack Preserves call stack Always shows exceptions Can hide exceptions Doesn’t always exit Always exits Lifetime tied to a MonoBehaviour Lifetime handled manually Familiar to most Unity developers Unfamiliar to many Unity developers
- 32. Example: Creating a prompt popup 32
- 33. 33
- 34. public class PromptPopup1 : MonoBehaviour { public Button buttonAccept; public Button buttonCancel; public Button buttonClose; public static async Task<bool> Spawn() { PromptPopup1 p = await Utils.LoadScene<PromptPopup1>("Popup", LoadSceneMode.Additive); Button selected = await Utils.SelectButton(p.buttonAccept, p.buttonCancel, p.buttonClose); return selectedButton == p.buttonAccept; } } 34 Simple prompt popup
- 35. public class PromptPopup2 : MonoBehaviour { public Button buttonAccept; public Button buttonCancel; public Button buttonClose; public static async Task<bool> Spawn() { PromptPopup2 p = await Utils.LoadScene<PromptPopup2>("Popup", LoadSceneMode.Additive); Task<Button> selectButtonTask = Utils.SelectButton(p.buttonAccept, p.buttonCancel, p.buttonClose); Task pressBackButtonTask = Utils.WaitForPressBackButton(); Task finishedTask = await Task.WhenAny(selectButtonTask, pressBackButtonTask); await finishedTask; // Propagate exception if the task finished because of exception return finishedTask == selectButtonTask && selectButtonTask.Result == p.buttonAccept; } } 35 Implement Android back button
- 36. 36 Implement Android back button public class PromptPopup2 : MonoBehaviour { public Button buttonAccept; public Button buttonCancel; public Button buttonClose; public static async Task<bool> Spawn() { PromptPopup2 p = await Utils.LoadScene<PromptPopup2>("Popup", LoadSceneMode.Additive); Task<Button> selectButtonTask = Utils.SelectButton(p.buttonAccept, p.buttonCancel, p.buttonClose); Task pressBackButtonTask = Utils.WaitForPressBackButton(); Task finishedTask = await Task.WhenAny(selectButtonTask, pressBackButtonTask); await finishedTask; // Propagate exception if the task finished because of exception return finishedTask == selectButtonTask && selectButtonTask.Result == p.buttonAccept; } }
- 37. public class PromptPopup3 : MonoBehaviour { public Button buttonAccept; public Button buttonCancel; public Button buttonClose; public static async Task<bool> Spawn(CancellationToken ct) { PromptPopup3 p = await Utils.LoadScene<PromptPopup3>("Popup", LoadSceneMode.Additive, ct); var selectButtonTask = Utils.SelectButton(ct, p.buttonAccept, p.buttonCancel, p.buttonClose); var pressBackButtonTask = Utils.WaitForPressBackButton(ct); var finishedTask = await Task.WhenAny(selectButtonTask, pressBackButtonTask); await finishedTask; // Propagate exception if the task finished because of exception return finishedTask == selectButtonTask && selectButtonTask.Result == p.buttonAccept; } } 37 Implement manual cancellation
- 38. public class PromptPopup4 : MonoBehaviour { public Button buttonAccept; public Button buttonCancel; public Button buttonClose; public static async Task<bool> Spawn(CancellationToken ct) { PromptPopup4 p = await Utils.LoadScene<PromptPopup4>("Popup", LoadSceneMode.Additive, ct); var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(ct); var linkedCt = linkedCts.Token; var buttonTask = Utils.SelectButton(linkedCt, p.buttonAccept, p.buttonCancel, p.buttonClose); var pressBackButtonTask = Utils.WaitForPressBackButton(linkedCt); var finishedTask = await Task.WhenAny(buttonTask, pressBackButtonTask); await finishedTask; // Propagate exception if the task finished because of exception linkedCts.Cancel(); return finishedTask == buttonTask && buttonTask.Result == p.buttonAccept; } } 38 Clean up remaining tasks
- 39. public class PromptPopup5 : MonoBehaviour { public Button buttonAccept; public Button buttonCancel; public Button buttonClose; public static async Task<bool> Spawn(CancellationToken ct) { PromptPopup5 p = await Utils.LoadScene<PromptPopup5>("Popup", LoadSceneMode.Additive, ct); using (var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(ct)) { var linkedCt = linkedCts.Token; var buttonTask = Utils.SelectButton(linkedCt, p.buttonAccept, p.buttonCancel, p.buttonClose); var pressBackButtonTask = Utils.WaitForPressBackButton(linkedCt); var finishedTask = await Task.WhenAny(buttonTask, pressBackButtonTask); await finishedTask; // Propagate exception if the task finished because of exception linkedCts.Cancel(); return finishedTask == buttonTask && buttonTask.Result == p.buttonAccept; } } } 39 Dispose linked CancellationTokenSource
- 40. public static async Task<bool> Spawn(CancellationToken ct) { PromptPopup6 p = await Utils.LoadScene<PromptPopup6>("Popup", LoadSceneMode.Additive, ct); var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(ct); try { var linkedCt = linkedCts.Token; var buttonTask = Utils.SelectButton(linkedCt, p.buttonAccept, p.buttonCancel, p.buttonClose); var pressBackButtonTask = Utils.WaitForPressBackButton(linkedCt); var finishedTask = await Task.WhenAny(buttonTask, pressBackButtonTask); await finishedTask; // Propagate exception if the task finished because of exception linkedCts.Cancel(); return finishedTask == buttonTask && buttonTask.Result == popup.buttonAccept; } finally { linkedCts.Dispose(); popup.StartCoroutine(Utils.PlayPopupCloseAnimation(p.gameObject)); } } 40 Implement closing the popup
- 41. public static async Task<bool> Spawn(CancellationToken ct) { PromptPopup6 p = await Utils.LoadScene<PromptPopup6>("Popup", LoadSceneMode.Additive, ct); var linkedCts = CancellationTokenSource.CreateLinkedTokenSource(ct); try { var linkedCt = linkedCts.Token; var buttonTask = Utils.SelectButton(linkedCt, p.buttonAccept, p.buttonCancel, p.buttonClose); var pressBackButtonTask = Utils.WaitForPressBackButton(linkedCt); var finishedTask = await Task.WhenAny(buttonTask, pressBackButtonTask); await finishedTask; // Propagate exception if the task finished because of exception linkedCts.Cancel(); return finishedTask == buttonTask && buttonTask.Result == popup.buttonAccept; } finally { linkedCts.Dispose(); popup.StartCoroutine(Utils.PlayPopupCloseAnimation(p.gameObject)); } } 41 Implement closing the popup
- 42. 42
- 43. Choosing between Async and Coroutines 43
- 44. Choosing between Async and Coroutines Rules of Thumb 44 1. Use async when you deal with IO (User input, Network calls) 2. Use coroutines for fire-and-forget routines. 3. Don’t intertwine them
- 45. Thank you! Johannes Ahvenniemi Lead Programmer, Seriously Digital Entertainment johannes@seriously.com
- 46. We are hiring! Johannes Ahvenniemi Lead Programmer, Seriously Digital Entertainment johannes@seriously.com
Hinweis der Redaktion
- Hello! And this talk is async vs coroutines, best practices. My name Johannes Ahvenniemi, I’m from Seriously Digital Entertainment Let’s start by asking who here is a coder? I hope most of you because this is a very code focused talk.
- I’ll start with telling about me, so you can better relate to what I’m saying. A basis for how I ended up talking about this subject. I started quite young, my first language was a BASIC, for Amstrad. We did a PC, but Amstrad was more approachable. You’d just type in commands and it would print and draw stuff for you. I did move on to QBasic on PC at some point. Who here has used QBasic? That was a lot of fun, right? You would just write this sequential code and do amazing stuff with it. Coding used to be so simple! I did some C++ in between but when Java came I was able to make easily distributable browser games, so that’s how I published my first game. Something like ten people played it, which was cool. Who where has made a game in Java? It’s not really great for games, is it… Then I realised how many players I’d get if I downgraded to flash! That’s how I saw it, as a downgrade. So I did that, and I’m happy I did because I achieved some mild success with my Flash games. Flash is also how I landed my first actual job in the industry, a flash developer at Rovio. Working on browser versions of Angry Birds. I also did some C++ and Lua at Rovio, and I use mostly C++ in my personal projects. It remains my favourite language for game dev. It’s a great language as long as you don’t go crazy with all the features available. Other technologies in my toolbox… A bunch of mostly web and game dev related stuff, and I’m also a fan of functional programming, so I use Clojure when I want to expand my mind. In case you didn’t know, functional programming is also good for your soul. - I started using Unity in 2014 when I joined Seriously, started working on the hit puzzle game Best Fiends. I hope some of you have heard of it. Best Fiends is a F2p so I’ve done lots of UI work. There’s lots of UI work that goes to F2P games, with all the sale and event popups and so on. And that’s fun but challenging work. Because these popups use lots of buttons, And buttons are handled with callbacks, And when you start chaining these callbacks you end up in what web developers call callback hell. So callback hell is a thing also in Unity, not only JavaScript. In JavaScript however we recently got rid of callbacks thanks to async. With async I could write my code sequentially once again, just like back in the days with QBasic. So I’m really happy for having async finally in Unity So we finally got to the topic
- , async! And Coroutines too of course But mainly async because it’s the new and exciting technology Actually, this talk is more async, but not only because it’s new and exciting but because it’s new and scary. But it’s also about coroutines because it can be really difficult to understand when to use which, async or coroutines.
- Let’s start with the good old coroutines. Who here has used them before? So you know coroutines are good for spanning logic across time. That’s pretty much what Unity documentation also states, I just reworded it to fit on one line. They are single threaded, which is important because the engine features are accessible only from the main thread. Under the hood they are actually just C# generators. So they aren’t exactly a language feature, but there is no magic under the hood. And to clarify, I’m focusing on Coroutines as an engine feature. When I’m saying that you can or can’t do something with coroutines, the same might not apply to generators. It’s also not a new concept. It’s available in many languages, I just listed a few here. So it’s clearly a useful.
- How about async/await. That’s right. We’re actually talking about two concepts here, async AND await, but I’ll just refer to this duality as simply async from now on. When async came to Unity, there was lots of discussion online about how you can now replace coroutines with async. I’m going to argue against that. I’m arguing that async is not intended for replacing coroutines. They can be very similar though. In some other language it can be hard to tell them apart. For example Clojure borrowed Goroutines from Go and called it async. Go figure. So what is async for then According to documentation, async is useful for handling non-blocking input. And threading, but I’m not talking about threads here today, for better focus. Before async these things were handled using callbacks. So async isn’t intended for replacing coroutines, async is pretty much a better way of handling callbacks. Async originates from functional languages. By now it’s spread from C# to many popular languages, so I would say it’s a very successful feature. We shouldn’t be afraid of using it. Finally we got it in Unity 2017, and now we are here wondering what to do with them.
- So let’s get started with the comparison between async and coroutines. This turned out to be quite a list, so hang tight.
- Alright, here’s the list. Coroutines on the left side, async on the right side. Now, some of the don’t seem that relevant, like the 2nd one, running async synchronously. And some of these are quite weird, like the 7th one, coroutines not always exiting. What’s up with that? That’s why I will go through all of these, with code examples, so we can understand them better.
- First one. Coroutines don’t have return values. Async does. This is the most important one. To put it simply, it’s the true reason to pick async over coroutines. The rest are just details If you need an asynchronous operation to return a value, you use async. That’s it. Our first code example shows how this works.
- But before that, a brief disclaimer: These examples are terrible. You don’t want to use them. They are designed to present ideas, they are not meant to be used as is. So please, don’t. Okay? Let’s do it.
- In this example we wait for a button press and log the name of the button. The async version’s Start method describes this well. Wait for select button, log name. Doesn’t get simpler than that, right? The coroutine on the other hand… So I lied. You CAN have return values with coroutines, like in this example, but not if you value your pride as a clean coder. I’m not even sure it works. It seemed to work! But with anything more complex, I wouldn’t dare to try this. The bottom line is: coroutines don’t have return values! Async on the other hand does. And it looks amazing! It almost feels like it was made for this. And it was! Async was created for handling asynchronous input. A button press is exactly that. It happens asynchronously at some point. The callback is wrapped in the PressButton method. We yield until it happens. And then in SelectButton we await for the first button press task to finish, and we return the pressed button. There’s also a Linq operation there, can you see it? If you can use Linq to handle your input, you must be doing something right. Also Linq is good for your soul, in case you didn’t know. Understanding what goes on here is vital to understand the benefits of async. The point of this example is to convince the non-believers that async does have a use case where coroutines don’t really cut it. Now are you convinced? Good.
- Next one! A less exciting one. Quite a weird one. Why would you even want to run async synchronously? Well, our games are asynchronous, right? Things happen over time, frame by frame, picking up user input along the way. But what if we want to run the game in batch mode? We’d just give a list of inputs as parameter and we’d get out the end state. Let’s say it’s for testing purposes, or maybe we’re validating a high score some user got. Now, this should be a synchronous operation. Give input, get result. There is nothing we need to “wait” there. Well, turns out this is tricky with coroutines. With async it’s at least less tricky. Check this out:
- Look at the outputs. Why did we lose one frame there? Even with the if (false) there, it still ends up losing one frame somewhere. It’s not synchronous! And that’s annoying! With async, we don't have this issue. With async we know we at least CAN run our logic synchronously if the need be. And that’s great.
- The third one is related to the previous one. If we want to run the game in the cloud, for score validation for example, and if our logic uses coroutines, we need to put the whole Unity engine in the cloud. If we don’t use engine features we can run it in headless mode, which is much simpler and faster I don’t have a code example of this so I’m letting Drake explain it to you:
- You can’t have coroutines without the engine. Async you can. Of course if your logic needs the engine for stuff like physics, there’s no way around it. But for something like a matching game, it doesn’t NEED the engine for anything, and we can theoretically run it without Unity. Makes it much easier to put it in the cloud.
- Coroutines don’t support try/catch. Async does. That’s pretty straight forward. A very powerful feature in async.
- Now we can finally do this. And this is a big one. It’s not only about try catch. With async we can build our whole game as sequential chain of logic. Everything starting from a Root, which is waiting the main menu, which is maybe waiting for a popup, which is waiting for a button press, and so on. There are many benefits to this approach, and one is better error handling. When an uncaught exception occurs in our logic, when everything is lost, we can just load an error scene saying that we’re sorry, please restart the game. Or even better, put this thing in a while loop and give a restart button. With Coroutines we simply can’t do this kind of things. They aren’t designed for this. They don’t even compile if you try to do this.
- This is an interesting one. Who thinks preserving the call stack is a positive thing? Hands up if you think so. Who thinks it’s a bad thing? Hands up. The rest of you either know it’s a trick question… or you spaced out. I don’t blame you. Turns out both have pros and cons. And now, I must point out that I’m spilling some lies here. It’s not exactly this simple. But it’s a pragmatic way of looking at this, so I’m going with it.
- Here is the logging of a NullReferenceException originating from somewhere The coroutine one is less intimidating. Not obvious, but it’s ok. But it’s also less informative. We see the exception is coming from DoStuff, but we have no idea how we ended up there! As you know, debugging exceptions is much easier when you see the call stack telling you how you ended up there. Where did that null value originate from. But Coroutines don’t tell you the stack. You’ve noticed this right? It’s annoying! Async does give you the call stack. It’s a bit scary looking, but it’s there. Look here: DoStuff, DoSomething, Start. Now you have something to work with. You’ll get used to the messy output.
- Here is the logging of a NullReferenceException originating from somewhere The coroutine one is less intimidating. Not obvious, but it’s ok. But it’s also less informative. We see the exception is coming from DoStuff, but we have no idea how we ended up there! As you know, debugging exceptions is much easier when you see the call stack telling you how you ended up there. Where did that null value originate from. But Coroutines don’t tell you the stack. You’ve noticed this right? It’s annoying!
- Async does give you the call stack. It’s a bit scary looking, but it’s there. Look here: DoStuff called by DoSomething called by Start. Now you have something to work with. The output is just a bit messy, but you’ll get used to it.
- THIS however you don’t get used to. It’s extremely annoying. This is what the async stack looks like in the profiler. Look at the size of that! And this is only a fraction of the whole thing! It’s all I could fit on my 4k monitor! It’s really quite a mess. I hope Unity does something about this… You really don’t want to be clicking through that to reach the leaf nodes. Using the keyboard helps. Only recently I found the fastest way to get to the leaf nodes: Adjust your key repeating interval on your OS to the minimum, and hold down the right button. Before I figured that I lost some brain cells pressing “down” “right” “down” “right”. Jokes aside
- This is an actual warning. Unity doesn’t automatically unload assets referenced in your execution stack. Remember how I advertised how you can turn your app into one sequential flow? Root awaiting the main menu awaiting game scene, game scene awaiting the win scene, win scene awaiting the gacha scene and so on. But now you risk referencing assets in all these scenes in your execution stack. Unity won’t unload these assets automatically. This rarely is a problem with coroutines. It can happen with Coroutines too, but it doesn’t tend to be a problem due to how they are normally used. You could use UnloadUnusedAssets. That will clear assets despite references in the call stack. You could get away by doing this. But then again somewhere you might depend on the assets not being unloaded, so I can’t recommend doing that. Instead I recommend not going crazy with stacking async calls. Especially don’t await non-additive scenes from other non-additive scenes. Return early and let the root decide where to go next. Never go crazy with new tools…
- Now a small win for Coroutines! How come async doesn’t always show exceptions? Well, look a this
- The implementations are equal, but the log doesn’t show the exception in the async version. The Debug Log is printed but no-one is noticing and logging the exception! It’s an uncaught exception no one catches. What’s that, an un-uncaught exception? - Now, this is a stupid example. You would never write code like this. You would never return a Task and not await it. But the point here is that weird stuff happens if you don’t know what you’re doing. This example is supposed to scare you a bit. To think twice before choosing async over coroutines just because it’s new and shiny. You will end up fighting a completely new set of problems. So as with any new tool, you need to be mindful of what you’re doing.
- This is a surprising win for async. When a MonoBehaviour owning a Coroutine dies, the coroutine isn’t actually STOPPED. It’s just never resumed again. Let’s see how this can be a problem
- We have this kind of code in our project at the moment. It’s a bit scary actually. Here’s what we do: We allocate a render texture and assign it to a UI component. For 100 frames we apply filters and stuff to the render texture, creating a cool animated effect. Think of Final Fantasy 7’s effect for transition from world map to battle. Once done we have to release the texture. This is important because Unity won’t release it automatically. But what if the MonoBehaviour running the coroutine dies? The coroutine will never be resumed again. It will never reach the finally block! This is crazy! What’s the point of finally if it doesn’t always happen!? Async on the other hand is fine. You can’t really mess it up. So when ever you see a finally or using block in a Coroutine, watch out!
- So the lifetime of a coroutine is tied to a monobehaviour. This is a big win for Coroutines. This can be extremely convenient. Without this feature I think Coroutines might not be worth it. Without this, the talk could as well been titled ten reasons to ditch Coroutines, or how I learned to love async. So this feature really justifies the existence of Coroutines. Let’s see an example of how this can be useful
- Here we have a component that rotates the game object seemingly forever, but the game object is destroyed after a second With Coroutines, as the owning MonoBehaviour dies, the coroutine silently stops But async… Well NOW async decides it’s a good time to explain something went wrong. That we are trying to access the transform of a destroyed game object. But we don’t really want that exception, do we? It’s an exception we don’t want our QA to come asking us about. We just want it to die silently. And null checks isn’t an answer. Then what do we do?
- We handle it manually with CancellationTokens! That’s the async way. Does this fix the problem? No it doesn’t. What if some other script destroys the game object before the timer runs out? Then we have the same problem. So do we cancel it in OnDestroy? Maybe. But now we’re starting to add complexity that we don’t need! We can just use Coroutines! So it seems like Coroutines still have a place in our world: Coroutines are great for this kind of fire-and-forget routines. Routines that never return anything, routines that can silently die away when not needed, routines that are just for visuals. Next one.
- Last one. More of a psychological one. Coroutines are familiar to us. We’ve already used them a bunch, for years, and done beautiful things with them. There is no reason replace them with a new tool, with all new quirks and pitfalls, if there isn’t a good reason. By now you hopefully already learned that Async is different from Coroutines. It’s a new set of issues you need to be mindful of. If you still think it’s a good idea to just throw out your coroutines and replace them with async, stay put.
- In this next section we’re going to build a prompt popup using async. This example will both show the power and the responsibility that comes with async.
- We are creating something like this. An additive scene with a couple of buttons for accepting or declining something. And a close button. That’s simple, right?
- Ha, and it WAS simple. Here we have a MonoBehaviour with three buttons. We use our utility SelectButton from the previous section to wait for the user to pick one. Finally we return true or false, depending on if the user accepted the GDPR or not. We’re also using a tiny utility function for loading the scene and finding the MonoBehaviour in that scene. Just to keep our example short and nice. Also you can see I’m using terrible naming convention, calling the popup instance p, just so I can fit everything horizontally on one line. Was that it? No it wasn’t. That’s why the behaviour is called PromptPopup1. It means there will be a 2 and a 3 at least! So let’s get cracking! What’s missing?
- We forgot the back button. We’re making a mobile game, we need to support the android back button. No problem, let’s add it. We have a Utility function for it, really simple. Now, async is fantastic when it comes to handling multiple simultaneous tasks. Here we wait for either one of the UI buttons to be pressed, or for the Android back button to be pressed. WhenAny returns the task that finishes first. If the finished task is the button task, and the accept button was pressed, we return true. Back button means “no” What about that weird await in the middle?
- That one. The comment explains it. But still, what? The thing is, if a task finishes because of an exception, WhenAny won’t tell it to you straight. It will just tell you something finished. But of course we don’t want to continue if there was an exception. We have no idea what state our application is in. So we need to dig out the truth ourselves! This is a neat way of doing that. If the task was finished because of an exception, awaiting it again rethrows that exception. Otherwise it does nothing. Just a bit of boiler plate, we can live with this. What else did we forget? We forgot manual lifetime management.
- We forgot cancellation tokens. As we learned earlier, if we don’t manage the lifetime of async manually, we quickly start seeing unwanted exceptions in the log, and unexpected stuff starts happening. In general, every async function should take a cancellation token. In the current code base I work with, we don’t have a single async function that doesn’t take it, except for one async void Start in the root of the logic, where it all starts. It’s our way of staying on top of the game. You want to have control over async, and cancellation tokens are a must for that! They are the spine of your async solution! So let’s add them, and it’s not that bad. Now, we still missed one aspect of manual lifetime management We don’t want the tasks that didn’t yet finish remain running in the background with all their references to buttons and what not. We want to cancel them. WhenAny doesn’t do that for us. We need to do that manually too.
- We can do this using a linked cancellation token. We link the original cancellation token with a new one And now after the first task has finished we are able to cancel the remaining ones That makes sense, right? Now we’re almost done, but we just introduced a surprising memory leak.
- We need to dispose the linked cancellation token source. Normally cancellation token sources don’t need disposal. They implement IDisposable, but it’s not needed. But when creating a linked one, they need disposal, or they will never be collected by the GC. No way around it. So we put it inside a using block. Finally! Code is done and you try it out. And immediately notice we forgot something. We never implemented closing the popup visually! The logic exits, but nothing unloads the scene. And we want to play a closing animation before we unload the scene. So you need a piece of logic that plays a close animation and then unloads the popup. Sounds like an asynchronous routine, right? Doing things over time. But this time it’s purely a visual thing. The input logic doesn’t need to wait for the animation. We don’t care when the animation and unloading finishes, as long as it does. It’s a fire-and-forget routine. And actually with Coroutines doing this is extremely simple
- We convert our using block into a try-finally block, it was just syntactic sugar for this anyways. Now, what ever happens, who ever cancels what, despite any exception, we don’t care. When the logic of the popup exits, we just fire and forget a routine that animates and unloads the popup. And that’s it. That’s the end result.
- It took quite a few steps to get here. So was it worth it? Well, this is actually a very powerful pattern. The thing we did here isn’t exactly trivial. We avoided many common popup bugs without even noticing. For example, how many of you have had to fix bugs related to double tapping a button? You double tap quickly and now you have two popups open or something. Well, it isn’t a problem anymore. Only the first tap is registerd. The second one does nothing. How about tapping two buttons at once, that’s even worse! It will definitely take you to an undefined state. But again, here the problem just went away. Only the first one is registered.
- Or, how many of you had to fix bugs related to pressing buttons behind a popup? Like pressing that play or settings button there behind the popup? If you fail to block those inputs it will most likely put your app in some undefined broken state. But if what ever loaded this popup is built with the same pattern we just used, there should no-one awaiting those buttons to be pressed. There should only be a piece of logic awaiting for this popup to return. The benefits of this pattern are many and would be worth another talk so I’m going to leave this here. The point of this exercise was to show not only that async can be really useful, but also that it comes with much responsibility. Coroutines come with less responsibility. I would say async is much harder to use than coroutines. You don’t want to be using async for things that you CAN solve with easy coroutines.
- So in the end, how do we know when to use what? It’s time for our final slide.
- Here I called them rules of thumb, as in not strict rules. In my current project these are actually rules. Currently we never break them. And it’s not because we like rules, but because we don’t have any problems when we follow them. But I don’t know your projects. I don’t know your special needs. Maybe these rules don’t apply to you strictly. But they should still give some guidance. We didn’t have this list when we started the project, but through trial and error we developed an intuition for picking the right one. And slowly we were able to formalise it. So this list came from a practical approach. But it ended up matching what documentation states. Should have started with the documentation! As stated earlier, according to Microsoft’s documentation, besides threading, async is about handling user input and network calls. And that’s what we’ve mostly done today. We’ve used async for handling input. What about Coroutines. According to Unity documentation they are for good spanning logic across multiple frames. But async can do that too, so that’s not enough. We need to specify the use case a bit better. In our project we ended up with this: We use Coroutines for all fire-and-forget routines. You could use async for them too, but there is so much responsibility that come with it. And because fire-and-forget routines don’t return anything you don’t NEED async. So when we don’t need async, we go with easy and familiar coroutines. Finally, you’ll end up with stuff like Tweens in-between inputs, and fire-and-forget tweens. So should a, say, position tween be async or a coroutine? In my current project it can be either. We have duplicated functions TweenPosition to work with coroutines and async. The point of this is to avoid intertwining the two. Duplicating implementations isn’t optimal of course, but it hasn’t really been a problem for us. Notice that it is still OK to fire a fire-and-forget coroutine from async, as long as it doesn’t later return to the async flow, intertwining the two. Branching is good, but don’t intertwine them. - And that’s it! It’s this simple. And here ends my talk.
- his was my talk about async vs coroutines. Thank you for listening. I hope you learned something
- And of course: And we are hiring! Any questions?