Adding touch-screen functionality to a watchface increases power-draw?

Watch Faces can only use onPress and then, not on all devices.  What does your delegate for touch do?

If you are doing a background with makeWebRequet  calls, I'd suspect that and not touch.

Thank you for taking the time to reply! The functionality is working as expected - no complaints there. It is just that the feature seems to increase the power-draw significantly. Of approx. 20%/day on my Fenix7s the elephant in the room - makeWebRequest - is obviously the larges consumer with ~5-10%/day depending on how long these requests take to process as the device keeps awake longer.

But just commenting out the WatchfaceDelegate get the power-consumption down by at least 5%/day. Disabling the touch-screen on device does not make a difference so I'm wondering if I miss something as I don't expect the code should ever be executed but seems to make a significant difference over a day.

Can you do a stupid test: 

1. Enable the touch and the delegate but but the watch on a desk and don't touch it for an hour

2. The same but touch it as much as you can

I've done something like that. The plot is showing the difference between two succeeding System.getSystemStats().battery-calls. The first plot is with WatchfaceDelegate enabled and in the second WatchfaceDelegate is commented out in my WachfaceApp. Otherwise identical. Data is collected every 5min. It seems that the "baseload" is just higher as the first plot never reaches the low levels of the second.

I would love to understand how onComplicationChange is affected by touch as the code is the same for both versions! This might be the obvious thing I might have missed.

Getting rid of BLE and restarting the device is a good idea! There might be other stuff running...

So this difference shows the effect of the difference in the code, without any difference in actual touches?

Yes, it seems to be just the code. Unfortunately my test-device is also my only Garmin device, so there can be a lot of noise. Following jim_m_58s advice I've switched off BLE and let it rest for a while. Will post the findings!

bruderjakob said:

The profile in the simulator was not very helpful

You can profile the app on the device itself by adding "-k" to the compiler options.

https://developer.garmin.com/connect-iq/core-topics/profiling/

If you suspect that the WatchfaceDelegate is somehow being called when it shouldn't be, maybe this will confirm or deny your hypothesis. Then again, I'd think the profile in the simulator should be similar enough (maybe not tho).

Thank you, that is good to know! Following jim_m_58s advice, disabling BLE and just let the watch lay around for an hour, there does not seem to be any significant difference that can be credited to the WatchfaceDelegate (13.16%/day vs. 12.59%/day).

It seems that the power-drain is somewhere else and following the advice I've optimized my ridiculously inefficient onComplicationChange and will look into BufferedBitmap instead of drawing to the screen each time. Thank you all for the advice and support!

You may not want to use Complications.subscribeToUpdates that often and not use WatchUp.requestUpdate() when one does change,  Just use the normal onUpdate for display. Native ones can update pretty often, and if you are watching a few, you could be updating the  screen (expensive) much more than needed.  Using steps as an example, I don't subscribe, and in onUpdate, I just use the step count from ActivityMonitor. but a press on that value, launches the steps glance.

Remember, each time onUpdate is call, you need to update everything on the screen, and not just parts,