Measuring load/performance

There's not a good way to do this in general other than observation.  Run your app for x hours, and compare the drain to something else, say a native WF, and maybe a really simple CIQ WF.

One exception is use "view watch face diagnostics" for a WF that uses onPartialUpdate.  Those have a max avg of 30ms per call, and you can see where you are at on a second by second basis, where if you're close to that 30ms, you can try to get that lower.

Widgets, it's really not that important, as they only run occasionally, and then have a timeout of 2 minutes or less on watches.

Device apps, there are a bunch of variables, like what sensors are used, GPS, recording, every sec or smart, etc.  You can get a bit of a baseline with a native activity that does the same kind of things (with no CIQ DFs).

And then there's the impact of background services.  Your app may not be using one, but other apps running on the device could. And there's also if the device is connected to a phone or not.

Efficiency is really something you want to consider when writing the app or adding something.

Again, thank you.

I have added sunrise/sunset functionality and I am simply wondering if those calculations would end up consuming too much battery/cpu/load wise.

Depends on how they are used.  Do you calculate them on ever call to onUpdate, or do you just display the value if the day hasn't changed?

In theory you should be able to open a shell into a device via adb (android debug bridge).

You would then be able to inspect all running processes with "ps" and "top" - those two will give you CPU load, memory consumption, and tons of other cool metrics.

adb on its own doesn't see simulator or physical device. 

Simulator instructs to run command:

adb forward tcp:7381 tcp:7381

However it produces the following error:

adb: error: no devices/emulators found

I'll dig into it a little deeper and will update this post if I find a way in.

Watches don't run android, and there is no access to a shell.  There is no on device debugging.

Would you buy me a beer if I find a way in?:)

The reason I'm fairly certain about some kind of Android trickery going on there is because:

1. Dev environment is very similar to Android. From layouts and directory structure to .findViewById and several other methods / lifecycle hooks.

2. Android file transfer recognizes connected watch as an Android device.

3. Simulator has Android Debug Bridge references.

Unless I'm completely wrong, in which case I'm buying you a beer. I owe you one anyway for all the help you have given me and countless others :)

1.  I don't think that matters

2. ATP because it's an MTP device if it has music.  That doesn't mean Android.  Non MTP devices it just looks like A flash drive

3.  That's the sim, not the device.  ADB is there so you can test with a companion android app on a phone.

If on device was possible, don't you think it would be mentioned in the doc?

Lots of things are not mentioned in the docs, but I have an uneasy feeling you might be right... 

Something like this would be in the doc, have been mentioned at one of the summits, etc. Or come up when I've asked Garmin folks specifically about on device debugging.

Didn't know you asked them about it directly...

a very nice craft beer is coming up