Hi Mark..how are you?

hello!

sorry for the delay

how can I help you?

So I using FragmentStatePagerAdapter to swipe through approximately 100 screens or so...I am using fragment.createinstancemethod to create a new instance of my fragment each time...in my fragment I am making retrofit calls to get back json data including images to parse it and populate in my views accordingly...so about after 40 fragments or so...my app crashes because it runs out of memory as I am observing the memory monitor

no problem!

in my onstop method of the fragment, I am canceling the retrofit and asynctask calls...

I am somehow leaking memory and not understanding where I could be doing this...

well, you might not be "leaking" memory, so much as just using too much of it

generate a heap dump and see what's all being held onto

Right...

for example, you might have a singleton cache of some sort that isn't bound by size or number of elements, so it grows continuously

or, you might have several caches, each of which is individually capped, but that the sum of their caps exceeds available memory

hmm...the only singleton I am using is the retrofit api client instance but I get your point...

another technique would be to comment out some portion of the logic and see what happens with memory usage

right

for example, you might comment out loading the images, since bitmap management is a common source of OutOfMemoryErrors

right! I should try that

if with image-loading commented out, your memory profile is pretty flat, then that's the area to focus on

I have heard not great things about facebook's fresco...apparently the memory management when cleaning up resources is not handled properly...what are your thoughts?

I haven't used it

I stick with Picasso

but, I haven't written an image-heavy app, either

hmm...I use Picasso as well...

well, Picasso has an image cache

I think the default size is 20% of your heap limit, though I may be mis-remembering

and, the size is configurable

right

I love it

So I commented out the code related to images and I haven't seen a massive memory gain...

OK, well, that suggests that image management is the source of your problems

in theory, if all you are doing is using Picasso, there should not be a problem here

you might want to do that heap dump, search for Bitmap instances, and see what's all being held, and by what

or, temporarily disable the Picasso memory cache (which I think you can do), and see what happens

actually I am using fresco here

sorry I didn't mention

oh, I misunderstood

I don't have a lot of advice with respect to that, sorry

and I meant I didn't see a memory gain which means the problem maybe isn't with the images

oh, sorry, I misunderstood twice -- I thought you meant that you were not leaking memory

or, rather, that you were not increasing your memory usage

so, if it's not the images, you will need to determine what else large you have that might be the source of the difficulty

no problem...can i just ask you if my implementation is ideal? the fact that I am making retrofit calls in the fragment and updating the views?

the reason why bitmaps tend to be a problem is that they are usually the biggest single chunks of memory we have

or should I use a service or something like that?

I can't really say whether that is a good thing or a bad thing

a service would only be needed if you intended to do this I/O even if the user stepped away from the activity

right

it's not...so service is probably not ideal here

it should not be needed

so, I'm back to the heap dump suggestion, annoying as those are to try to make sense of

I should learn how to interpret the heap dump first...

haha

and that's a wrap for today's chat

thank you Mark

the transcript will be posted to https://commonsware.com/office-hours/ shortly

the next chat is 4pm US Eastern on Tuesday

you are very welcome!

have a pleasant day!