Battery Optimization in Watch Faces

Watch Face Studio
1

Hi, do you have any tips for making watch faces that consume less battery?

Some specific questions:

  1. I guess that using less and dimmer pixels is an obvious guideline, but how much of a difference does it make?
  2. Do complex animations, progress bars, etc. drain the battery significantly faster than a more static watch face? Specifically, does a watch hand/progress bar that represent the seconds+milliseconds (“higher” refresh rate) drain faster than a face that only changes when a minute passes? (Is the watch optimized for less usage when the face is mostly static, or does it still refresh at the same interval to the same image?)
  3. Do the gyro features affect battery life? Is the accelerometer activated anyway when the face doesn’t use it?
  4. Does the size of the source media matter? Should I use smaller, compressed images, or do they compress anyway when the face is built?
  5. More complications = more battery usage?
  6. Does it matter whether I use the battery complication, or create it from scratch using tags?
  7. Do hidden components (that never appear) still load when the face runs, and therefore consume more battery?
  • And any other things that should be considered when designing the face using Watch Face Studio, not after that?

Thank you!

1 Like
2

Hello,
Thank you for the useful questions :slight_smile:

It is known that the more dark pixels there are, the lower the battery consumption depending on the characteristics of OLED displays generally equipped by the recent watch devices.

The results of the watchface app created by WFS are optimized so that the screen is not updated unnecessarily. Therefore, more static watch faces consume less battery than dynamic ones.

Since the accelerometer sensor is one of the most widely used sensors in watches, it cannot be considered to be turned on according to the use of the watch face and in itself does not seem to have a significant impact on battery use. However, using accelerometers such as gyro effects can lead to frequent screen updates and high battery consumption.

Of course, it is recommended to use media images of exactly the same size as those placed on the screen. For example, since the screen size of WFS is 450x450, it is best to use an image of 450x450 size for a background image that fills the screen.

In WearOS, complication is data provided by another application to the watch face, so using a lot of complication slots means that other application services operate more in the background, so it can be seen that the battery is used more. However, this is not always right because the update cycle or operating environment varies depending on the type of application, and complication system is optimized at the platform level.

In this case, it is difficult to predict any difference.

It is recommended to remove them before build your app.

Here is the information you can refer to when making watchface.

Looking forward to your wonderful watchface! :+1:

3 Likes
3

Hi, @sinjae: let me add an extra question here:

When designing a watch hand, I have a 450*450 px image with the hand itself.

It works perfectly (WF is done in WFS).

Is it more advised to trim the image? I.e. to make it 10*450px? Does it increase performance / consume less battery to rotate smaller images?

Thank you

4

Hello,
Correct, the trimmed smaller images optimize the performance and power consumption.
We have prepared a document on how creators using Watch Face Studio can optimize the watch face : Performance tips  |  Android Developers

Thanks.

2 Likes
5

Hello, thank you.

While this is quite straightforward, please correct me if I’m wrong:

In the performance tips there is one: “Combine bitmap assets”: in case I wish to add shadow to a watch hand, shall I combine the hand + shadow into one picture?

6

hi,
it’s up to your design.
If it is okay that the shadow is rotating as a clock hands, it’d be better to be combined. If the shadow should be rotated in different position, for example, shifted to downside (opposite direction from the virtual light origin), it should not be combined.

1 Like
7

Thank you very much! I planned to move just a little bit downwards, yes.

8

One more question came into my attention:

From the the linked site:

Combine bitmap assets

If you have bitmaps that are often drawn together, consider combining them into the same graphic asset. You can often combine the background image in interactive mode with the tick marks to avoid drawing two full-screen bitmaps every time the system redraws the watch face.

This is great idea, I have 2 combinable assets: ticks, and numbers, both are PNG with 450*450px with white shapes (I’ve done the coloring in WFS):

  • ticks.png: 7229 bytes
  • numbers.png: 5739 bytes

I decided to try the idea above, and merged them together with a photo editor. However, I had to apply the coloring before the merge, as ticks and numbers had different colors (which were set earlier in WFS - static color, user can’t change it).

Result image: 15411 bytes.

So, which is more battery efficient? Having 2 white fullsized PNG which gets color info from WFS, or having only one precolored image, although it’s size is almost 20% larger then those 2 earlier.

9

Having only one precolored image is much better for battery efficiency :slight_smile:

In a nutshell,
In order to draw an image on the screen, a raw buffer decoded by the required resolution size is required, not the compressed png file size. The 450x450px png accounts for 791Kbytes. Therefore, in your example, in terms of file size, it increased by 2443 bytes when made into 1 file, but the actual memory used decreased by 791 Kbytes.

2 Likes
10

Great info. Thanks for sharing this