Building better, faster games with Embrace’s Unity toolset

Embrace’s ANR (App Not Responding) resolution feature gives engineers highly granular data and advanced analysis capabilities to solve even the most persistent ANRs. It’s used by Android engineers across many different app types, including mobile games.  

This feature works by sampling the main JVM thread of an Android app as soon as it’s blocked for 1 second, then continues to take samples of the stack frame every 100ms until the ANR resolves or causes an exit. We analyze all of these samples and group the ANR by the method that’s identified as being responsible for the blockage. 

Mobile engineers can then analyze any ANR grouping using our flame graph visualizations, which allow them to see all the methods captured across the many stack frame samples during the ANR duration, both in terms of how frequently they show up across samples, as well as how deep in the stack they appear when tracing the operations through each frame.  

While this feature is incredibly useful for Unity engineers building on top of Android, it has been missing the context into what’s going on within the actual Unity layer. 

If an app experienced a blockage in the Unity thread, for example, and the JVM main thread was waiting on the Unity thread to resume work, an engineer trying to resolve the issue wouldn’t have enough information. They need a stack trace of what’s going on in the Unity layer, not just in the JVM. 

With the introduction of Unity flame graphs (beta), we’re now giving engineers this essential context. Through this new feature, the Embrace SDK will take samples of the stack frame from the Unity main thread as soon as it starts to get blocked, and an ANR is imminent. We capture these samples once per second, and similarly group the Unity ANRs based on the problematic method identified from the group of samples. These Unity ANRs will then be displayed in their own version of a flame graph, giving engineers a highly-effective visualization tool to spot the problematic methods at the root of a Unity thread blockage. 

Through this new feature, we’re better enabling Unity devs to debug the ANRs plaguing their games, frustrating their players, and impacting their adoption rates and Play Store rankings.

Along this same line of providing added context for Unity, we’re excited to announce that Embrace now symbolicates native stack traces into C#.

As the language used to write Unity code, it’s essential for engineers to be able to see stack traces for each crash or exception in C# so they can properly troubleshoot. Until recently, however, stack traces captured by Embrace contained the file name and line number information for C++ code generated by IL2CPP, not the original C# source code written by the dev. 

All of that has changed with this new feature rollout. Now, Unity engineers can see stack traces in C# code, making it much easier and quicker to identify the root cause of an issue.  

For a more detailed look at this feature, including some background on Unity’s IL2CPP AOT compiler and the compiling process, check out this technical blog. 

While gaming solutions are a big part of what we build, Embrace has so much more to offer for engineers across the spectrum of industries and mobile app types. We support the Flutter and React Native frameworks, in addition to native iOS, Android, and — of course — Unity. 

Our data-rich, issue-detection and -resolution tool is specially designed for early discovery because we capture the full story for each individual session. That means that you’re able to catch early performance risks as soon as they start impacting even just a handful of people, rather than 5-10% of your entire user base. 

To learn more, check out the rest of our product suite, or request a demo to see how our solutions can help you maintain fast, stable, and all-around amazing mobile app experiences.