The startup moment is automatically created by the SDK. You can also define your own custom app moments. App moments allow you to wrap portions of code and hyperfocus on the performance behavior of your application in those areas. The following attributes are monitored and collected by the Android SDK within an app moment.
Battery Charging Intervals
High CPU Usage Intervals
Disk Storage (Application/Device)
Network Interface & Connectivity Switches
While app moments are very powerful tools and provide a great deal of contextual information, they are not designed as a global monitor for your app’s performance. Rather they provide the most value enclosing short sections that you think may have a bug, performing poorly or have critical business impact (e.g. purchase flows). In general, we recommend defining one or two moments in addition to the startup moment.
App moments are identified by name and can be started in the following manner:
Terminating app moments is just as simple.
Remember, it is important that all flows from the start of the moment be accounted for when stopping the moment. Failure to do so may lead to some moments stalling out. As with ending the app startup moment, terminating an already completed app moment has no effect.
Adding Moment Identifiers
Let’s say that you have an app that needs to display a handful of images to the user and you want to wrap each photo load in an app moment. You could define an app moment called photo_load and start it before fetching an image and end it when it is rendered. This could work if you’re serially loading images one after the other but if you’re loading images in parallel, this would likely lead to unexpected behavior since multiple contexts are operating on the same app moment. To get around this issue, you may instead consider defining a new app moment for each image being rendered (perhaps by adding a UUID suffix to the moment name). While this would solve the earlier issue, this does bring up a new problem. On the dashboard, moments are aggregated according to the app moment name. What this means is that instead of having a single photo_load moment that has the aggregated stats across all image loads, none of the image loads will be aggregated as their names will all be different.
The proper way to solve this issue is to use moment identifiers to differentiate between different instances of the same app moment. When you stop an app moment with a particular moment identifier, only the app moment with the identifier will be terminated. However for aggregation purposes, the moment identifier will be ignored and only the moment name will be considered.
The moment identifier can be specified by adding it as an additional parameter to the
endEvent method calls. If an app moment is terminated by only its name, all app moments regardless of identifier, will be terminated.
Embrace.getInstance().startEvent("<NAME>", "<IDENTIFIER>"); // Stops an app moment with the given name and identifier combination. Embrace.getInstance().endEvent("<NAME>", "<IDENTIFIER>"); // Stops all app moments with the given name, regardless of identifier. Embrace.getInstance().endEvent("<NAME>");