Add jank events for slow app rendering #2157
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,22 @@ | ||
| # Use this changelog template to create an entry for release notes. | ||
| # | ||
| # If your change doesn't affect end users you should instead start | ||
| # your pull request title with [chore] or use the "Skip Changelog" label. | ||
|
|
||
| # One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
| change_type: enhancement | ||
|
|
||
| # The name of the area of concern in the attributes-registry, (e.g. http, cloud, db) | ||
| component: app | ||
|
|
||
| # A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
| note: Defines a new jank event in the app domain | ||
|
|
||
| # Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists. | ||
| # The values here must be integers. | ||
| issues: [2157] | ||
|
|
||
| # (Optional) One or more lines of additional information to render under the primary note. | ||
| # These lines will be padded with 2 spaces and then inserted directly into the document. | ||
| # Use pipe (|) for multiline entries. | ||
| subtext: |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -62,3 +62,43 @@ groups: | |
| A widget is an application component, typically an on-screen visual | ||
| GUI element. | ||
| examples: [ "submit", "attack", "Clear Cart" ] | ||
| - id: app.jank.count | ||
|
Contributor
There was a problem hiding this comment. Not needed if moved to body attribute or metric
Contributor
Author
There was a problem hiding this comment. True, but metrics aren't on the table right now for mobile...and using flat/basic attributes is currently much simpler than defining structured event bodies. There is prior art for defining attributes for events, and these events are pretty simple (eg. not a lot of deep structure or complicated types involved).
Contributor
There was a problem hiding this comment. I like the overall idea, @breedx-splk. What's very confusing to me is that it looks like a metric, swims like a metric, and quacks like a metric... And yet it's defined as a log event? I noticed that you recently mentioned that you've added a period attribute to keep the count somewhere in memory and only sending the event after that period of time, and that's something that already happens with metrics too! 😅 - I just don't understand the idea of having to reinvent metrics as log events, it makes me wonder why do we have different signals then? In theory, I guess we can also replace spans by logs, but it doesn't seem like that's the way to go. I was thinking what would make sense to me for this to be a log event, and as such, I think it would be simpler, like "There was a UI jank at this point in time" with maybe an attribute that shows for how long the UI was stuck and where in the app that happened. It would be helpful for me as an app developer to know that there are UI janks and where, and with the time attr I would be able to correlate that data with the host device info so that I can check how much priority I should give this issue since it's not uncommon to have UI jank in older devices. The problem with that approach is that we could potentially send hundreds of events in a very short period of time (unless we limit the amount of events per second or something like that, where we would only capture the first jank within a second and then ignore the rest during that time, for example), which is why I guess we came up with the "count" attribute. But by introducing a count value and a period of time, we essentially turn this into a metric (unless I missed something important), so it seems like it's just the nature of this event. We've recently added metrics support in OTel Android, so I'm not sure why it would be a problem to go with it as a metric. It's a tricky event to define for sure, it's probably a good topic for the SIG meeting.
Contributor
There was a problem hiding this comment. Agree it certainly appears to me to be a metric to me so I would rather see it expressed in that manner. The event should be recorded as soon as it happens to provide an indication that something happened.
Contributor
There was a problem hiding this comment. I mentioned this in @breedx-splk's PR over in the Android repo, but I don't think making this a metric, thereby erasing the "when did it happen?" dimension from the signal is a good idea. That is the most important thing when this data is being used, and no amount of aggregation will give you more information than knowing when it happened within a session and what preceded and followed it. Count in this case is metadata for the jank event and gives some qualification as to the magnitude of the jank event being seen by the user. Totalling up all the dropped frames but not stating when they were dropped renders this data pretty useless. We are not trying to count all the dropped frames in the entire fleet (or even on a single device) - we are trying to model the fact that users are seeing janky scrolling or unresponsive UI.
Contributor
There was a problem hiding this comment. Actually metrics support exemplars which preserve that link hence not rendering them useless in fact for me make them more useful then events as you can see how widespread it is and then drill down. |
||
| type: int | ||
| stability: development | ||
| brief: A count of the number of frame renders that experienced jank. | ||
| note: > | ||
| Depending on platform limitations, the value provided | ||
| MAY be approximation. | ||
| examples: [ 9, 42 ] | ||
| - id: app.jank.type | ||
|
Contributor
There was a problem hiding this comment. Could this be app.rendering.state so that it is generic?
Contributor
Author
There was a problem hiding this comment. Not my preference, because this is attempting to specifically define a type of jank (slow screen rendering performance). It's not really a "rendering state", so I don't think
Contributor
There was a problem hiding this comment. I wouldn't add this attribute, I think it might be more confusing than helpful as its items don't depend on constants but instead users can choose what values to set as thresholds, so if they decide to change them at some point (or just switch from an instrumentation impl to another with different defaults), then they would get misleading values across time. Plus, I think this categorization makes more sense to do on the query side, where I can define my threshold at query time, without having to rely on how it was categorized in the past. On top of that, it adds more size to the event itself, making it not too disk space friendly. If someone needs it in the future, and they explain their use case in a way that we can get a better idea of how to make this attribute useful for them, I think we should add it then. But right now, since we don't know exactly what's needed for this event, I wouldn't add it because I think it's better to add stuff as the need arises, rather than having to make breaking changes and/or removing stuff later.
Contributor
There was a problem hiding this comment. If we were to add it then the naming should be generic rather than jank so that it can be used on other os.
Contributor
There was a problem hiding this comment. Jank is a specific type of UI artifact whereby some amount of frames were not rendered, leading to choppy or frozen UI. It's not state, per se, but more like the occurrence of something bad that is perceivable to users. I can see the desire to classify this into different types, but in a way that is what the period and count attributes do. Having a high-level box to put it into would require defining the parameters of said box, and I don't think we know enough how the usage to clearly say what they would be. I think we should probably skip this for now. And if we want to go ahead and do it, I wouldn't make it more generic, as the whole idea of semantic conventions is to make them specific and meaningful. If there are other UI screen events we want to track, we can define a new event, as the underlying attributes would likely not be the same as what we have for jank. |
||
| stability: development | ||
| brief: A categorization of the type of jank. | ||
| type: | ||
| members: | ||
| - id: slow | ||
| value: 'slow' | ||
| brief: 'Jank is classified as observably slow.' | ||
| note: 'Recommended threshold for slow is 16ms.' | ||
| stability: development | ||
| - id: frozen | ||
| value: 'frozen' | ||
| brief: 'Jank that causes the user to suspect that the application is frozen.' | ||
| note: 'Recommended threshold for frozen is 700ms.' | ||
| stability: development | ||
| examples: [slow, frozen] | ||
| - id: app.jank.threshold_ms | ||
|
breedx-splk marked this conversation as resolved.
|
||
| stability: development | ||
| type: int | ||
| brief: The minimum rendering threshold for this type of jank, in milliseconds. | ||
| examples: [16, 700, 1024] | ||
| - id: app.jank.period | ||
| stability: development | ||
| type: double | ||
| brief: The time period, in seconds, for which this jank is being reported. | ||
| examples: [ 0.5, 1.0, 10.0 ] | ||
| - id: app.activity.name | ||
| stability: development | ||
| type: string | ||
| brief: The name of the Activity at the time of the event or span start. | ||
| note: This is an Android specific attribute. | ||
| examples: ['myActivity', 'checkout'] | ||
Uh oh!
There was an error while loading. Please reload this page.