Simulator vs. Real device

Of course you don't have to draw everything every onUpdate (and I don't draw entire screen too in one WF)  but you have to remember:

1. which device clears screen and in jungle point them to draw like amoled

2. Bigger problem is with system messages (goals, low battery etc.). But I noticed that this message is in 1/3 upper part of screen so draw only 1/3 every time :)

And of course from time you have to expect bad drawing (e.g. when user choose WF). Everything depends on situation if you have fast drawing you can draw everything but is complicated (drawing and calculation) you can looking for optimization.

Do you have an estimation how much battery this saves?

Did you ever have problems (complaints from users) when you had to change things to fix how it works (or how big the upper third is)?

it's difficult to say haw much because I don't how to calculate from profilers's us to % battery

But in my example

- one onUpdate costs about 10000us

- one onPartialUpdate (without drawing anything only one IF) costs 24us

- every wrist move - about 10 onUpdate let's say you move wrist every 30 minutes

so, in 4 days you have (about, you have every minutes update else)

So you can save "days" but everything depends on watch settings (sensors, brightness etc.)  app and what you do in onUpdate e.g. one:

- Storage.setValue - 12000u

- Storage.getValue - 6000u

- Property.getValue - 100u

- loading string using loadresource - 3000u

I don't like charge my watch often so my WF have to save battery. In my case is 4 days (all day Spo2, HR a lot app updating, 3 hours with gps etc). One user has informed me about near 8 days without charging. Of course it's nothing to saving mode but in this mode watch switch off sensors, steps and I don't know what else.

And of course drawing entire screen has advantage, you don't have to:

- clear every control (drawing background or dc.clear() costs too - unfortunately screen  is always black when system clears it so even for amoled you have to clear it if user choose not black background)

- use clips to separate regions

- know which control should be updated

-etc.

The biggest problem was to discover clearing screen - users simple says "everything flushing". I simple fixed it and no complaints . And I'm ready to quick change way of drawing changing from CLEARSCREEN_N to CLEARSCREEN_Y in jungle to prepare new version.

One other, general thing to keep in mind is that the Connect IQ simulator is not an emulator. We do try to make the simulated devices behave as closely to the real thing as we can, but there will sometimes be hardware differences or even configuration changes on a device that we're not immediately aware of that can cause disparity between the simulator and real products.

It's always best to test on hardware if possible, but it's clear why that's not an option for most people, particularly if you're a hobbyist building something like a watch face for fun. jim_m_58's recommendation to use some base assumptions for all devices is wise, and beyond that, we can check specific cases if they're reported as bugs in our Bug Reporting Tool. I can't guarantee that we can address every discrepancy, but there are many we can.

For example, there are some cases where a device will exhibit a particular behavior when recording an activity with a particular sport type or sub-sport type. This is something we wouldn't likely address in the simulator because it's outside the scope of Connect IQ (CIQ just records the data provided by the system - it doesn't manipulate it in any way unless he CIQ app is implemented to do so). However, if a physical device is using a different font from what's displayed in the simulator or something similar, we can address that.

Everything I have written was "about".

Everybody choose his way of developing. For me it's important to write app as good as possible at all and because I'm using my apps. So if I can save battery I do it.

It simple to write app but if you hit the wall with memory/battery you have to choose to resign or to find a solution to correct it. Let's see, layout.xml - it exist somewhere in memory and consumes kilobytes (if you have a few layouts it can by 20% of memory). Using layout.xml just for drawable that do nothing besides load height/width/etc is simple wasting of valuable resources.

The same profiler, maybe it doesn't reflect good device but shows  bottlenecks. When I see that saving to storage cost comparable with onUpdate I limits every save.