text: The State Of Performance Reporting II
  Performance Reporting aims to be a suite of tools. At the moment, only exception reporting is available as a feature of our Performance Reporting service. This has lead to some confusion as developers often are looking for profiling data. In the future, we see Performance Reporting becoming a suite of tools for things like benchmarking and getting some lightweight profiling data.
  How Performance Reporting fits in with Analytics, Cloud Build, and Collaborate
  We often get questions about how Performance Reporting works with our other Unity Services. Our vision is clear, and we would like to share it with you now.
  Analytics
  Analytics is about helping developers understand their players. Performance Reporting is about improving the health of your game. By bringing these two together, we can see how bugs impact your players.
  In the future, you’ll be able to cross reference game session data with exceptions. With this, we can correlate an increase in exceptions with the end of a session.
  Cloud Build
  Cloud Build is all about automating your build process so you can focus on your game. Performance Reporting’s most requested feature is Native crashes. One struggle for native crash support is getting the build symbols, so that the native crash reports are readable by humans.
  Again, by bringing these two together, we can give you native crashes just by turning both the services on. The future we see here is native crashes with two clicks. Just enable Cloud Build and Performance Reporting.
  Collaborate
  Collaborate is all about seamlessly working on your project with a team. Part of good collaboration is having a clear overview of bugs that currently exist in your project. Performance Reporting will be able to use Collaborate’s project history to help narrow down where and when a bug was introduced.
  Performance Reporting is now integrated into the editor
  Previously, it took some effort to get started with Performance Reporting. These were the steps our beta users went through:
  - Learn the feature existed
  - Go to the website
  - Download the package
  - Install the package
  - Get your project ID
  - Add a few lines of code to your project
  While we did our best to simplify this, it was still too hard.
  We’re pleased to announce that in Unity Pro 5.4, new projects can enable Performance Reporting with one click.
  The work here mostly involved translating C# into C++ , refining our algorithm for sending data and moving from the Unity WWW class to the UnityWebRequest class.
  How the Performance Reporting client works
  Performance Reporting sends reports with a behavior that works like this:
  - A map between fingerprint and exception is stored.
  - An exception comes in and gets fingerprinted.
  - If the fingerprint isn’t in the map, it is added, then an asynchronous HTTPS request is scheduled for that report ensuring PerfRep gets at least one report.
  - If the fingerprint already exists in the map, a counter is incremented.
  - If too many of the same exception have been observed (10,000), the data is flushed asynchronously via HTTPS, and the feature breaker trips for the session.
  - If too many different exceptions have been observed (100), the data is flushed asynchronously via HTTPS, and the feature breaker trips for the session.
  - When the client exits the game, the data is flushed asynchronously via HTTPS to the server.
  When the feature breaker trips, we unregister the log callback so we don’t get any more reports this play through. Relaunching the game will start sending new reports. Usually when you reach one of these limits, you hit one of these cases:
  - There is an exception in the update loop.
  - A message that is variable with something like a time stamp, url with a query string, or temporary file name.
  One challenge was the exit hook. Some platforms don’t give you any time; others do. The Desktop platforms will successfully send their final counts, but that might not always be the case with iOS.
  Upgrading from the Performance Reporting Plugin
  If you’re using Performance Reporting for a 5.3 or earlier project, upgrading from the plugin to native editor is pretty straight forward. Just remove the package and any code you have referencing it, such as the initializing code. Then go to the Unity Services window shown above and click enable.
  If you don’t remove the plugin, the new method will still work. However, both the plugin and editor integration will send a report, causing double counting and extra network traffic.
  Performance Reporting Roadmap
  The feedback we’ve gotten has been remarkably consistent. Developers want native crashes, and some more filtering and tagging options for the dashboard.
  The good news is that we should have some better filtering options for the dashboard SoonTM. The also good, but never soon enough news, is that native crashes will probably be in 5.5 for iOS with other platforms to follow. Native crashes are a platform by platform battle, and we will do our best to get the ones we can into 5.5.
  Another shift for Performance Reporting will be the what we’re calling the “Common Data Pipeline”. This is a platform that the editor will use to minimize network connections and link information between services.
  Related posts
  16 CommentsSubscribe to comments
  ShawnJuly 18, 2016 at 7:42 pm
  Currently this is a bit useless to me, as you can’t filter by version number. So, although I patched most of the bugs in v1.8, there are many 1.7 versions in the wild, spamming thousands of errors, and filling up my log with reports that I have already fixed.
  The “filter” field seems like it could do the trick, but it only seems to filter on the error message itself, typing in a version number does nothing.
  ArmanJune 25, 2016 at 2:57 pm
  Three questions:
  1. Does performance reporting work in WebGL?
  2. What does “client exits the game” mean for WebGL apps?
  3. Is there a way to manually trigger data flush to the server?
  Thank you!
  thomasnervalJune 24, 2016 at 9:50 pm
  hola.sinfalta surespeto.nesecita……..ajuda por hecesprogramas.nesecitar para q activandos.hoye por favor
  Lior TalJune 24, 2016 at 7:33 am
  “Performance Reporting’s most requested feature is Native crashes. One struggle for native crash support is getting the build symbols, so that the native crash reports are readable by humans.”
  What exactly are you referring to as “native crashes” ?
  Our game uses a mix of both C# code and native plugins (implemented in objective-c for iOS, Java for Android).
  When i think of native crashes, i mean crashes that occur in those plugins. I still want those to be reported so we know our game client crashed.
  A crash can also occur in other non-plugin code (e.g: OS code). We would still like to have that reported.
  Is this scenario currently covered? just making sure we’re referring to the same thing…
  Chris LundquistJune 24, 2016 at 4:17 pm
  For native crashes we mean crashes that happen in Objective C or C++ where the app is terminated.
  Both managed and native exceptions would be reported, they would just be handled a little differently code wise.
  VictorJune 23, 2016 at 11:16 pm
  Please guys, make this also accessible by code, either in the editor or at the beginning of the run-time, because we want the ability to make debug builds fast, without having to change settings manually. I guess this is great news for the newbies who still use visual scripting, but granting access to this functions is never a bad thing. Please reply
  Chris LundquistJune 24, 2016 at 4:33 pm
  You should be able to enable it / disable it via
  using UnityEditor.Connect;
  // ...
  CrashReportingSettings.enabled = false;
  The above modifies the UnityConnect.settings which gets baked into the runtime during the build process.
  VictorJune 24, 2016 at 7:14 pm
  Can I also change the id of the project dynamically? Say I have different branches of the same project, but i do not want their metrics to mix. One for development, one for testing, and one for production, you get the idea. How can I set the id’s dynamically? Including the id’s for Analytics, Ads, and so on.
  Chris LundquistJune 25, 2016 at 2:38 am
  I believe cloudProjectId is a read only attribute.
  For the crash reporting feature in particular, it uses
  PlayerSettings.bundleVersionto tag reports.
  Having a project per branch or environment isn’t the work flow we’re hoping for.
  That seems like making a Git repo per branch / env.
  I can see how it might be the only way at the moment to distinguish things across all our services though.
  VictorJune 25, 2016 at 1:18 pm
  Thanks, I found that other people have complained about this before:
  MattJune 23, 2016 at 8:15 pm
  Hmm. Sounds like it’s still going to be a useless feature for quite a while. Can I get a partial refund for the Pro license I bought over a year ago? March 2017 will come before this feature is implemented. I was supposed to get a “Performance Reporting” service for 2 years.
  laurentJune 23, 2016 at 8:41 pm
  They are working with other pro license owners on extending cloud services.
  If they have not contacted you yet, you should get in touch with your local sales rep.
  Ben HymersJune 23, 2016 at 7:02 pm
  Will this new native performance support allow us to enable reporting only for certain builds? We currently conditionally compile out reporting for editor and development builds as we expect them to be quite spammy! If there’s no code required to initialise the system, how would we accomplish this?
  Chris LundquistJune 24, 2016 at 4:36 pm
  The code in the response to Victor should help.
  The gist being:
  CrashReportingSettings.enabled = false;
  AlexandreBJune 23, 2016 at 6:51 pm
  Why is it called Performance reporter while it is only an exception log ? It is more a Crash reporter.
  Chris LundquistJune 24, 2016 at 4:37 pm
  Because more features are in the works!