As mobile developers we understand there are thousands of devices that reside on a spectrum of performance potential, with “low-end devices” at one end and “high-end devices” at the other
I’ve been wondering for some time what a general solution to putting a given device into a bucket might look like. For any given app we could use some benchmarking measurement at runtime, on the other hand we might be able to use some kind of database that contains a prefabricated map of device to performance bucket.
I’ve noticed the Clarity dashboard allows you to disable screen recordings for low end devices, and I wonder how it achieves this, or whether there are other leads on this problem
You could check cpu type, core count, ram size etc. and draw a line from where you think your app should run as a low end version. Get a few low end/old devices and monitor with adb for bottlenecks. If you see for example,the cpu is maxed, you should draw the line somewhere there. Yes you could run some tests too at first run to figure out if it’s a weaker device.
FWIW, I think this would make a fantastic plugin. Something that tries to guess the device’s performance level, however imprecisely, across devices.
I like both the hardware info and the runtime benchmark idea. Both have major problems, of course.
It would be easy to “miss a spot” with the hardware info approach (e.g. a variable that’s very important but not part of the heuristic). Plus, I’m not sure all devices give access to this info freely and without user approval.
On the other hand, the “benchmark” would take time (presumably on startup) and should probably run for a non-insignificant amount of time (several frames worth), otherwise it’s just noise.
And the developer would always use the outcome only as guidance, giving the user the ultimate choice.
Something I’m wary of with the runtime measure is that low performance isn’t necessarily a fixed characteristic of a device but can be more of a mode of operation caused by things like throttling of the device due to high temperature, battery saving modes, contention for resources with other applications / the operating system
Perhaps it’s worth enumerating the possible goals.
I think the runtime heuristic is something we might use to improve the overall user experience in a just-in-time manner - if we estimate we can automatically sync content offline seamlessly right now then perhaps we should. We might also record these results with an analytics service to later try and draw some insights, perhaps using these to shape product and/or engineering design decisions
The device bucket might be something we use to help set expectations with users, perhaps inside the app as well as outside the app in a support portal or product page if we were provide some estimate of the experience on a given device to customers present or future, in a similar manner to how games often provide a minimum or recommended spec.
Using contents of this forum for the purposes of training proprietary AI models is forbidden. Only if your AI model is free & open source, go ahead and scrape. Flutter and the related logo are trademarks of Google LLC. We are not endorsed by or affiliated with Google LLC.