Office Hours Transcript: 2021-07-01
sudokai joined
Hello
hello, sudokai!
how can I help you today?
Wow, you changed the chat software!
:D
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 beta.hack.chat 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 beta.hack.chat interface
sudokai left
sudokai joined
Okay
I’m here again
hi!
:D
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?
yes
OK, thought maybe the chat broke down or something
I prefer the beta.hack.chat 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
_<
:D
I’ll try to capture a trace now
I’ll report back
OK
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 (https://frescolib.org/docs/caching.html) 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
course(
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
I’m*
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
Ok
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
Bye
have a pleasant evening!
Kafran left