Memory Leak with setLayout?

Former Member over 8 years ago

I am refactoring an app I wrote for a vivoactive HR (128kb limit) for devices with less memory (right now vivoactive with 64kb limit).

I am trying to optimize everything as best I can but I ran into an interesting issue I am not sure how to deal with it.

I have a method to pause a workout and show a menu which allows you Save / Discard / Resume.

I noticed that when I toggle to pause the workout and resume it, about 10kb of memory get added to the used pool, and every time you do this, it adds.

For example: 50kb memory used -> Pause / Resume 60kb memory used -> Pause / Resume 70kb used.

It looks as if the "setLayout" method is what is doing this.

Am I doing something wrong where I should be doing something in the onHide function? I have tried doing setLayout(null) in onHide to no avail.

Aside from the usual tips of using less bitmaps, narrowing variable scope, etc. What can do to further lower the memory usage?

As an aside - the app is fairly heavy on bitmaps / fonts and I realize that when I try to refactor for a device with a very low 16kb limit I will have to remove them - however right now I am trying to refactor for a 64kb device which seems workable with my current set of resources.

Here is my source code if you'd like to have a look:

https://github.com/werkkrew/ciq-orange-theory

peterdedecker over 8 years ago

the layout system is pretty heavy on memory, to maximize memory you can reside to do using direct dc.draw calls instead, see also my tutorial on that: http://starttorun.info/tutorial-layout-by-coding-dc-draw-calls-directly/

travis.vitek over 8 years ago

This question has nothing to do with layouts. I haven't tested, but it looks like there is a problem with the view handling code.

Assume for a second that your application is currently recording, and you press the start/stop key. The key press causes the system to call OTFDelegate.onKey(), which calls OTFController.onStartStop(), which calls OTFController.stopWorkout(), which pushes a menu onto the view stack with a call to WatchUi.pushView(new Rez.Menus.EndWorkoutMenu(), new EndWorkoutDelegate(), WatchUi.SLIDE_UP). So now you have the initial OTFWorkoutView and an EndWorkoutMenu on the view stack.

If you choose Resume from the menu, EndWorkoutDelegate.onMenuItem() is called, which calls OTFController.startWorkout(), which calls WatchUi.pushView() to push another OTFWorkoutView. Since you've pushed a new view, the automatic popView() performed by the system does not occur, and you end up the initial OTFWorkoutView, the EndWorkoutMenu, and another OTFWorkoutView on the stack.

If you are going to call switchToView() or pushView() from onMenuItem(), you need to be sure to properly manage the view stack, which may mean calling Ui.popView() to remove the menu from the view stack. Once you've removed the menu, you may need to switch views (if you don't want to grow the view stack), or push a view (if you do want to grow the view stack). In this case, it appears that you need to either return true (and not push another view) in response to the onMenuItem() call, or you need to call Ui.popView() to get rid of the menu, and then call Ui.switchToView() to switch to the right view type.

Travis

jim_m_58 over 8 years ago

As far as memory on 1.x devices, a couple things to note:

On the va, if you have an app that records a .fit, 1k of memory is used by the system as soon as you start recording, so you only have 63k to work with. On the f3 devices, it uses 4k, so that leave you with 60k. Other 1.x devices don't use anything extra however.

So if you have an app that runs on the va, you may run into a memory issue if you try to port on a f3. Just something to keep in mind...

Former Member over 8 years ago

Barco 3100

the layout system is pretty heavy on memory, to maximize memory you can reside to do using direct dc.draw calls instead, see also my tutorial on that: http://starttorun.info/tutorial-layout-by-coding-dc-draw-calls-directly/

Thanks, I used the layout system simply because it seemed like it was the more "correct" way to do it. I will resort to individual draw commands if I must but I feel like this is a different issue.

This question has nothing to do with layouts. I haven't tested, but it looks like there is a problem with the view handling code.

Assume for a second that your application is currently recording, and you press the start/stop key. The key press causes the system to call OTFDelegate.onKey(), which calls OTFController.onStartStop(), which calls OTFController.stopWorkout(), which pushes a menu onto the view stack with a call to WatchUi.pushView(new Rez.Menus.EndWorkoutMenu(), new EndWorkoutDelegate(), WatchUi.SLIDE_UP). So now you have the initial OTFWorkoutView and an EndWorkoutMenu on the view stack.

If you choose Resume from the menu, EndWorkoutDelegate.onMenuItem() is called, which calls OTFController.startWorkout(), which calls WatchUi.pushView() to push another OTFWorkoutView. Since you've pushed a new view, the automatic popView() performed by the system does not occur, and you end up the initial OTFWorkoutView, the EndWorkoutMenu, and another OTFWorkoutView on the stack.

If you are going to call switchToView() or pushView() from onMenuItem(), you need to be sure to properly manage the view stack, which may mean calling Ui.popView() to remove the menu from the view stack. Once you've removed the menu, you may need to switch views (if you don't want to grow the view stack), or push a view (if you do want to grow the view stack). In this case, it appears that you need to either return true (and not push another view) in response to the onMenuItem() call, or you need to call Ui.popView() to get rid of the menu, and then call Ui.switchToView() to switch to the right view type.

Travis

I think you are right, I was wondering if I was managing the view stack correctly as I never make use of popView. I do use switchToView to get off the initial splash screen, although doing that does not seem to release any memory associated with that screen...

Let me see if I can change how I manage the view stack to get my memory usage under control.

travis.vitek over 8 years ago

the layout system is pretty heavy on memory
This question has nothing to do with layouts.

Sorry Peter, I focused in on the problem that was being described and not on the overall problem of trying to reduce memory usage. You are right, using layouts can be costly, and I apologize for the harsh response.

Travis