This article is more than 1 year old
Apps made with Google's Flutter may fritter away CPU cycles. Here's what the web giant intends to do about it
Chocolate Factory's cross-platform framework seems to struggle to craft efficient desktop software
Google's Flutter cross-platform app framework appears to have a thinking problem: in certain situations, Flutter desktop apps consume too much processing power.
How much is too much? Try an extra six to ten per cent CPU usage just to recreate the blink of a cursor in the style of a native macOS app. That's an improvement over the 100 per cent CPU usage reported in 2019, though that was when Flutter desktop app support was in alpha stage.
This would be a showstopper on mobile devices, where users won't tolerate apps that make their phones go dark from battery exhaustion. But energy inefficiency hasn't proven to be a common problem in Flutter Android and iOS builds recently, though it was something of a concern as Flutter has matured. The more pressing issue on mobile devices for Flutter devs is still trying to reduce "jank" – lag created by shader compilation.
For desktop apps, particularly on plugged-in devices, excessive resource consumption is often tolerated as a trade-off for developer/user convenience, as can be inferred from the ongoing lavish lifestyle of many Electron-based apps, which use memory and CPU rather liberally.
But one of Flutter's selling points is the possibility that it can provide smaller, more performant apps than the Electron framework or similar cross-platform technologies.
An easier way to Flutter? Custom functions improve visual code builder but devs may still be frustratedREAD MORE
Flutter offers developers a set of tools for creating builds of apps that can run on Android, iOS, Windows, macOS, or Linux, the web, and embedded devices from a single code base. It does so by relying heavily on Skia, a graphics-rendering engine written in C/C++ that uses a device's CPU or GPU to draw app interfaces on its own, without relying on native platform interface libraries.
But by handling compositing independently, Flutter has magnified the challenge of writing resource optimized code. Flutter's avoidance of native libraries deprives it of some of the efficiencies available to native platform code.
For Flutter, the blinking cursor CPU tax has been an open GitHub Issue for more than a year.
As of August 2020, Kaushik Iska, senior software engineer at Google, said Flutter was working as expected and that the Flutter team might consider improvements at a later date:
If you were to create an application with a simple text box on macOS, the native application can essentially sleep as most of the heavy lifting is done by the system compositor. In Flutter the cursor is a timer and for each frame we need to composite and paint the layer tree to the surface. I’ve confirmed that we aren’t doing any additional work than expected.
Flutter also has the dart VM running to run the framework code to produce each frame and we expect that this will incur additional overhead as compared to native applications. Given this I think this is working as intended. If we at a later stage determine that we need to hit specific CPU and GPU utilization goals we can revisit this issue and try to find some improvements.
That later date hasn't yet arrived but there are signs it might soon. A spokesperson for Google told The Register, "Flutter desktop support is still in progress, and it's a bit early to judge performance."
Canonical: Flutter now 'the default choice for future desktop and mobile apps'READ MORE
We were also told that the cursor issue doesn't reflect resource usage in other scenarios, and that the Flutter team intends to fix or mitigate this at some point.
The reengineering will need to extend beyond Flutter's cursor tax, however. There are reports of excessive memory usage on Linux builds, too, which will need to be fixed to make Flutter suitable for IoT scenarios. And there's Flutter's practice of redrawing every animated widget in full, as opposed to just portions of the screen that have changed – something that may soon be improved.
Creating one framework to rule them all isn't easy. Then again, neither is writing native operating system code. ®