• Replies 22 replies
  • Subscribers 15 subscribers
  • Views 4943 views
  • Users 0 members are here
Options
Related

Best practices - performance, memory management, optimization

HermoT
over 9 years ago
Can you please share what your best practices are in terms of

Memory management and
Optimization for performance

I have now had two users providing feedback that my watchface slows down the watch overall.
For example apparently when the user wants to start training and pressing start / stop takes a moment to appear, or nothing happens and the user has to click twice. Apparently shows with other functions also.

Doesn't the watchface completely unload and free up memory when the user performs actions outside the scope / view of a watchface?

The description above does not make sense to me, but I believe that since it has been reported, I need to investigate at least.

For starters I am going to try and load resources a bit smarter. I know that I load all various bitmaps for example different battery levels all at once in the onLayout. But I might just need to load just the singel one on every onUpdate.

Regards,

H
  • Former Member
    Former Member over 9 years ago
    If you send your latest code drop, with steps to create the error message in the CIQ log, we will take a look. If the simulator isn't giving the the error, there could very well be an issue in the VM causing that message to appear in the log.
  • over 9 years ago
    Figured it out

    About 2 weeks ago, before I went on vacation, I figured out a huge performance issue in all of my watch faces.

    Now I have the time to share my resolution:

    It is very important to set a flag when onHide and onShow so that you can check in onUpdate whether you should update or not.

    Why Garmin allows the onUpdate to run even when the watchface is not shown, remains a mystery. This was the main cause why most users complained that my watchfaces are slow when they cycle through widgets.

    Another thing I did was to release memory in the onHide. I managed to cut down my memory footprint from 45kb to 23kb, and then, when onHide, further to just 15kb. This gives the watch much more memory and processor needed to run widgets smoother.

    Let me know who else didn't know this. To me this was not clear enough, especially the part about onUpdate running when hidden.
  • over 9 years ago
    My Activity History app - https://apps.garmin.com/en-US/apps/bd03db57-92c0-407f-ae39-70e2899c4f87

    also have this issue, but I think the slowdown is due to how I'm polling for the activity history at every second.
    My resolution has been to cache the numbers into an array instead of polling it every second. I figured that it is faster.
    But ever since my activity history has filled up the entire 7 days, the slowdown is occurring again.

    I've yet to figure out why as of yet but my watch face memory usage is pretty sane at 20kb.
  • over 9 years ago
    About 2 weeks ago, before I went on vacation, I figured out a huge performance issue in all of my watch faces.

    Now I have the time to share my resolution:

    It is very important to set a flag when onHide and onShow so that you can check in onUpdate whether you should update or not.

    Why Garmin allows the onUpdate to run even when the watchface is not shown, remains a mystery. This was the main cause why most users complained that my watchfaces are slow when they cycle through widgets.

    Another thing I did was to release memory in the onHide. I managed to cut down my memory footprint from 45kb to 23kb, and then, when onHide, further to just 15kb. This gives the watch much more memory and processor needed to run widgets smoother.

    Let me know who else didn't know this. To me this was not clear enough, especially the part about onUpdate running when hidden.


    Do you have a code snippet on what kind of a flag you setup on onHide and onShow? Thanks!
  • over 9 years ago
    To reduce overhead, here's what I do in watchfaces that use the history-

    There are only two times I grab the history - during initialize() and when the date has changed. I then save the data for display (history only changes once a day) in a easy to display format.

    I'm surprised that getting the history causes much of a CPU impact even if you grab it more often. Are you sure it's not something in how you display it - like figuring out the sizing for the bars on the display or something?
  • over 9 years ago
    Yes.. it's the ON-The-Fly calculation that may be causing some of the delays as well.
    I'm already caching most of the calculation (I think) cos if the step count history is > goal, i don't do any calc, it defaults to the max height of the y bar. (and I hit my goal 6/7 days of the week anyways)
  • over 9 years ago
    Do you have a code snippet on what kind of a flag you setup on onHide and onShow? Thanks!


    var show = true;

    function onShow() {
    show = true;
    }

    function onHide() {
    show = false;
    }

    function onUpdate(dc) {
    if(show){
    //if shown, perform your display update
    }
    }

  • Former Member
    Former Member over 9 years ago
    If your onUpdate function is being called on a view after onHide, and before onShow, I'd like to report that to the device teams so they can fix it. That is something that definitely shouldn't be happening.
  • over 9 years ago
    If your onUpdate function is being called on a view after onHide, and before onShow, I'd like to report that to the device teams so they can fix it. That is something that definitely shouldn't be happening.


    That is indeed what happens.

    You can check by putting println statement inside the onUpdate and force onHide in simulator.
    It keeps printing to console when hidden.
  • Former Member
    Former Member over 9 years ago
    Are you seeing this on a device? If so, which ones? We will look into getting this corrected in the simulator.