Office Hours Transcript: 2021-07-01

sudokai joined


hello, sudokai!


how can I help you today?

Wow, you changed the chat software!




Yes, I had a question Mark.


Any advice on troubleshooting memory usage issues in Android apps


I’m using the profiler and I see a lot of "Native memory" allocations

um, that’s kinda broad 😀

That are never freed


So I launch the app and it uses like 120MB


But I start scrolling, navigating to other screens, hitting back, etc.


And the memory usage can eventually balloon to north of 500MB

AFAIK, those allocations would be referring to NDK code – are you using the NDK, or do you know of libraries that you are using that do?

Which seems like a lot for me___


Well, I use Realm, but that’s about it I think

sudokai1 joined


sudokai1 left

oooo… dueling sudokais!

Hah, I was testing the link

anyway, perhaps Realm is the culprit

I actually used the new native allocations profiler to see what’s going on


in Android Studio


But the flamegraphs are very hard to read


As in, they are incredibly deep


And the allocations seem to be a lot of small allocations


Instead of one big culprit


But generally, would you say that 350-500MB for an app is too much nowadays?

I haven’t used that native allocations profiler. Does it give you an indication of what in the JVM triggered the allocation?


the catch with native allocations is that they don’t count against your heap limit

Well, it’s hard to read, but I actually see what seem to be a lot of layout inflations

so, in terms of 350-500MB being too much, it will be for low-end phones, and it’s not ideal on most devices

Give me a sec, as I’m switching to the interface

sudokai left


sudokai joined



I’m here again



You can’t use the native allocations profiler on an emulator


Only on a real phone

Does Realm have widgets that you’re using? I wouldn’t expect framework or Jetpack widgets to report native allocations, though I haven’t had to do this sort of leak tracing in ages.


I’m used to thinking of Realm purely in terms of data storage, but I don’t pay a ton of attention to what changes they might have made in the past few years


um, are you there?

Emergency_Backup_Murphy joined


Emergency_Backup_Murphy left


Emergency_Backup_Murphy joined

testing, testing, 1, 2, 3

Well, I don’t used the latest version of Realm


Yeah working

Emergency_Backup_Murphy left

I see the emergency backup

do you see the original me?


OK, thought maybe the chat broke down or something

I prefer the interface


Anyway, I don’t use the latest version of Realm

it’s possible you’re seeing some Realm bug, though I’m surprised that layout inflations would be the culprit, unless you’re doing Realm I/O in a view constructor

So that could definitely be a problem too


unless you’re doing Realm I/O in a view constructor





I’ll try to capture a trace now


I’ll report back

So just launching the app on a Xiaomi phone, it’s already using 160MB of memory


Java: 15MB, Native: 50MB, Graphics: 18MB, Stack: 0.09MB, Code: 41.2MB, Others: 7MB

odd, that doesn’t seem to add up to 160MB


wonder where the other ~30MB went


anyway, 50MB native feels like an outlier, but I haven’t had a need to do this type of memory analysis in a while

Now, I’ve scrolled through the main recyclerview, 200 elements


And it’s using 271MB of memory

what is the new breakdown? did that mostly go to Native?

Java: 25MB, Native: 111MB, Graphics: 82MB, Stack: 0.1MB, Code: 39MB, Others: 8.2MB


Wait, could it be the Fresco library for loading images?

Fresco uses native code IIRC


at least back in the day, they were using that for what amounted to an in-memory cache

Because I have an image in each recyclerview element


Even if I trigger the garbage collection, the Native allocation still sits at 107MB

you might want to play around with Fresco cache settings ( and see if that changes things

If I turn off the screen, the Graphics memory goes down to 40MB


Nice, thanks for the link

I can’t tell if they have an API for controlling the cache size, though they should

Apparently, you need to implement MemoryTrimmableRegistry

ah, OK


if you have a way to get the current ImagePipelineConfig, you might see if you can log what the existing MemoryCacheParams values are


another quick-and-dirty test would be to comment out loading those images in your RecyclerView and see what the results are


if the memory problems go away, Fresco caching is your culprit, most likely


if the memory problems are still there, assuming you commented out Fresco’s bits, then Fresco won’t be the problem

Good idea


I’m interested in this problem because it seems that some battery managers are killing my app due to high memory usage

Kafran joined

sudokai: that’s not surprising

Thanks Mark!

sudokai: let me take a question from Kafran, and I’ll be with you in a bit


Kafran: hi! how can I help you today?

Hello Professor. Still studying =)
Professor I asked on the forum these days… I’m having difficulties to understand Classes Relationship on the OOP subject. Where could I read about composition, association and aggregation and its UML diagrams (=

I learned those topics over 20 years ago, so I am not up to date on the best current resources for learning OO concepts

Its not an Android question >.<
For what I can tell by reading the forum you’re a little skeptical about architecture (:

I would phrase it more that software architecture is a lot more "fuzzy" than some people think


if I asked five developers to show me how to do MVP in Android, I might get at least four distinctly different approaches


and none are necessarily right or wrong


so, in term of the "MV-whatever" sorts of architecture discussions, my reaction tends to be ¯\_(ツ)_/¯

I’m still learning the basics but with an eye on these things as these are fundamental to get a job =/

well, the architecture that will matter is the architecture used by your employer, and that may vary by employoer


er, employer


personally, I would focus more on having some pattern for how you set up your apps, for the sorts of samples that you might show a prospective employer as a portfolio


in other words, demonstrate good code organization skills, with some sort of layered approach


as opposed to, say, doing database I/O directly in an activity

Mark’s Exploring Android book is fantastic

sudokai, yes, I’m doing it

I wish all technical books were written in this way

along side with a coure I bought here in Brazil



sudokai: thanks! and there I’m focusing less on the details of the architecture style and more on just following Google’s recommended layers

Well, I gtg! Thanks Mark, see you around!

sudokai left

Kafran: whether your particular style is MVVM or MVI or MVP or MVC or something else is unlikely to matter in an interview setting, because you are going to need to adapt to what that employer wants you to use

Ok. Thanks.

just be reasonably organized, and I would not expect you to encounter problems as a result of any specific choices that you make

I pretty anxious right now




Mark, Exploring Android and Elements of Jetpack, should I follow both at same time?

you could, but that might be a bit much at once

Should I finish Exploring Android first?

probably yes


then, with Elements of Android Jetpack, you can skim through sections that cover the things that you saw in Exploring Android

Thasnks and good night. I got a slow pace with the reading as the course I’m doing advanced a little.


I have one more question but I will leave for the next meeting

OK! the next chat is Saturday in the 4pm US Eastern time slot

Ok. I have the schedule on google calendar, it manages time zone for me


I just forgot about today



have a pleasant evening!

Kafran left