Toybox.Timer works on Simulator , but freezes a real device.

 I'm still trying to understand how data is managed. I see that a lot of people have a separate drawables.xml for each watchsize and employ a lot of tricks. I plan to see the efficiency gains by doing as you suggested (by lazy loading resources in the Onshow, instead of doing everything in onUpdate).

0n Fitbit, I have a watch called Virtual Star with 100 png characters (each 10-20kb) and expressions, costumes, 7 backgrounds for every month that are probably 30kb each. Somehow that huge 50mb javascript program compresses down to a 1.4mb package on Fitbit (but for only 2 devices).  On Garmin, you the programmer have to be more smart.

I have a Garmin watch that is 3mb with no bitmaps, but it just has hundreds of settings and enums - the uncompressed program folder is very small  (50-100kb) , but as a "compressed" IQ package it becomes 3MB and 34kb memory usage.  Then I have a published watch with no settings or enums, and it has 50ish backgrounds at 20kb each and sprites and it goes from 18mb raw folder to a compressed IQ package of 2MB and only 14kb memory usage.

Ngl, adding adittional calls to bitmap draw(dc) in onUpdate only increases the memory usage by 0.3 kb for each draw (in simulation).

Overall , the freeze effect  for this specific issue was  removed by fixing the timer- but I admit battery and IQ package size are bigger issues in a lot of my programs that I need to later address. 

What's displayed for a watchface when the AMOLED display is in low power mode, is really up to how a specific watch face was written.  With mine, I just display the time, but do have an option to either move the time around, or overlay it with a checkerboard to turn off different pixels every minute. (the result is it's dimmer)

I think your brightness settings, notifications, and Always On Dispay can have way more battery drain than anything coming from a 30kb vs 14kb vs 5kb memory usage.

I have a watch with a white background and just having a white background (on fullest brightness) does miles more to battery drain than calling bitmaos in onUpdate.

The same exact program has 4 days battery with solid white background and 14 days on a solid black background. If I have a dark jpeg background it's about 8 days.

(((But of course , we should always aim for best practices as programmers.)))

Using Monkey Motion or animation layer seems to cause the most battery drain- making my device have only 2 days battery.

VirtualStar said:

I have a watch with a white background and just having a white background (on fullest brightness) does miles more to battery drain than calling bitmaos in onUpdate.

Yeah but the main problem with loading bitmaps in onUpdate is the *freezing*, not necessarily battery drain, bc accessing the file system is very slow.

Like I said, just connect your watch to your PC or Mac and see how slow it is to copy files to and from the device. Or notice how slow it is to save an activity, or how the map tiles take a while to render when you pan the map (if you have a device that supports maps.)

Garmins don't have fast flash.

Like jim_m_58 said, a white background is not recommended on AMOLED devices. AMOLED devices won't even let you select a white background for data pages or for native watchfaces.