1

I've recently gotten into android development, and I've been taking some of the Android basics courses offered on Udacity. I've tried using their forums, but I haven't really had much success, so I'm asking here!

Currently I'm on the fourth course which covers networking. One of the lessons goes over asynchronously loading data using the AsyncTask class first, then loaders. Part of the reasoning for using loaders over AsyncTasks is that the latter can potentially cause memory leaks if, for example, the phone's orientation changes while it's retrieving data. Loaders supposedly don't have this issue. Using the monitors on Android Studio, I checked how much memory was being used whenever I changed the orientation of the demo app for the course when I was using loaders. The amount of free memory would go down during the orientation changes regardless.

I tried the same thing using just the empty app template, and the same thing would happen; The amount of free space displayed on the monitor would go down, and the amount of allocated space would go up. The number of free space doesn't go back down until I click the little "initiate garbage collector" icon on the monitor. From what I've read, I understand that on orientation changes, activities are destroyed (confirmed this by logging a message on the Activity's onDestroy() callback, then switching orientation) and then recreated. But shouldn't the memory used by the activity that was destroyed be released? Why/Why not?

Thanks!

I know someone else asked a similar question, but it still doesn't answer my question (shouldn't the memory used by the activity that was destroyed be released?)

stillsleep
  • 41
  • 5
  • 1
    You raised an interesting question, have you also tried rotate from horizontal to vertical and reverse back, to see if the horizontal one will be recreated or just using the cached one in memory? – S.W. Jul 07 '17 at 02:33
  • Every time I change orientation (vertical to horizontal or horizontal to vertical) the amount of free memory goes down. – stillsleep Jul 07 '17 at 03:54
  • @stillsleep Well, I can understand why the memory goes down for an empty-template app on a configuration change since that deals exclusively with the main thread, but can you confirm that memory for `Loaders` get used up just as much as `AsyncTasks` while performing data/networking processes via the background thread? Also, have you used `Logs` accordingly for `Loaders` and notice that the `Loader` is created once at most for a certain ID so only the `Log` for `onLoadFinished()` is called on a configuration change(s)? – DaveNOTDavid Jul 07 '17 at 16:51
  • I haven't checked that, I'm not debating whether or not that's the case, I'd just like to know why the RAM displayed on the monitors doesn't go back down in general on a configuration change after the initial activity is destroyed. – stillsleep Jul 07 '17 at 19:15
  • 1
    You might wanna how [Garbage collector](https://stackoverflow.com/a/3315292/5217712) works. – Enzokie Jul 07 '17 at 21:30
  • @Enzokie that's exactly what I was looking for. I guess it wasn't super intuitive to assume "There are no guarantees regarding when GC will run except that it will definitely run and reclaim memory from unreachable objects before an OutOfMemoryException is thrown." Seems a little inefficient. Thanks! – stillsleep Jul 08 '17 at 00:08

0 Answers0