Something drains battery... ListView is a suspect.

Gourmet

I often see message about my currently developed app drains battery on smartphone. My code does nothing when app is idle. It just waits in the Qt message loop as obvious. On the screen app shows complex ListView with 18 different size Texts in each Rectangle. There is MouseArea on each Rectangle too. List is large, scrollable and has scrollbar. And background colors in Rectangles are different depending from some date-time conditions. And there are several other windows on top of it but most time they are hidden (by hide() method exactly). I did not yet profiling but may be anybody here did. What is known about processor consuming by QML interface elements and it's optimization? I am seriously worry about this. If my application will drain user's batteries while being idle - the Google will remove my app from GP.

J.Hilk

hi @Gourmet

I have an app in the store, that has a multitude of ListViews in them one is almost always on display + continues data exchange via Bluetooth. Each time a package is received a new one is requested.

I have no problem at all with battery draining warnings. In fact this app is a recreation of one of our old apps (made in pure JS of all things) and that one got the warning. The one made in Qt does not.

So ListView is 99% not the issue here. You should investigate your code you're most likely doing processor heavy tasks somewhere.

Gourmet

I do not know how exactly QML engine works. But I have noticed some interesting thing. In my QML file for this ListView I added following option - if current system time is greater or lower than time value Moment in item, then item's rectangle has different background color. It's just like:

    ListView {
        id: lView
        property date today: new Date()

        delegate: Rectangle {
            color: modelData.Moment < lView.today ? "gold" : "yellow"

In my code I do not refresh view. Moment is some time changed only by user and nothing else. But I was surprised - right now after system time comes over Moment - then Rectangle changes it's color. That means - ListView or QML engine or QQuickWidget - somebody of them permanently refreshes it's view. This is definitely processor consuming action.

JonB

@Gourmet said in Something drains battery... ListView is a suspect.:

Moment is some time changed only by user and nothing else.
But I was surprised - right now after system time comes over Moment

What does this mean? Are you saying modelData.Moment changes, or new Date() changes or what?

Gourmet

@JonB nope... After written above I've made some tests - it works different. I must make more experiments... Right now it's not clearly visible how it works.

JKSH

@Gourmet said in Something drains battery... ListView is a suspect.:

I did not yet profiling but may be anybody here did. What is known about processor consuming by QML interface elements and it's optimization?

I haven't encountered anything like this myself, but I highly recommend profiling.

Here are some other tips that might help: https://doc.qt.io/qt-5/qtquick-performance.html

fcarney

@Gourmet said in Something drains battery... ListView is a suspect.:

That means - ListView or QML engine or QQuickWidget - somebody of them permanently refreshes it's view. This is definitely processor consuming action.

This changes because you modified the value of a property. Of course it will change. That is how it is designed. It doesn't mean that QML is sitting there checking for changes constantly.

Now, is modelData or any other exposed C++ objects constantly changing values that are assigned to properties in QML? If so then it will drain battery.

Gourmet

@fcarney said in Something drains battery... ListView is a suspect.:

is modelData or any other exposed C++ objects constantly changing values that are assigned to properties in QML?

Constantlty - no. In background - no. My application does nothing in background. What is most interesting - I have many other apps made on the almost same internal design like this one. About difference I'll tell little later. Those apps DO constantly work - they show music visualizations with frame rate 15 FPS. Of course they do calculations in background and they refresh screen part. But Android NEVER told they drain battery. The only one important difference of those apps from this one is - they DON'T use QML. They are completely QWidget-s based.

fcarney

@Gourmet said in Something drains battery... ListView is a suspect.:

If my application will drain user's batteries while being idle - the Google will remove my app from GP.

Could it be a false positive? Could Google be not liking the content of the app and are using this as an excuse to target the app (Google, despite claims, is not impartial.)? Are users of competing products attacking your app by saying it causes a problem that it does not?

Gourmet

@fcarney No. No. No. Google has rule about battery consuming applications. App must not actively drain battery being idle. Otherwise Google can remove it on this reason.

But it is possible to particularly solve this problem with AndroidManifest.xml setting

<meta-data android:name="android.app.background_running" android:value="false" />

Unfortunately in this case application won't be able check for it's location on GPS and send notification when it reaches targeted point. But my apps must do this. It is one of their important function.

JKSH

@Gourmet Profile it.

JonB

@Gourmet
As everybody else says here, QML does not sit there updating/refreshing because it has nothing else to do. If you truly suspect ListView, I suggest you create a tiny, standalone QML containing just that and see how it behaves battery-wise.

fcarney

Just for an example of what can cause CPU load in QML. I created some Text in a delegate. When I have a winning condition in my game I rotate some of the text back and forth. If I do this alone the CPU usage will go from 0% to 2% while the Text is rotating. If I give it a drop shadow and/or a gradient and rotate the CPU jumps to eat a whole core. So 15% CPU on my laptop. As soon as I stop the animation it goes back to the 0% or nearly 0. This has made me rethink using certain animations in QML except for maybe transitions. I tested some of the line drawing with opengl and the shape based drawing in QML and those consume magnitudes less of cycles. So I learned this weekend you have to be really careful what parts of QML you use and how you use it. Trial and error I guess.

@Gourmet maybe not useful for your current problem. I hope you can track it down.